SBOM Operations: Keeping Your Software Bill of Materials Alive After the First Export

Most manufacturers have crossed the first SBOM threshold by now: pick a format, run a generator, produce a file. If you have not, start with our introduction to SBOMs under the CRA and come back.

This post is about what happens after that first export — because the Cyber Resilience Act does not ask for an SBOM. It asks, in effect, for an SBOM per product, per version placed on the market, kept truthful for the life of your technical file, and actually used as the front end of your vulnerability-handling process. That is an operations problem, not a tooling problem, and it is where most SBOM programmes quietly rot.

What the Regulation Actually Requires

Getting the legal baseline precise helps you size the operational work:

The core duty. Annex I, Part II(1): manufacturers must identify and document vulnerabilities and components in the product, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies" of the product. This obligation applies for the entire support period (Article 13(8)).
Where it lives. The SBOM is part of the technical documentation (Annex VII(2)(b)). It is handed to a market-surveillance authority on reasoned request (Annex VII(8)) — it does not have to be published. Making it available to users is your choice; if you do, Annex II(9) requires you to say where it can be accessed.
Format. "Commonly used and machine-readable" in practice means CycloneDX or SPDX. The Commission may specify format and elements by implementing act (Article 13(24)), so pin your pipeline to a mainstream format that tracks those specifications rather than something homegrown.
Definition. Article 3(39) defines the SBOM as "a formal record containing details and supply chain relationships of components included in the software elements" of the product. Relationships included — a flat list of names is the floor, not the target.

Two clarifications worth internalising. First, "top-level dependencies" is a minimum. An SBOM that stops at top level will not tell you whether you ship a vulnerable transitive library four levels down — and most real-world incidents (Log4Shell being the canonical example) live in exactly that blind spot. Build to full dependency depth; report at whatever depth the eventual implementing act demands. Second, the SBOM duty is continuous: it must describe the product as shipped, for every version you place on the market, not the product as it looked at the last compliance review.

Principle 1: The SBOM Is a Build Artefact, Not a Document

The single decision that separates working SBOM programmes from decorative ones: the SBOM is generated by the release pipeline, from the same dependency resolution that produced the binaries, and stored alongside the build artefact it describes.

If the SBOM is produced by hand, quarterly, or from a different environment than the release build, it will drift — and a drifted SBOM is worse than none, because it gives you confident wrong answers during an incident.

Concretely:

Generate on every release candidate, in CI, after dependency lockfiles are resolved.
Fail the build if generation fails. An unbuildable SBOM is a release blocker, same as a failing test.
Version and retain the SBOM with the release: product-1.8.2.cdx.json lives wherever product-1.8.2 lives, for as long as the technical file must exist — at least ten years after placing on the market or the support period, whichever is longer (Article 13(13)).
Include firmware and container layers, not just application code. The obligation covers the product's software elements, and your base image is part of what you ship.

Principle 2: Quality Is Measurable — Measure It

An SBOM can be schema-valid and still operationally useless. The failure modes are consistent enough to lint for:

Missing or ambiguous identifiers. Every component needs an identifier a vulnerability database can match — a package URL (purl) and, where applicable, a CPE. A component named "crypto-lib" with no purl cannot be correlated with anything.
NOASSERTION sprawl. SPDX tools happily fill unknown suppliers and licences with NOASSERTION. A few are honest; hundreds mean your generator does not understand your build.
Missing versions. A component without a version cannot be checked against an advisory's affected range. This is the most common and most damaging gap.
Stale metadata. Product name, version, supplier, and timestamp of the SBOM itself must match the release it claims to describe.

Put a quality gate in the pipeline: minimum percentage of components with purl + version + supplier, zero unresolved top-level dependencies, metadata consistency with the release tag. Track the score over time like test coverage.

Principle 3: An SBOM You Do Not Monitor Is Paperwork

The reason the CRA wants the SBOM is Part II(1)'s opening clause: identify and document vulnerabilities. The SBOM is the input; continuous matching against vulnerability intelligence is the process:

Correlate every supported release's SBOM — not just the latest — against advisory feeds (NVD, OSV, GitHub Security Advisories) on a schedule measured in hours, not weeks. Your users run old versions; your obligations cover them for the support period.
Prioritise with exploitation evidence. CVSS alone over-alarms. Feeds like CISA KEV and EPSS tell you what is actually being exploited — which matters doubly under the CRA, because an actively exploited vulnerability in your product (Article 3(42)) triggers the Article 14 reporting clock: 24 hours to the early warning once you become aware.
Record triage decisions in VEX. Most matches will not be exploitable in your product ("vulnerable function never called", "component not present in shipped configuration"). A VEX (Vulnerability Exploitability eXchange) record — CycloneDX has it built in, or use OpenVEX alongside SPDX — turns each triage from a Slack message into a durable, machine-readable statement you can show an authority. Under Article 13(7), you are required to systematically document relevant cybersecurity aspects including vulnerabilities you become aware of; VEX is the natural format for that trail.
Report upstream. When triage finds the vulnerability lives in a third-party or open-source component you integrate, Article 13(6) requires you to report it to the component's maintainer — and if you developed a fix, to share the code or documentation with them.

Principle 4: One Product, Many SBOMs — Plan the Cardinality

Teams consistently underestimate how many SBOMs "one product" produces: per version still in support, per platform variant, per deployment form (container vs. installer vs. firmware). A product with three variants, monthly releases, and a five-year support period is a four-digit SBOM archive by end of life.

That cardinality is why manual processes fail. The archive needs to be queryable in one direction above all: "which shipped versions contain component X in an affected version range?" That query is the first question of every incident, and answering it in minutes rather than days is the practical difference between meeting and missing a 24-hour early warning.

A Reference Pipeline

Putting it together, the steady state looks like this:

CI resolves dependencies and builds the release.
SBOM generated from the resolved graph; quality gate enforced; SBOM stored with the artefact and registered in a searchable inventory.
Scheduled correlation of all in-support SBOMs against advisory feeds, enriched with KEV/EPSS.
Matches triaged; outcomes recorded as VEX; exploitable findings flow into the vulnerability-handling process — fix "without delay" (Annex I, Part II(2)), disclose per your CVD policy, and if evidence of active exploitation appears, start the Article 14 workflow immediately.
Technical file references the SBOM archive; the Annex VII documentation stays pointed at living data instead of a snapshot.

None of the steps is exotic. The discipline is in running all five, for every release, for years.

How Seentrix Fits In

Seentrix ingests the CycloneDX or SPDX files your pipeline already produces — per product, per release — and does the unglamorous middle of this post for you: quality checks on ingest, a searchable component inventory across every version you still support, continuous correlation against vulnerability feeds, and triage workflows whose outcomes are stored against the exact SBOM and release they concern. When a match looks like active exploitation, the incident workflow with the Article 14 deadlines is one step away, pre-filled with the affected products and versions.

What the platform cannot do is generate the SBOM for you — that has to happen in your build, from your dependency graph, or it will never be true. Get that one step right in CI, and everything downstream becomes tractable.