CycloneDX / CycloneDX/specification
[FEATURE]: Clarity on referring to external VEX source from SBOM
- Dominant language
- XSLT
- Stars
- 547
- Forks
- 93
- Avg merge
- 7h 11m
- Merged PRs (30d)
- 37
Description
## Describe the feature
I would like to be able to strictly typed refer to external VEX information outside of a CDX BOM.
We are already distributing SBOMs with our container images as In-Toto attestations and are very happy that scanners like Trivy are able to pick up the BOM and use it for the most accurate scan results we ever had.
What is missing now is that we would like to be able to communicate vulnerability information (e.g. VEX statements) not hard coded in the BOM itself but rather serve an associated file somewhere else over HTTPS so we are able to make additions when the SBOM was already released to consumers.
What I was thinking about is to use the "externalReferences" in the "exploitability-statement" type to link to such an external VEX file and trying to get SBOM scanners to adopt resolving such references for immediated assessment of known false positives.
That field seems to be exactly made for that use-cases as being [typed as containing either an **URL** or a **BOM-Link**](https://github.com/CycloneDX/specification/blob/268138039498a4f390ddc5d7e7e78857a951986f/schema/bom-1.6.schema.json#L1710-L1720).
As far as I understand it, the BOM-Link is an abstract link between documents, but would not tell some kind of scanner e.g. where to retrieve it.
The URL type on the other hand could contain any kind of resource on the other end - e.g. a URL to a PDF statement, an HTML page or _maybe_ a CDX BOM with VEX information. This makes it a bit hard to make a case for e2e automation.
## Possible solutions
What I would be wishing for is 2 things:
* a statement from your side / the community if that is actually a valid usecase that makes sense to be supported by tools interacting with an SBOM for security scanning -> discussion on trivy repo for reference: https://github.com/aquasecurity/trivy/discussions/8047
* some kind of concept where we can provide additionaly typing to the URL to make it easier for scanners to distinguish if they can read the "format" of the resource that is located at that URL or not (seems very similar to a Media Type now that I am writing it out).
## Alternatives
I am aware of the work being done on the Transparancy Exchange API. To me the TEA seems like a parallel usecase but not contradictory. E.g. maybe the linked VEX file might even be hosted by a TEA in the future.
## Additional context
Add any other context about the problem here.
Contributor guide
Assessment
This issue has not been assessed yet.