Software Bill of Materials (SBOM): Why It's Crucial for Supply Chain Security
A Software Bill of Materials (SBOM) is no longer just a compliance checkbox—it's a critical defense mechanism against supply chain attacks. Discover why SBOMs are essential, how they protect against hidden vulnerabilities, and how Adayptus can automate your SBOM creation.
When a critical vulnerability lands in a widely used open-source component, the organisations that respond in hours are not the ones with better security teams. They are the ones who could answer the question "do we use it?" without convening a war room and asking every engineering team to check.
That is what a Software Bill of Materials is for. It is an inventory of the components in a piece of software — direct dependencies, transitive dependencies, versions, licences and origin. Unglamorous, and the difference between a coordinated response and a week of uncertainty.
This guide covers what an SBOM contains, why generating one is the easy part and consuming it is where value lives, the formats and where each fits, the regulatory direction of travel, and how to build the capability without adding another dashboard nobody reads.
- 01The value is answering "do we use it?" in minutes when a critical vulnerability is disclosed.
- 02Generating an SBOM is easy; consuming and querying it is where organisations stall.
- 03Most risk sits in transitive dependencies nobody chose and nobody tracks.
- 04An SBOM is a point-in-time artefact — generate per build, or it describes software you no longer ship.
- 05Pair it with reachability analysis, or you will triage vulnerabilities in code that never executes.
Why This Became Urgent
Modern applications are assembled more than written. A typical service may contain a few thousand lines of your own code and hundreds of third-party packages, most of which arrived as dependencies of dependencies. Nobody on the team chose them, and in many cases nobody knows they are present.
This creates two distinct risks. The first is known vulnerabilities in components you ship — the ordinary case, manageable if you know what you have. The second is deliberate compromise: a package taken over by a malicious maintainer, a typosquatted name, or a build system tampered with upstream. Attacks of this kind are attractive precisely because a single compromised package reaches everyone who depends on it, and they have repeatedly hit package ecosystems including npm, PyPI and Packagist.
In both cases, the first question is the same and most organisations cannot answer it quickly.
What an SBOM Actually Contains
| Element | Why it matters |
|---|---|
| Component name and version | The minimum needed to match against a disclosed vulnerability |
| Unique identifier | Package URL or CPE, so matching is not guesswork across naming conventions |
| Dependency relationships | Distinguishes what you chose from what arrived transitively |
| Supplier and origin | Provenance, and exposure to a compromised maintainer |
| Licence | Legal exposure, often the reason finance sponsors the work |
| Cryptographic hashes | Verifying the component is what it claims to be |
The dependency relationship data is the part most often discarded and most often needed. Knowing that a vulnerable library is a transitive dependency four levels deep tells you that you cannot simply upgrade it — you must wait for an intermediate maintainer, or override the resolution and accept the compatibility risk.
Generation Is Easy. Consumption Is the Problem.
This is the failure mode we see most often. An organisation adds SBOM generation to the build, produces a file per release, stores them, and has achieved almost nothing — because when a vulnerability is disclosed there is no way to ask "which of our products, in which versions, currently deployed where, contain this component?"
An SBOM only creates value if it is queryable across your estate. That means storing them in something searchable, linking each to the deployment it corresponds to, and continuously matching contents against vulnerability feeds so that a newly disclosed issue surfaces automatically rather than prompting a manual hunt.
The test that matters: a critical vulnerability is announced in a common library at 9 a.m. Can you produce a list of affected products and deployed versions before the first customer email arrives? If the answer involves messaging engineering leads, you are generating SBOMs rather than using them.
Formats and Where Each Fits
Two formats dominate and the choice is less consequential than it appears, since tooling converts between them.
SPDX is an ISO-standardised format with strong licence-compliance heritage, and tends to be preferred where legal and procurement requirements drive the work. CycloneDX originated in the security community and carries richer vulnerability and dependency-relationship data, which suits security-led programmes.
If your driver is procurement or regulatory response, ask the requesting party which they want. If it is internal security, CycloneDX is usually the more natural fit. What matters far more than the choice is generating consistently per build and using unique identifiers such as package URLs, so matching does not depend on string comparison across inconsistent naming.
Reachability: Avoiding Alert Fatigue
A complete SBOM matched against vulnerability feeds will generate a large number of findings, and most of them will not matter. A vulnerability in a code path your application never invokes is present but not exploitable, and treating it as urgent burns credibility with engineering teams quickly.
Reachability analysis — determining whether the vulnerable function is actually called in your application — reduces that volume substantially. The related mechanism is VEX, an exploitability statement allowing you to record and communicate that a given vulnerability does not affect your product, and why. That matters when a customer asks about a headline CVE and you need a defensible answer rather than an upgrade you did not need.
Without this layer, SBOM programmes tend to collapse under their own output — which is the same dynamic that made traditional vulnerability scanning unpopular, discussed in our guide to vulnerability assessment versus management.
The Regulatory Direction
Software transparency expectations are consolidating rather than fading. US federal procurement has established SBOM expectations for software suppliers, the EU Cyber Resilience Act introduces obligations for products with digital elements sold into the EU, and IEC 62443-4-1 requires component and supply chain management from industrial product suppliers.
For Indian organisations there is an additional practical driver. CERT-In's six-hour incident reporting window assumes you can characterise an incident quickly, and a supply chain compromise you cannot scope is difficult to report meaningfully. Enterprise procurement is also moving faster than regulation here — security questionnaires increasingly ask for an SBOM regardless of any legal obligation.
Building the Capability
- 01Generate an SBOM per build, in the pipeline — not periodically by hand.
- 02Capture transitive dependencies and relationships, not just direct ones.
- 03Store them somewhere queryable across the whole estate, linked to deployments.
- 04Match continuously against vulnerability feeds so new disclosures surface automatically.
- 05Add reachability analysis before the finding volume destroys engagement.
- 06Record VEX statements so "not affected" is documented and communicable.
- 07Request SBOMs from your own suppliers — their dependencies are your exposure.
- 08Rehearse the disclosure drill — pick a real CVE and time your answer.
The drill in item eight is the cheapest way to find out whether the programme works. Pick a component you know you use, treat it as newly vulnerable, and measure how long it takes to produce a definitive list of affected deployments. That number is your actual capability.
How Adayptus Helps
- SBOM Creation — pipeline-integrated generation with complete transitive coverage.
- SBOM Risk Analysis — continuous matching, reachability and prioritisation.
- Digital Supply Chain Security — the broader programme, including build integrity.
- CI/CD Security Review — securing the pipeline that produces your artefacts.
- Third-Party Risk Management — extending the same discipline to your suppliers.
- Secure Code Review — for the code your dependencies cannot account for.
Related reading: malicious packages in the Packagist ecosystem and our secure code review guide.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is an SBOM and why do we need one?
A Software Bill of Materials is an inventory of the components in a piece of software — direct and transitive dependencies, versions, licences and origin. Its practical value is answering "do we use this?" within minutes when a critical vulnerability is disclosed, instead of messaging every engineering team and waiting. Modern applications contain hundreds of third-party packages that arrived as dependencies of dependencies, and most organisations cannot enumerate them on demand.
QSPDX or CycloneDX — which format should we use?
Less consequential than it appears, since tooling converts between them. SPDX is ISO-standardised with strong licence-compliance heritage and suits legal or procurement-driven work; CycloneDX originated in the security community and carries richer vulnerability and dependency-relationship data. If a customer or regulator is asking, use what they request. What matters far more is generating consistently per build and using unique identifiers such as package URLs so matching does not rely on string comparison.
QHow often should an SBOM be generated?
Per build, generated automatically in the pipeline. An SBOM is a point-in-time artefact describing exactly what a specific build contained, so one produced periodically by hand describes software you may no longer ship. Generating in the pipeline also guarantees accuracy, because it reflects what was actually resolved and packaged rather than what a manifest file declared should be included.
QWhy do SBOM programmes fail?
Because generation is treated as the goal. Organisations add SBOM output to the build, store the files, and still cannot answer which products in which deployed versions contain a newly vulnerable component. Value requires storing SBOMs somewhere queryable across the estate, linking each to its deployment, and matching continuously against vulnerability feeds. The second failure is skipping reachability analysis, which floods teams with findings for code that never executes.
QWhat is VEX and do we need it?
VEX is an exploitability statement recording that a given vulnerability does not affect your product, and why — for example because the vulnerable function is never invoked. It matters commercially: when a customer asks about a headline CVE in a component you ship, VEX gives you a documented, defensible answer instead of an unnecessary emergency upgrade. It also prevents the same question being re-analysed by a different engineer three months later.
QAre SBOMs becoming a regulatory requirement?
The direction is clearly toward transparency obligations. US federal procurement has established SBOM expectations for software suppliers, the EU Cyber Resilience Act introduces requirements for products with digital elements, and IEC 62443-4-1 requires component and supply chain management from industrial suppliers. In practice enterprise procurement is moving faster than regulation — security questionnaires increasingly request an SBOM regardless of any legal obligation to provide one.
Adayptus Security Research
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
