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 :)

[volker-holz]

Hi oxisto, happy to hear you were contracted to develop this extension. Are you able to provide additional details yet, e.g. roadmap or such? Thanks!

[oxisto]

Hi oxisto, happy to hear you were contracted to develop this extension. Are you able to provide additional details yet, e.g. roadmap or such? Thanks!

I will be careful about concrete dates but maybe it's time to give a short update. Our main working space is currently https://github.com/csaf-sbom/kotlin-csaf. The main artefact we are currently working on is https://github.com/csaf-sbom/kotlin-csaf, to handle CSAF files in Kotlin. Currently it is only targeting the JVM, in theory we could enable Kotlin multiplatform, but since DepedencyTrack is our main integration target, it is not necessary at the moment. We just had our first 0.0.1 release.

The next step is to integrate this library into the DepencencyTrack backend server and create the necessary Vue views for the frontend. For that we are currently using a fork of the various DT micro-services in our csaf-sbom organisation. Once we have a working example ranging from fetching CSAF, storing them in the DT database and loading them again, we will prepare the first smaller PRs for DT.

[volker-holz]

Thanks, oxisto, for your quick reply! Actually I was not aiming for an exact date; a rough targeted month or even quarter would already be helpful. Situation is that I am involved in a project aiming for production around mid 26, thus I would love to rely on having that feature around mid 25. Otherwise we would have to think about alternative approaches. Should I be worried? :-)

[oxisto]

Thanks, oxisto, for your quick reply! Actually I was not aiming for an exact date; a rough targeted month or even quarter would already be helpful. Situation is that I am involved in a project aiming for production around mid 26, thus I would love to rely on having that feature around mid 25. Otherwise we would have to think about alternative approaches. Should I be worried? :-)

Mid '25 sounds reasonable.