Evaluate VulnerableCode as source for vulnerability database

[nscuro]

Current Behavior

We're aiming to build a mechanism to assemble and distribute a vulnerability database tailored to Dependency-Track's needs.

Similar efforts exist already. It would be good to leverage what is already there, rather than reinventing the wheel.

The goals for our own database are defined here: https://docs.google.com/document/d/1DVV4ik7NGOBc6u-fdPlPVKoplNmSpzDT6iC4FJAFYi0/edit?tab=t.0#heading=h.w22q0gsagz1c

Proposed Behavior

Evaluate if and how VulnerableCode (https://github.com/aboutcode-org/vulnerablecode) can be leveraged.

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this enhancement was already requested

[nscuro]

(Comment moved from #4122 (comment))

Their credentials look great. There is a wide range of supported data sources:

Available importers as of v35.1.0

vulnerabilities.importers.alpine_linux.AlpineImporter
vulnerabilities.importers.openssl.OpensslImporter
vulnerabilities.importers.redhat.RedhatImporter
vulnerabilities.importers.debian.DebianImporter
vulnerabilities.importers.postgresql.PostgreSQLImporter
vulnerabilities.importers.archlinux.ArchlinuxImporter
vulnerabilities.importers.ubuntu.UbuntuImporter
vulnerabilities.importers.debian_oval.DebianOvalImporter
vulnerabilities.importers.retiredotnet.RetireDotnetImporter
vulnerabilities.importers.apache_httpd.ApacheHTTPDImporter
vulnerabilities.importers.mozilla.MozillaImporter
vulnerabilities.importers.gentoo.GentooImporter
vulnerabilities.importers.istio.IstioImporter
vulnerabilities.importers.project_kb_msr2019.ProjectKBMSRImporter
vulnerabilities.importers.suse_scores.SUSESeverityScoreImporter
vulnerabilities.importers.elixir_security.ElixirSecurityImporter
vulnerabilities.importers.apache_tomcat.ApacheTomcatImporter
vulnerabilities.importers.xen.XenImporter
vulnerabilities.importers.ubuntu_usn.UbuntuUSNImporter
vulnerabilities.importers.fireeye.FireyeImporter
vulnerabilities.importers.apache_kafka.ApacheKafkaImporter
vulnerabilities.importers.oss_fuzz.OSSFuzzImporter
vulnerabilities.importers.ruby.RubyImporter
vulnerabilities.importers.github_osv.GithubOSVImporter
vulnerabilities.importers.curl.CurlImporter
vulnerabilities.importers.epss.EPSSImporter
vulnerabilities.importers.vulnrichment.VulnrichImporter
pypa_importer
npm_importer
nginx_importer
gitlab_importer
github_importer
nvd_importer
pysec_importer

Data is stored in a PostgreSQL database. It'd be easy to filter and transform this data as needed. Since we wouldn't be using their database schema in DT, some form of conversion is required.

They are entirely software focused. Their NVD importer explicitly skips records of hardware vulnerabilities. We could contribute a change to make this configurable. We could further contribute more importers for hardware-specific sources.

Importing data is extremely slow for me, not sure why. Running the NVD import alone has an ETA of over 90min.

They have their own vulnerability IDs. CVEs and other identifiers are listed as aliases. Aliases are purely descriptive, there is no concept of grouping based on them.

The hashid package is used to deterministically generate vulnerability IDs. We should consider following a similar strategy.

They explicitly track affected and fixed packages for each vulnerability. I assume the coverage heavily depends on the data source. Still very convenient.

I haven't seen if or how version ranges are handled.