Add support for advisories defined in CSAF

[stevespringett]

Current Behavior

Some commercial software vendors provide advisory information in CSAF 2.0 format. These include RedHat and Oracle, among others. There isn't currently a good way to identify vulnerabilities in a specific part of RHEL for example, as CPE isn't granular enough.

Support for CSAF was brought up in https://github.com/DependencyTrack/dependency-track/issues/1374#issuecomment-1065265818

Proposed Behavior

Add native support for consuming CSAF 2.0 feeds. This should be definable by Dependency-Track administrator, similar to how package repositories are managed today.

Concerns:

• There is a lack of tooling and libraries that support CSAF today
  • We need a reusable Java library that works universally across any vendor that provides CSAF, and not specific to how certain vendors have implemented CSAF
  • Support for CSAF profile 1, 2, and 4 are likely required. Support for profile 3 is likely optional
  • Chosen library should include support for resolving CSAF feeds according to spec, including /.well-known/csaf/provider-metadata.json, ROLIE, security.txt, and csaf.data.security.domain.tld. CSAF resolution via the specs distribution requirements should be the responsibility of the library, not Dependency-Track
• There are no guidelines for how to resolve products in a product tree
• There doesn't seem to be a universally accepted way to associate a component in an SBOM to a product in a CSAF advisory

Notes:

• Support for CSAF is for advisories only. It is likely not possible to support CSAF VEX (profile 5) without much more guidance from OASIS.
• Upon release, this should likely be a beta feature. CSAF is new, has limited adoption, and the correlation to component identity in SBOMs has likely not been tested in the real world. There will likely be compatibility issues, thus beta feature with associated warning is recommended

Checklist

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

[tschmidtb51]

There is a lack of tooling and libraries that support CSAF today

• We need a reusable Java library that works universally across any vendor that provides CSAF, and not specific to how certain vendors have implemented CSAF [...]
• Chosen library should include support for resolving CSAF feeds according to spec, including /.well-known/csaf/provider-metadata.json, ROLIE, security.txt, and csaf.data.security.domain.tld. CSAF resolution via the specs distribution requirements should be the responsibility of the library, not Dependency-Track

For the consumer side, there are currently not many Open Source tools available. I would suggest to start importing local CSAF files (or provide an API to push CSAF files into Dependency Track). A consumer could use tools like CSAF Downloader to retrieve CSAF files from feeds.

• Support for CSAF profile 1, 2, and 4 are likely required. Support for profile 3 is likely optional

I would suggest to start with the profiles Security Advisory and VEX as those seem to be the most relevant to the users right now.

• There are no guidelines for how to resolve products in a product tree

The is already an issue https://github.com/oasis-tcs/csaf/issues/593 that explains parts of the solution. However, that might not be enough...

• There doesn't seem to be a universally accepted way to associate a component in an SBOM to a product in a CSAF advisory

IMHO, the standard describes what is expected:

• Use BOM-Link if you want to reference a specific component
• Use SBOM urls if they exist to reference a "primary component"
• As fallback use the supplier/component/version methodology from SBOMs (through the product_tree)

[tschmidtb51]

• Support for CSAF is for advisories only. It is likely not possible to support CSAF VEX (profile 5) without much more guidance from OASIS.

Happy to provide guidance. Are there any specific questions?

[tschmidtb51]

I would love to see DependencyTrack to become a CSAF SBOM matching system.

[wurstbrot]

As an OpenSource user and a vendor, I envision enhancing Dependency Track with a CSAF management system to better manage security vulnerabilities. Specifically, I propose reflecting the state of a CSAF Product Status within the vulnerabilities associated with a component or primary component. For instance, if a CSAF Product Status is labeled as known not affected, this could trigger the suppression of the corresponding matching component and vulnerability within Dependency Track.

[nicorikken]

Dutch National Cyber Security Centre started publishing in CSAF format as well https://vulnerabilities.ncsc.nl/ adding to the relevance of this enhancement. I recognize the lack of a decent library before getting started.

[oxisto]

Hi everyone!

Happy to announce that we (https://github.com/Fraunhofer-AISEC) were contracted by the German BSI to develop an extension to DependencyTrack to handle CSAF documents. This includes importing, matching them against components and management CSAF documents within DependencyTrack. We will also introduce ourselves shortly in Slack how to proceed with the parts that we need to develop within DependencyTrack itself. We are still in a little bit of holiday mode here in Germany, so stay tuned for more updates. We will have a dedicated person working as a contact person for the DependencyTrack team, but he is also still in holiday.

I will hopefully able to share more details on this soon, especially where we are pushing the code, etc, we still have to work out some internal regulations for that.

In the meantime, feel free to assign this issue to me if you want - as I am the main project manager of this project on our side. And of course I am happy to answer (almost) all of your questions :)