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.
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.