As part of our secure SDLC strategy, we generate an SBOM(Software Bill of Material) and store it inside Dependency Track. This gives us a good overview of all our applications, their dependencies and vulnerable components.
However after upgrading to the latest CycloneDx-dotnet version, our SBOM pipeline turned out broken.
The problem
When uploading an XML-based Software Bill of Materials (SBOM) to Dependency-Track, we started to encounter a 400 – Bad Request response. The culprit is a version mismatch: a recent update to the dotnet-CycloneDX tool now generates SBOMs in CycloneDX 1.7 format by default — a version that Dependency-Track does not yet support.
Dependency-Track validates incoming SBOMs against its supported schemas. When it receives a 1.7 document, schema validation fails and the upload is rejected entirely.
The dotnet-CycloneDX package was updated our your build server, silently bumping the default output format from CycloneDX 1.6 to 1.7. No code change, just a dependency update.
The fix
We fixed it by explicitly pinning the output version to CycloneDX 1.6 in our build script. This can be done by passing the version flag to the CLI. For example:
dotnet-CycloneDX ... --spec-version 1.6
This forces the tool to produce a 1.6-compliant XML document, which Dependency-Track accepts without issue.
Summary
If your SBOM pipeline breaks with a 400 error after a dependency update, check whether your tooling has bumped the CycloneDX spec version. Until Dependency-Track adds support for CycloneDX 1.7, explicitly specifying --spec-version 1.6 in your XML generation step is the recommended workaround.
A big thank you to my colleague Jef who did the investigation and found a solution.
More information
Introduction | Dependency-Track
CycloneDX/cyclonedx-dotnet: Creates CycloneDX Software Bill of Materials (SBOM) from .NET Projects