Skip to content

Project Ideas

Philippe Ombredanne edited this page Feb 24, 2021 · 3 revisions

Project Ideas

Integration with other aboutcode tools :

This includes integration with other aboutcode tools, namely scancode io and scancode-toolkit .

At a higher level these tools detect all the packages used by a codebase. They will then query VulnerableCode and verify whether each of the found package is vulnerable or not .

See ticket at scancode io

More data sources :

See https://github.com/nexB/vulnerablecode#how for background info. We want to search for more vulnerability data sources and consume them. There is a large number of pending tickets for data sources. See https://github.com/nexB/vulnerablecode/issues?q=is%3Aissue+is%3Aopen+label%3A"Data+collection"

Generic issues mining :

The project would be to provide a way to effectively mine issues (such as GitHub issues) for possible unreported vulnerabilities. For a start this should be focused on a few prominent repos.

CI integrations:

Create a CI integrations which would scan the codebase for packages using SBOM tools like scancode-toolkit. Then verify whether each of the package is safe. Implement a Github action, jenkins plugins that does this .

Vulnerability review Workbench:

We could add UI components that would enable reviewers to triage, refine, improve and curate vulnerability data. This could include linking and displaying references and helpers to link the vulnerability to packages. VulnerableCode should obviously consume this newly minted data.

Use NLP and machine learning to "understand" vulnerability descriptions:

Often security advisories do not provide structured information on which package and package versions are vulnerable. We could create a system which would infer vulnerable package name and version(s) by parsing the vulnerability description using natural language processing techniques and heuristics.

Vulnerability code scanners (e.g. static code analysis):

Create scanners which would verify whether a codebase is vulnerable to a vulnerability. Once we know that a vulnerable package is in use, a scanner could check for whether the vulnerable code is called, or if environmental conditions or configuration are conducive to the vulnerability, etc. This could be based on yara rules, OpenVAS or similar. Or based on Eclipse Steady and deeper code analysis, static or dynamic.

Exploits references as alternative to scanner:

We can collect exploits and PoC that can verify whether a codebase is vulnerable to a given package vulnerability. Once we know that a vulnerable package is in use, the exploit could be to check for whether the vulnerable code is effectively being called.