Consume SBOM, produce VEX

[marcelstoer]

Is your feature request related to a problem? Please describe.
We have been using OWASP dependency-check (aka ODC for us) at corporate level (600 employees) for a several years. Also, we built light-weight tooling, policies and processes around it. Besides CI integration we established a suppression/exception board that decides on which issues to suppress. The suppression files it produces are published internally and added to the ones we get from ODC when we analyze components. Furthermore, with every component we release we also publish the ODC reports and our suppression files alongside the component artifacts (in Artifactory). As such, all of that is available for customers.

To ensure all projects are buildable in our CI infrastructure we produce throw-away releases once a month fully automated (build, publish, discard). As ODC is included in this process we detect vulnerabilities in our components and their dependencies no later than a month after they are published. It is a byproduct of our auto-build strategy.

We achieved a high level of automation and thanks to this wonderful project we are very happy with the results. Yet, two developments make us want to extend or rework that setup:

• More and more customers are asking for SBOM and VEX - or something similar. It's their compliance requirements (perceived and real) that are driving this.
• Detecting vulnerabilities on (at least) a monthly basis might be ok by some. We'd rather know at lot sooner: daily.

We have been looking at the various tools and offerings around CyclonDX, SBOM and VEX. We also considered dependency-track but we don't feel it would fit in nicely with our organization. Instead, the first step now is that we produce SBOMs for each component we release. We use cdxgen to create them and just like the ODC reports we publish them to Artifactory. The SBOM should then serve as the foundation to run "a dependency check" frequently. There are tools that do this (e.g. OWASP dep-scan) but we'd like to avoid two things:

• Those tools to produce different results that what ODC produces during CI and release builds (which fail on CVSS>=7).
• Those tools to force us to abandon using ODC which in turn would also impact the artifacts our suppression/exception board produces.

Describe the solution you'd like
Given our setup we consider an evolution around the ODC project as the ideal solution. This would require the ODC scanner to accept CyclonDX SBOMs as a new input. Furthermore, it would need to offer VEX as new report format.

There are certainly tools in this context that we haven't considered yet. So, if you see flaws in our thinking we'd be happy to hear that.

Describe alternatives you've considered
We would either need to abandon our OCD-based approach, build a custom solution of some sort or reevaluate (something like) Dependency-Track.

Additional context
In #2958 (comment) @jeremylong seemed to be open to "including a scanner for an SBOM." #4516 briefly touched on the VEX topic but it mainly discussed suppression files.

[marcelstoer]

@jeremylong @aikebah I would be enormously grateful to get your expert feedback on this proposal. If it's way beyond of where you intend to take this project, I will close it.

[jeremylong]

This will be possible after implementing #6540