Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support generation of a cyclonedx bom #2233

Open
amandel opened this issue Oct 4, 2019 · 5 comments
Open

Support generation of a cyclonedx bom #2233

amandel opened this issue Oct 4, 2019 · 5 comments

Comments

@amandel
Copy link
Contributor

amandel commented Oct 4, 2019

(Lost my initial text :( )
Dependency Check finds dependencies of a project in a wider scope than cyclonedx-maven-plugin as a sample. It not just checks the build file (pom.xml) but also the files in the workspace. So from my point of view it is better suited to create a bom of a project.

Would it be possible - with reasonable effort - to generate a CycloneDX bom.xml as a result file of the DependencyCheck? This would allow the use of DependencyCheck for detection of immediate vulnerabilities and the generation of the bom. DependencyTrack can then cover the long term scope, vulnerabilities found after build time and updates or retirements of used dependencies.

@mathuriga
Copy link

It's a really useful feature 👍 .

In which version we can expect this feature?

@ufkesba
Copy link

ufkesba commented Jul 31, 2020

This would be a great addition! A seamless integration with Dependency Track would be great for the OWASP projects

@stevespringett
Copy link
Collaborator

In order for DC to support this, it would theoretically need to:

  • Remove all existing evidence-based analysis and replace it with high-confidence or factual analysis that would end up in the BOM. This would change the entire premises from which DC is designed.
  • Natively recreate how each of the supported ecosystems (npm, pypi, nuget, etc) resolve dependencies and provide metadata for each package analyzed from each ecosystem.

These two things would be a ton of work and would essentially remove the value that DC provides as an audit tool. Simply bolting on CycloneDX output to the existing design would lead to inaccurate and incomplete data in the BOM.

DT will not import vulnerabilities from a CycloneDX BOM. The base specification doesn't support opinion or dynamic facts such as vulnerabilities, only static facts like hashes, license, and authors. So I'm not entirely sure why outputting CycloneDX would be a useful feature for DC in the first place.

I'd recommend creating PRs to the tools in question to add the features you need, or use a tool like ORT that already supports the above ecosystems and outputs CycloneDX.

@VinodAnandan
Copy link

I think we should revisit this as the CycloneDX 1.5 can now capture evidence ( https://cyclonedx.org/docs/1.5/json/#components_items_evidence ) and VDR. Many other SCA tools (Syft, Trivy, Blackduck, etc.) generate the CycloneDX SBOM.

I think the CycloneDX SBOM generation will enable more collaboration with the OWASP Dependency Track project. If the DependencyCheck can generate the BOM, it can be published to the DependencyTrack for scanning and monitoring

@marcelstoer
Copy link
Contributor

marcelstoer commented Jan 16, 2024

@stevespringett In #5947 I proposed for this project to consume CyclonDX SBOMs (rather than to produce them as discussed here). I feel it would be much more in line with how DC currently works. SBOMs could be treated as another form of evidence to scan. To complete the picture, DC could then produce a VEX file by mapping the contents of its suppression files to the VEX analysis section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants