Upload an SBOM
An SBOM (software bill of materials) is how Declara knows what's actually in your product. Upload one to a product version, and matching against the advisory feeds starts from there.
Supported formats
- CycloneDX 1.4 through 1.7, as JSON or XML
- SPDX 2.2 through 2.3, as JSON or tag-value
Format is detected from the file's own content, not its filename or extension. A
file named sbom.json could be either CycloneDX or SPDX — Declara reads the
document itself to tell which.
Steps
- Open the product you want to attach the SBOM to.
- Upload the file. Drag it in or choose it from your filesystem.
- Wait for parsing. Declara sniffs the format, extracts every component it can identify by purl (package URL), and records the dependency graph as given in the document.
- Matching runs automatically. Every component with a purl is checked against the current advisory feeds.
What you should see
The product page updates to show a component count and a last-scanned time. If nothing in the SBOM matched a known advisory, or every match was Tier B or C, your alerts list stays empty — see Understand your first alert for why that's not a sign anything went wrong.
Under each version you'll also see the SBOM's score against the fields BSI TR-03183-2 asks for (see Check an SBOM's quality) and, if the document carries a cryptographic bill of materials, how many cryptographic assets it declares (see Review the cryptography an SBOM declares).
Other ways in
- From CI. Push the SBOM your build produces through the API on every release. See Push SBOMs from CI.
- From Dependency-Track. If your SBOMs already live in a Dependency-Track server, map each project to a Declara product and Declara imports the project's BOM once a day, or when you press Sync now. The project's version becomes the product version, and a BOM identical to the last one is not recorded again. The import is read-only and pull-only. See Connect Dependency-Track.
Both need an API key or integration, on the Growth or Partner plan. Every route ends in the same upload record, parsed and matched the same way.
Supplier SBOMs are kept apart
An SBOM a supplier uploads through a supplier request is stored and scored for completeness, and it is not attached to any product version. It is not added to your inventory and it is not matched against advisories, so it raises no alert. Upload your own product's SBOM here to have it watched.
Cryptographic assets are not packages
CycloneDX 1.6 and later can list algorithms, protocols and certificates as
cryptographic-asset components. Declara keeps those apart from your packages: they
are not counted in the inventory, never matched against advisories, and do not affect
the quality score. A file that contains only cryptographic assets is refused, so an
upload cannot empty a version's inventory.
Components with no purl
A component Declara can't resolve to a purl can't be matched against anything — it's recorded in your inventory, but it contributes nothing to matching. This isn't an error; some SBOM exporters simply don't emit a purl for every entry.
A note on dependency depth
Where a component sits in your SBOM's dependency graph — direct or several levels deep — is shown as a hint about whether you chose it or inherited it, read straight from the graph the SBOM itself describes. It's not a claim about whether the vulnerable code path is actually reachable in your running product. See What the CRA requires of you, and what Declara does about it for the fuller framing on what stays yours to judge.