cyclonedx-maven-plugin VS dependency-track

There are a number of SBOM standards, but we'll focus on the CycloneDX standard here. CycloneDX grew out of the Open Web Application Security Project (OWASP), is licensed under Creative Commons Zero v1 (think a "public domain" license formulated to meet the laws of many countries), and is a widely known and respected standard.

As others have already commented:

The US government has added SBOMs to a proposed rule to update the Federal Acquisition Regulation. So if you want to sell to the US Government you'll have to provide SBOMs: https://www.federalregister.gov/documents/2023/10/03/2023-21...

Lots of large companies require SBOMs from their supplier.

In the EU we will get the Cyber Resilience Act which will make them mandatory as well in certain cases: https://data.consilium.europa.eu/doc/document/ST-12536-2023-...

And yes, there's bascially two technical standards to provide them: SPDX and CycloneDX: https://cyclonedx.org/

Usually there is a requirement through a risk in the risk register, new project etc. appsec engineers perform an analysis of what is available in the market paid and/or open source and match it against the list of requirements and come up with an proposal to be signed off by relevant stakeholders. Usually (there may be exceptions) security engineers take care of the implementation. Which snyk product are talking about? SCA? If so have a look in https://cyclonedx.org/ open source or jfrog (paid) but it will depend much on your current processes mainly around CI/CD tools

We use https://cyclonedx.org/ to auto generate them.

The recent govulncheck effort made me think of the possibility of having the go tool create an SBOM (Software Bill of Materials) in a standard format like CycloneDX that could be consumed by existing tools like DependencyTrack. Somewhat similar to the recent docker sbom feature.

Alternative it would be nice, if there is way to get an SBOM (Software Bill of Materials). Microsoft created an Open Source Tool to get an SBOM for many programming languages, but pascal is not one of this. With a SBOM file, it should be possible to run it against a tool like CycloneDX.

A Software-Bill-of-Materials (SBOM) lists all the software components included in an image. Buildpacks support SBOMs in CycloneDX, Syft and SPDX formats.

CycloneDX is OWASP's lightweight SBOM standard for application security and software composite analysis. It comes with multiple tools for all environments. Its maven plugin generates SBOM featuring all types of dependencies in your projects.

There is a CylconeDX plugin available on Maven central and Github that appears to be well-maintained and commonly used.

This sample project is using Maven build system for generating artifacts. cyclonedx-maven-plugin is used for generating CycloneDX SBom file.

I've become interested in SBOM recently, and found there were great tools like https://dependencytrack.org/ for CycloneDX SBOMs, but all I have is SPDX SBOMs generated by GitHub.

I decided to have a go at writing my own dependency track esque tool aiming to integrate with the APIs GitHub provides.

It's pretty limited in functionality so far, but can give a high level summary of the types of licenses your repository dependencies use, and let you drill down into potentially problematic ones.

Written in NextJS + mui + sqlite, and using another project of mine to generate most of the API boilerplate/glue (https://github.com/mnahkies/openapi-code-generator)

To detect these types of vulnerabilities, we should first and foremost know our dependencies and versions, and which of them have vulnerabilities. The OWASP Top 10 2021 identifies this need as A06:2021-Vulnerable and Outdated Components. OWASP has several tools for this, including Dependency Check and Dependency Track. These tools will warn about the use of components with vulnerabilities.

https://dependencytrack.org/

You just need to use one of the various tools out there to scan.

OWASP Dependency Track - https://dependencytrack.org/

Dependency-Track

I actually want to build the same thing you are after, and I think I’ll go for the setup you describe in idea 2. The tool you can use for this is Trivy (https://trivy.dev), have it generate a SBOM and send it to Dependencytrack (https://dependencytrack.org).

If you like Dependency-Track, consider moving to Dependency-Track ( https://dependencytrack.org ), which makes administration much easier.

Even if you roll up the sleeves and add the feature yourself there is no guarantee it will be accepted upstream and you should always be prepared for the possibility of wasting time.

I don't quite understand the deployment issue. I mean, I understand people might not be tracking what's deployed, but I don't understand what is missing for it to be happening today, other than will.

For example: I build some software into a Docker image, version tag it, sign it, and generate an SBOM for it. That image goes into production with signature validation. Even if I've included 100 jar files in there, I should know exactly which ones I have. I can upload the SBOM to my DependencyTrack[1] instance to so over time no dependencies have vulnerabilities I'm not aware of.

What doesn't work in that scenario? What scenarios can't conform to that one?

[1] https://dependencytrack.org