Understanding the Software Bill of Materials in one read
If your product needs compliance documentation because of the EU Cyber Resilience Act (CRA), the SBOM is only one piece of that picture; the specific regulatory relationship between SBOM and the CRA, and the format requirements, are covered in a separate dedicated article. This piece first clears up the term “SBOM” itself.
“Please provide the SBOM for your product as part of the pre-purchase security review documentation.” — this sentence has been appearing more and more often in customers’ emails and audit checklists. When most engineering or sales managers see it, their first reaction is usually not to look up how to prepare one, but to freeze for a second: “SBOM? Have we been missing something?”
The answer is usually less complicated than feared. An SBOM is not something that requires new development work to produce. It is simply “which software components are actually inside our product”, written down as a structured, machine-readable list. Most manufacturers already have this information — the only question is whether it has been organised into a format customers can read and systems can parse.
SBOM stands for Software Bill of Materials. Conceptually it is very close to the ingredients label on food packaging, or to the bill of materials (BOM) that manufacturing has always used — except that what is being listed is software. An SBOM records which components a software product uses (open-source libraries, third-party packages and so on), each component’s version and supplier, and the dependency relationships between components.
The problem it solves is very concrete: when a widely used open-source package is hit by a major vulnerability, can the manufacturer answer immediately: “Is that package in our product? Which version?” If the answer has to be pieced together by engineers digging through code and phoning suppliers one by one, the golden response window is usually already gone. With an SBOM, that comparison can be done in minutes.
The term SBOM has existed for many years, but only in the last year or two has it become a standard contractual requirement. Three forces are driving this:
Not every “software list” counts. An SBOM that customers, auditors or scanning tools can actually use typically needs to satisfy several conditions:
1. An SBOM is not a sign-once, valid-forever document. Whenever the product ships a new version or a new build, a corresponding SBOM should in principle be regenerated — otherwise the list quickly drifts away from what is actually shipping.
2. “Having records” is not the same as “having an SBOM”. A dependency list privately maintained by the engineering team, if it is not machine-readable and lacks versions and identifiers, is still some distance away from a qualifying SBOM.
3. The SBOM is the manufacturer’s own inventory to build — you cannot just wait for upstream suppliers to hand it over. Which components your product uses is ultimately your responsibility towards your customer — and incomplete upstream information is precisely where SBOM projects most often get stuck.
One day the security team sends out a notice: a widely used open-source library has been hit by a major vulnerability. The R&D manager’s first thought is: “Is that package actually in our products?” Without an SBOM, this question is typically answered by engineers combing through code and asking suppliers one by one, and it can take days to piece together. With a structured SBOM at hand, one comparison run tells you within minutes which products and which versions are affected — response time compressed from “days” to “minutes”.
An overseas customer’s security due-diligence questionnaire has a row that says “please provide the product SBOM”. If you don’t have one, the common outcomes are a demand to supply it within a deadline, delays to the whole procurement process, or being recorded outright as a risk gap that weighs on the evaluation of any future cooperation. Conversely, if you can immediately attach an SBOM in SPDX or CycloneDX format, the audit usually runs far more smoothly — and the customer gains confidence in your supply-chain governance.
Misconception 1: “SBOMs are only for special industries like defence and critical infrastructure.” That impression comes from the settings where SBOMs were first widely required, but the requirement has since spread to ordinary commercial products — wherever the customer runs a security procurement review, or the product is subject to specific regulations, an SBOM may be demanded.
Misconception 2: “Our product doesn’t really use open-source software, so we probably don’t need one.” An SBOM covers all software components, not just open-source packages; in-house modules and supplier-provided firmware are in scope in principle, as long as they are part of the product.
Misconception 3: “Do the SBOM once and you’re done forever.” An SBOM reflects which components the product uses right now. The moment the product is revised, the old list no longer matches the shipped version. Seen from the customer’s side, an SBOM generated three years ago and never updated is not just useless — in a security review it tends to be read as “this supplier has a version-control problem”.
If your company does not yet have a systematic SBOM-generation process, the pragmatic opening moves are usually:
If you have finished the inventory but are unsure which format or which depth of SBOM to target, or would like a professional review, feel free to contact us — our consultants can help assess your specific case.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: What is an SBOM? An SBOM (Software Bill of Materials) is a structured list recording which components a software product uses, their versions, their sources and their mutual dependencies. Conceptually it is very similar to the ingredients label on food packaging.
Q: Why is every customer asking for an SBOM now? Three main factors: frequent supply-chain attacks have made buyers want to know “what is inside the product”; regulations are steadily adding the requirement; and corporate procurement security questionnaires now list the SBOM as a mandatory field rather than a bonus item.
Q: Are SBOMs only needed for defence and critical infrastructure? No. That impression comes from the settings where they were first required, but the practice has spread to ordinary commercial products — wherever the customer has a security procurement review process, or the product is bound by specific legal requirements, you may be asked to provide one.
Q: Is an SBOM a one-and-done exercise? No. An SBOM reflects the components the product uses at that moment; once the product is redesigned, the old list is out of date. An SBOM that has gone years without an update is likely, in a customer review, to be read as a warning sign of poor version control.
The concepts and normative sources cited in this article are based on the following documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. Final compliance determinations for specific cases remain subject to official EU documents and the interpretations of the competent authorities.
