Add support for source/sink and stacktrace to vulnerability support

[stevespringett]

Per comment https://github.com/CycloneDX/specification/pull/91#issuecomment-982546216

In general I like this, but it seems like it has bit of a vulnerability centric view versus a vulnerability in context of an assembled >piece of software view. An example to demonstrate.

I'm shipping ACME Widget Studio. CVE-EverythingIsOnFire, which affects component C, is published. Some segments of my dependency graph are as follows (X is ACME Widget Studio, * indicates a potentially exploitable component)...

X* -> A* -> B* -> C* X -> D -> B* -> C* X -> E -> C* X* -> C* The context of the CVE is quite different for each of those dependency graph segments.

I might not be groking this right. But I'm not sure how I would represent these different scenarios in the same BOM.

2 and 3 aren't exploitable, for different reasons, which I want to communicate.

1 and 4 are potentially exploitable, depending.

Do I include the same vulnerability multiple times for each?

Also, maybe, "affects" should be changed to "appliesTo"?

AND https://github.com/CycloneDX/specification/pull/91#issuecomment-982865331 https://github.com/CycloneDX/specification/pull/91#issuecomment-983043949

One possible solution is to support SARIF

[stevespringett]

@planetlevel is this something you or anyone on your team would be interested in contributing to?

Anyone else in the SARIF world we should reach out to?

IMO, if we use SARIF, we need to do so in a way as to support static analysis results today, and other forms of analysis tomorrow. From my understanding, support for dynamic analysis in SARIF is planned, so this could potentially tie into vulnerabilities against services defined in CycloneDX - currently possible.

[planetlevel]

@stevespringett - SARIF already supports multiple forms of analysis, including IAST and DAST. They're considering changing the name to Security Analysis Results Interchange Format (instead of Static). Here's an example of a webRequest in SARIF spec -- https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc10541090

I could easily imagine including or linking to a SARIF document that describes the vulnerability in question. That would be the most complete way to capture all the relevant information.

We could also come up with a simplified format, but I suspect we would quickly run into a lot of cases that would require us to basically reinvent SARIF.

What are next steps in exploring this?

[stevespringett]

This enhancement should also support reachability.