CRA readiness · · 5 min read
The first SBOM run is usually a success. The second one, three months later, is where the gap between having a tool and having a process becomes visible.
Nearly every SBOM programme we have seen clears its first hurdle without difficulty: point a scanner at the build, get a component list, present it as evidence of progress. The programme stalls afterwards, usually within one or two release cycles, and the failure is rarely technical.
An SBOM is treated as a document to produce rather than data to maintain. Producing it once satisfies an immediate request. Maintaining it requires a decision about who reviews new findings, on what cadence, and what authority they have to block a release over an unresolved dependency. That decision is usually the part nobody made before the first run, which is why it is also the part that is missing three months later.
An SBOM that cannot be queried against a shipped version by Friday afternoon is not yet an operational capability.
Generation belongs in the build pipeline, not in a person's calendar. A single format across the portfolio, even an imperfect one, is worth more than a precise format used inconsistently. Someone with the authority to say no owns the triage queue. And the inventory is tied to a version identifier that support and security teams already use, so answering a real question about a real release does not require a special exercise.
CRA SCOPE CHECKER
Enter your website. We read what you make and sell, then ask only the few questions the regulation turns on.
About 60 seconds. No account. PDF report on request.
CRA readiness
The reporting duties arrive well before the main obligations. They are the first point where a product organisation is measured on process, not intention.
System safety
Most programmes have traceability on paper. Fewer can follow a single hazard to the verification that closed it without a manual reconstruction.
Engineering practice
When safety and product security work in separate structures, the contradictions surface late — usually in a customer review.
CRA readiness
The template for a technical documentation pack is public. What is not public is which sections a reviewer actually reads twice.
System safety
Run separately, the two standards produce two item definitions, two review cadences and two sets of evidence that quietly contradict each other.
System safety
A hazard analysis that stops at a mitigation statement has done half the job. The other half is writing something a test engineer can act on.
CRA readiness
Most organisations can produce a vulnerability handling policy on request. Fewer can produce evidence that it was followed on the last three findings.
System safety
A safety case is usually written as an argument about a specific, frozen configuration. Continuous updates make that assumption false on day one.