Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
The SCA check on your payments API came back clean this morning, and an hour later a customer asks for the full component list of the exact version they run in production. The scan result cannot answer that request, and this post explains why: software composition analysis and a software bill of materials answer different questions, and you need both working together to respond with confidence.
Software composition analysis (SCA) checks the open-source components in a build against vulnerability and licence data, and tells you what is risky today. A software bill of materials (SBOM) is the durable inventory of what one artefact contains. SCA is a verdict that changes as advisories are published; the SBOM is a record that does not.
SCA answers whether a build carries known risk today
Software composition analysis resolves a project’s declared and transitive dependencies, identifies each component by name and version, and checks those pairs against vulnerability data. When a match lands, it reports the component, the advisory and, usually, a version that fixes it. For the payments API, that is a clear answer to a narrow question: does this build contain anything with a known vulnerability right now?
The “right now” matters. Vulnerability data changes independently of your code, so yesterday’s clean result can be wrong today without a single commit landing. That is not a weakness of SCA; it is why you run it on every build and treat each result as a snapshot of risk against the data available at that moment. A vulnerability verdict alone is not a durable composition record, although many SCA tools also generate and retain SBOMs.
An SBOM answers what actually shipped in an artefact
A software bill of materials is an inventory, not a verdict. It records the components identified in a specific artefact, with name, version, supplier, licence and the relationships between components. Where SCA asks whether anything is risky, the SBOM records what is in the artefact, exactly as it was built.
An inventory describes a fixed artefact, but its completeness depends on the generator and inputs; later analysis may correct it. When the customer asks about the payments API version in their environment, an SBOM generated at build time answers directly, even if the repository has moved on and the branch behind that build has been deleted. When a new advisory lands months later, the same record tells you whether that release carried the affected library, without re-scanning source that no longer matches what shipped. SCA describes today’s risk. The SBOM lets you answer composition questions about any artefact at any point in its life.
Transitive dependencies are where SCA and SBOM earn their keep
Engineers generally know their direct dependencies, because those appear in a manifest someone edits. Few have an accurate picture of the tree underneath. The payments API might declare a web framework, an HTTP client and a database driver, and those three quietly bring in serialisation libraries, compression code and cryptographic helpers several layers down. That hidden layer is where most surprises come from.
Both controls have to walk the full tree to be useful. SCA needs it to find the vulnerable component nobody chose on purpose. The SBOM needs it because a list of direct dependencies describes what a person typed into a package file, not what the build produced. If either stops at the first level, it reports a tidy picture of the parts you already understood and misses the parts you did not.
Licence obligations are composition data, not a vulnerability side effect
Composition data also carries licence obligations, and they deserve their own review. A transitive component can bring copyleft terms, attribution requirements or limits on commercial redistribution that your organisation never intended to accept. Those terms attach to the component, not to any advisory, so a clean vulnerability result says nothing about them.
Most SCA tools surface licence metadata alongside vulnerability matches, and a well-formed SBOM records licence as a standard field for each component. The failure mode is treating licence results as noise next to the vulnerability list. If the payments API ships a component whose licence conflicts with how you distribute it, you want your own review to catch that long before a customer’s legal team does.
An SBOM nobody can query is a checkbox, not a control
The common confusion runs in one direction: teams produce an SBOM as a by-product of the SCA step and consider the job done. The file is attached to a pipeline run, never stored against the artefact, never indexed, and effectively lost once the run’s records expire. It satisfies “we generate SBOMs” while failing the test that matters: when an advisory lands, can you check every image you have shipped for the affected component without running anything new?
The reverse confusion is treating an SCA pass as a record of what shipped. A passing gate is a scan outcome, not an inventory. The payments API can pass SCA and still ship components that later matter for a licence review, a customer questionnaire or an advisory nobody had published at build time. Run SCA on every build to catch known risk early, keep an SBOM per artefact as the durable record, and connect the two so a new advisory becomes a lookup. The companion post on tracing a new CVE to the images that shipped it walks through that lookup, and risk-based vulnerability management covers how to order what it finds.
Key takeaways
- Run SCA on every build, because vulnerability data changes even when your code does not.
- Generate an SBOM for every artefact you ship and store it against that artefact’s identity so it can be queried later.
- Check that both SCA and SBOM generation walk the full transitive tree rather than stopping at the manifest.
- Review licence findings as composition data in their own right, not as a footnote to the vulnerability list.
How SecurityVault approaches this
SecurityVault combines supported dependency scans with generated SBOMs and retains the resulting inventory for review and export. Available image-to-workload associations help teams investigate where affected components may be running. Check scan completion, component identification and advisory applicability before relying on an inventory match or a clean result.
Choose a built image and compare its generated inventory with the packages your build process expects. Inspect a transitive dependency, a vendored component and an item with incomplete metadata. Then review the effect of an advisory update without changing the image. The team should be able to distinguish a changed vulnerability assessment from a changed component inventory. Agree how exports are retained and associated with releases so procurement and incident response can retrieve the same evidence later rather than generating inconsistent copies under deadline pressure.
Explore SCA and SBOM or talk to our team about an evaluation with your engineering, security and compliance stakeholders.