Since Executive Order 14028 and OMB Memorandum M-22-18, “do you have an SBOM?” has become a procurement gate, not a nice-to-have. A software bill of materials lists every component that ships inside a release — the direct dependencies you chose and the transitive ones you inherited. The NTIA’s minimum-elements guidance and CISA’s SBOM work set the baseline: component name, version, supplier, unique identifiers, and dependency relationships, in a machine-readable format (CycloneDX or SPDX).
Most teams can generate an SBOM — syft, cdxgen, and Trivy all do it in one command. The hard part is everything after: correlating those components against the vulnerabilities you already track, telling the world which CVEs actually affect you (and which don’t) in a format a machine can read, proving how the artifact was built, and handing a buyer a single bundle that answers all of it. Talarity treats the SBOM as the spine of that whole workflow.
What’s on the page
Everything below happens on one route — /app/appsec/sbom — organized into three tabs:
- Documents — the SBOM inventory: ingest a bill of materials, browse its component inventory, correlate findings, author and publish VEX, verify provenance, and export a procurement bundle.
- Products — group a series of releases so you can diff any two of them.
- Composition policies — license/package rules that flag components you don’t want shipping.
Step 1 — Ingest a bill of materials
Click Upload SBOM and paste a CycloneDX 1.5 or SPDX 2.3 document. Talarity auto-detects the format, so you don’t pick a type. Optionally link the document to a repository — a real picker of the repos you already track, not a raw ID to hunt down — and give the release a name.
Re-uploading the same document is safe — Talarity de-duplicates on the document’s SHA-256, so a nightly pipeline that pushes the same bytes won’t pile up duplicates. Ingest parses every component into a normalized inventory.
Step 2 — Read the component inventory
Each component lands with its version, license, type, and — once you correlate — its known vulnerabilities. A container image SBOM can carry thousands of components, so the inventory has a filter: type a name, purl, or license and the list narrows server-side. Below, filtering on apache cuts a twelve-component release down to the four Apache-2.0 packages.
Step 3 — Correlate against your findings
Talarity does not run a second vulnerability scanner or call an external feed behind your back. Instead, Correlate findings matches the SBOM’s components against the SCA findings already in your AppSec findings register — the ones that arrived through your real SARIF and scanner imports. Every CVE it attaches is one you already track; a release with no matching findings honestly correlates zero.
Expand the affected component to see the CVE, its severity, and its CVSS score, with an inline editor for the next step.
Step 4 — Author VEX (and say what doesn’t affect you)
A vulnerability appearing in your dependency graph is not the same as your product being exploitable. VEX — a Vulnerability Exploitability eXchange statement — is how you say so in a way a buyer’s tooling can consume. Talarity follows the OASIS CSAF 2.0 model: set a status (not affected, affected, fixed, under investigation), and when you claim not affected, a justification is required — one of the standard CSAF reasons, like “vulnerable code not in execute path.”
When you’ve authored your statements, Publish VEX (CSAF 2.0) assembles them into a real OASIS CSAF 2.0 VEX document and downloads it — the same builder Talarity uses for security advisories, recast to the csaf_vex profile. It refuses to publish an empty document.
Step 5 — Verify build provenance (SLSA)
Under Record provenance, paste a SLSA / in-toto attestation (DSSE-wrapped or a bare statement). Talarity verifies its structure and checks that the subject digest matches the artifact — a mismatch fails loudly. The result is recorded honestly: a bare, unsigned attestation shows a verification state of Unsigned, meaning the structure and subject digest were verified but cryptographic signature verification is not yet enabled. Nothing is ever labeled “Verified” that wasn’t.
Step 6 — Enforce composition policy
Beyond CVEs, you often care about what licenses you’re shipping. Composition policies flag components by license, package name, ecosystem, or purl. A block rule flags anything that matches; an allow rule builds an allowlist, so anything matching no allow rule is flagged.
Run the policies from a document’s Evaluate composition. Here the release is checked against one block policy and the GPL-licensed readline component is flagged. The same modal offers a Check known vulnerabilities (OSV.dev) button — a single live lookup against the public OSV.dev database, read-only.
Step 7 — Diff two releases
Group releases into a Product, then Compare releases to see exactly what changed between any two — added, removed, and changed components, plus the known-CVE delta. This is where the security story of an upgrade becomes obvious: moving from 2.4.0 to 2.5.0 here resolves CVE-2021-44228 (the log4j upgrade) and drops the GPL-licensed readline.
Step 8 — Hand the buyer one bundle
Finally, Export procurement bundle assembles the SBOM, the CSAF-VEX, and the SLSA provenance into a single JSON bundle — the artifact a federal buyer asks for under EO 14028 and OMB M-22-18. One download answers “what’s in it, what’s exploitable, and how was it built.”
What you walk away with
A supply-chain program that lives in one place instead of five: ingest → inventory → correlate → VEX → provenance → policy → diff → procurement bundle. Every claim on the page is one the product actually keeps — correlation only surfaces CVEs you already track, VEX is real CSAF 2.0, provenance states are honest, and the procurement bundle is a genuine assembly of the three. Generate the SBOM in your pipeline; do everything after it here.