DevSecOps and Software Supply Chain
SBOM Management
We set up a process to generate an SBOM at build time for every release. When a new vulnerability is announced, you identify affected products and versions with a single query.
What it is
An SBOM is a standardized record of the components in a software release and their supply chain relationships. SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424) are the two standard formats. Its value comes from generating it at build time for every release and storing it for queries. This allows the impact of a new vulnerability to be determined without asking each team individually.
Scope
- SBOM generation in SPDX or CycloneDX format for every build
- SBOM collection for container images and purchased software
- SBOMs stored and mapped to their release, and made searchable
- Continuous mapping of newly announced vulnerabilities to SBOMs
- VEX statements for unaffected products
- Rules for sharing SBOMs with customers and auditors
The need
When organizations need it
- When offering software-based products in the EU market and needing to prepare for the SBOM required by the Cyber Resilience Act.
- When a corporate customer or tender specification requests the SBOM for your delivered software.
- When it takes days to identify affected products after a critical library vulnerability is announced.
Method
How we work
-
Sources
We list your products, build pipelines, and deployed images.
-
Generation
We add SBOM generation to every build and define the format and minimum content.
-
Storage and matching
We store SBOMs mapped to their release and set up automatic matching with new vulnerabilities.
-
Response process
We document who assesses a match and how customers are informed.
Outcome
What you have at the end
An SBOM is produced and stored for every release. When a new vulnerability is announced, affected products and versions are found by query, and your customers receive a reasoned response.
Frequently asked questions
Do we have to disclose our SBOM to everyone?
The Cyber Resilience Act requires preparing the SBOM and keeping it in technical documentation. Public disclosure is not mandatory. Sharing with customers depends on your contracts and policy.
What is VEX and why is it needed?
VEX is a machine-readable statement indicating whether a product is affected by a specific vulnerability. If a vulnerable component appears in the SBOM but the product is not affected, VEX allows you to inform customers with the reason.
Is producing an SBOM once sufficient?
No. Components change with every release. The SBOM must be generated for every build and stored with the corresponding release.
DevSecOps and Software Supply Chain
Other services in this area
Let's talk about this service.
Tell us briefly what you need. We will agree on the scope and timing together in the first meeting.
Schedule a Meeting