A critical flaw in a widely used library becomes public. Product Security asks which product versions are affected. Procurement asks which supplier must respond. Engineering points to a repository containing several SBOM files. Yet nobody can say with confidence which file belongs to which release, whether transitive dependencies are included or who owns the assessment. The list exists. The decision does not.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
That gap is a management issue. A Software Bill of Materials (SBOM) can create transparency about software components, but it is not standalone proof of compliance and does not replace vulnerability management, secure product development or supplier governance. On 29 July 2026, CISA, Germany’s BSI and other international partners published revised Minimum Elements for SBOMs. The 2026 edition supersedes the 2021 NTIA minimum elements; CISA’s 2025 publication was a public-comment draft, not the final version published in 2026. BSI points to its existing TR-03183-2 technical guideline as further guidance but does not say that the guideline itself was updated on that date. At the same time, the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, increases the need for controlled product and vulnerability information. The result is not a magical list standard. It is an operating model.
Under time pressure, that model must answer a straightforward question: which defensible decision can be made from which product data, who makes it and how does it remain traceable? Exporting a file is only the beginning. Without identity, quality, triage and functioning handovers, an SBOM mainly creates a precise-looking form of uncertainty.
An SBOM is a data product, not a storage artefact
A defensible SBOM describes the components of a specific software product at a specific version. To support decisions, it needs identities, relationships, versions, authorship, time context and a machine-readable format. CISA’s 2026 Minimum Elements organise expectations across data fields, automation support, and practices and processes. Compared with the 2021 baseline, additions include the author’s signature; data-format name and version; generation context; tool name and version; SBOM version; component hash value and algorithm; and component licence. That structure makes an important point: even the minimum model does not stop at collecting package names.
CISA frames the Minimum Elements for software broadly, including open-source software, AI systems and Software as a Service. The document notes that AI and SaaS may require additional elements to address their particular transparency and operational characteristics. The minimum fields are therefore a shared baseline, not a promise that the same dataset is sufficient for every type of product.
Organisations should therefore manage each SBOM as a controlled data product. For every released product version, they need to establish where in the build or release chain it is generated, which component types it covers and how product, version, build and SBOM are linked unambiguously. Accountability is also required for quality, approval, retention, permitted disclosure and traceable corrections.
Calling it a data product is not a cosmetic upgrade. It shifts attention from the file to its lifecycle. A data product has a defined purpose, an owner, quality rules, known limitations and consumers. For an SBOM, those consumers may include Product Security, Engineering, Procurement, Legal/Compliance and Support. They use the same underlying data but ask different questions. Support wants to know which customer version might be affected. Engineering needs the technical path. Procurement needs the responsible supplier and a deadline. Without a shared identity, everyone can discuss the same case while referring to different releases.
A folder called “final_sbom_v7_new” meets these requirements in name only. File names have yet to develop an embedded governance committee.
Product and release need to share the same identity
The first control point is attribution. An SBOM without a reliable product, version and build relationship may create more confusion than transparency when a vulnerability is disclosed. A product-security identifier or release key should connect the binary artefact, source state, build provenance, SBOM, approval and later advisories.
That relationship needs to cover variants. Operating-system packages, container images, firmware, white-label products and customer-specific builds may contain different components. A generic “product SBOM” hides those differences. The objective is not to create as many identifiers as possible. It is to establish one stable reference that works across tools and roles.
Consider a clearly hypothetical example. A manufacturer operates a standard image and a customer variant with an additional driver under the same product version. After a vulnerability disclosure, monitoring finds the affected library in the standard image’s SBOM. Customer Support applies the assessment to both variants without checking. It later emerges that only the customer variant contained a different and materially relevant component version. The technical analysis was not fundamentally wrong. It lacked precise release attribution, so the wrong decision was applied to the wrong installed base.
The operational consequences of ambiguous identity are substantial. Teams investigate the same issue twice, customers receive conflicting statements or a measure is tested against the wrong build. Governance therefore starts not with a dashboard but with a dependable answer to the question: “What exactly are we deciding about?”
Data quality is more than syntactic validity
Completeness is not binary. A scanner may miss statically linked, vendored or runtime-loaded components. The organisation therefore needs quality criteria and known limitations. Useful measures can include the proportion of components with automatically resolved identities, undetermined versions, orphaned relationships and releases without an approved SBOM.
Quality also covers freshness, syntactic validity, semantic plausibility and reproducibility. A file can be formally valid while not matching the delivered build. It can contain every mandatory field while omitting a critical relationship between the main product and an embedded component. The right question is therefore not only, “Do we have a file?” but, “Which decisions can this version support, and with what confidence?”
Quality rules also need consequences. A syntax error may block release if downstream tools would otherwise fail to process the SBOM. An unresolved identity does not need to block every release, but it should remain visible and may require approval depending on product criticality or exposure. An organisation can choose its thresholds. The mechanism should not be optional: the issue is detected, assigned to an owner and either corrected or consciously accepted.
In a second hypothetical operating scene, the pipeline creates a valid SBOM but reports twelve components without a determined version. Because the build is green, the release proceeds. Weeks later, a vulnerability notice concerns one of those components. Product Security cannot decide whether the shipped version is affected and must reconstruct the build. The deficiency was visible at release. Without a threshold and escalation route, it was merely documented without consequence. A green pipeline step is a technical status, not a judgement on residual uncertainty.
A CVE match is a starting signal, not a complete answer
A component appearing in an SBOM and matching a CVE does not by itself prove exploitability in the product. Conversely, an incomplete match must not become an all-clear. Product Security needs to assess product context, actual component use, reachable attack surface, existing mitigations and credible exploitation information.
The triage process requires a common case reference and a limited set of possible outcomes. A structured assessment such as affected, not affected, investigation pending or mitigated works well. Each statement needs a rationale, evidence, owner and next review time. Vulnerability Exploitability eXchange (VEX) formats can transport such assessments. VEX is still only as reliable as the analysis underneath it. “Not affected” is not a calming label; it is a claim that requires a reason.
This mechanism matters most when information is incomplete. An open investigation is not a process failure when uncertainty remains visible, accountability is clear and the next decision has a date. A premature all-clear is more dangerous when it turns an absent match into assumed absence of impact. Machines correlate data. The professional statement about the product remains an accountable decision.
Suppose, hypothetically, monitoring reports a match in a library that is present in the image but not called by the product path. Engineering documents the unreachable code path and existing mitigations. Product Security assesses the version as not affected and sets a review point should new exploitation information appear. Months later, a feature is enabled that uses the same path. Good governance treats that product change as a trigger for reassessment. A static VEX statement without a relationship to change would continue to look reassuring after its assumption had expired. Calm is welcome in vulnerability management, but it is not a quality criterion by itself.
Suppliers belong in the same control loop
For third-party software, contracts and operations need to establish which SBOM information a supplier provides, when, in which format and for which version. That includes updates, corrections, vulnerability information, escalation paths and response times. Procurement alone cannot assess technical quality; Product Security alone cannot enforce a supply obligation.
The handover works only if both sides reference the same case. A contract clause without an operational contact offers little help when a notice arrives and nobody knows which product version is concerned or who answers the technical question. An informal channel between engineers is equally fragile when deadlines, corrections and escalation have not been agreed.
Risk-based governance differentiates by product criticality, change frequency, exposure and replaceability. Not every supplier needs the same dataset or cadence, but every exception needs an accountable decision and visible residual uncertainty. Management does not need to read every supplier SBOM. It should be able to see which critical dependencies have weak data and which options follow from that condition.
How the SBOM supports CRA-relevant processes
The CRA requires manufacturers to operate vulnerability-handling processes and maintain technical documentation across the product lifecycle. An SBOM can be a valuable input: it supports inventory, assessment of affected versions, supplier coordination, security-update preparation and traceability of technical decisions.
It does not perform those activities automatically. Accountability, risk analysis, secure development, monitoring, reporting, remediation and user communication remain separate capabilities. Treating the SBOM as the sole CRA proof confuses a map with the journey planner – and occasionally with the vehicle.
The practical governance issue lies in handovers. A vulnerability match must become an assessed product case. Depending on the assessment, that case must lead into a technical measure, supplier escalation, documentation or communication. The SBOM provides structure and a reference, not the decision itself. Nor can the relevant legal or manufacturer role be read from a component list. It needs to be established for the product and its specific context.
A lean SBOM operating model
A workable control loop starts with scope: which products, versions, component types and supply chains are covered? The organisation then defines which build step creates the SBOM and which quality failures block release or require escalation. It registers the approved version with product attribution, access and retention. Monitoring correlates vulnerability or exploitation signals with this inventory. Product Security triages matches, documents uncertainty and initiates action. Response and communication use the same case reference. Findings from false matches, blind spots and delayed responses then change tooling and process.
This sounds linear but operates as a loop. A corrected component identity can change previous matches. A new product function can invalidate an old “not affected” assessment. A supplier response may improve data quality or reveal further uncertainty. The model therefore needs not only a generation point but defined triggers for reassessment.
A sample-based review should follow the complete path for a small number of releases, from the build through the SBOM and a simulated vulnerability match to an approved decision. It should test more than whether tools exchange data. The relevant questions are whether roles reference the same product version, recognise quality limits, document uncertainty and approve an action traceably.
Such a vertical slice shows more quickly than a tool demonstration whether the model operates. The demonstration proves that an export is possible. The slice shows whether a defensible decision emerges under time pressure. Those are different achievements, even when both appear on the same screen.
The management view connects criteria with clear consequences
Management first needs controlled attribution. Products, manufacturer roles, versions and builds must link unambiguously to their SBOM versions. Mandatory quality criteria, known limitations and release escalation rules show how direct, transitive, embedded and supplied components are handled on a risk basis. Generation and validation belong reproducibly in the build or release process.
Decision capability comes next. Every vulnerability match needs a documented triage route with evidence and a deadline. Supplier obligations cover formats, updates, corrections and escalation contacts. Product Security, Engineering, Procurement, Legal/Compliance and Support reference the same case. The organisation also defines which SBOM information remains internal, is shared selectively or is published.
Finally, management needs an honest view of limitations. The model supports CRA-relevant processes without presenting the SBOM as standalone compliance proof. Reporting covers data quality, open investigations, response time and residual uncertainty. A useful metric should point to a possible decision, not merely activity. One hundred generated SBOMs may indicate progress. If five critical releases are not linked to an approved version, the more important information probably sits there.
Conclusion and the A-R-C perspective
An SBOM creates value when it supports the next defensible decision, not when the export completes. Product Security needs controlled product attribution, measurable data quality, professional triage, supplier handovers and traceable actions. The CRA makes those capabilities more urgent but does not replace the governance required to operate them.
A focused A-R-C starting point is an SBOM Governance Vertical Slice. One relevant product and current release are followed from build to a simulated vulnerability match. The outcome is not a conformity promise. It is a prioritised view of data, process, role and evidence gaps.
Scope and limitations
This article provides professional analysis on product security and governance. It is not legal advice, an individual CRA assessment, a conformity assessment, an audit or certification. It offers no legal-compliance, audit or certification guarantee. Specific requirements must be assessed against the product, manufacturer role, jurisdiction and applicable technical specifications.
Primary sources
- BSI, announcement on the revised SBOM Minimum Elements published by CISA, BSI and international partners, 29 July 2026, accessed 2 August 2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Minimum_Elements_SBOM_aktualisiert_260729.html
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), published 29 July 2026, accessed 2 August 2026: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), accessed 2 August 2026: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.