SBOM and Software Supply Chain: What a Pentest Shows

An SBOM lists the libraries and components your software is built from, with their versions and where they came from, in a standard format. Two formats are in common use: SPDX and CycloneDX. The list lets you answer a simple question quickly, such as "do we use the version of this library that was just reported as vulnerable?"

Open-source tools read a repository or a container image and produce the list:

syft dir:. -o cyclonedx-json > sbom.json       # list components in a project
grype sbom:./sbom.json                           # match them to known vulnerabilities

Build the SBOM in the pipeline, for every release, and store it with the release. An SBOM made once and never updated is out of date within weeks.

• Direct and indirect dependencies, with versions.
• Which components match a known vulnerability, when combined with a vulnerability database.
• Licenses, which matter for legal review.
• Which of your products are affected when a new vulnerability is announced.

• Whether a vulnerable component can actually be reached. Many reported flaws sit in code your product never calls. A separate statement (VEX, vulnerability exploitability exchange) can record that a flaw does not affect a product.
• Flaws in your own code, in your configuration or in the way components are put together.
• A compromised build or package. An SBOM lists what was included, and cannot tell you that a package was tampered with.
• Components added outside package managers, such as copied code, vendored binaries and firmware, unless the tool is set up to find them.

A penetration test shows whether a vulnerable component is reachable and exploitable in your running product, which an SBOM cannot. For example, the SBOM flags an old logging library, and the tester checks whether attacker-controlled text ever reaches it. A secure code review looks at how you use dependencies and at the pipeline that builds them. A test does not replace an SBOM, and an SBOM does not replace a test.

$ grype sbom:./sbom.json
NAME            INSTALLED  FIXED-IN  TYPE   VULNERABILITY   SEVERITY
example-parser  2.3.1      2.3.4     npm    CVE-XXXX-NNNN   High

The scan flags a parser library. The team asks three questions: is the vulnerable function used, can user input reach it, and is there a fixed version? If the product only uses the library at build time, the risk is low and the team records that decision. If the library parses uploaded files, the risk is real, and the team updates it and asks a tester to try the upload path.

• Can you produce a current list of the components in each product within a day?
• Do you know who owns each dependency decision, and how updates are approved?
• Do you pin versions and keep a lockfile, and does the build verify what it downloads?
• Who can publish to your package registry or change your build pipeline?

Generate the SBOM on every release, scan it on a schedule, record decisions about reachable and unreachable flaws, pin and verify dependencies, restrict who can change the pipeline, and share the SBOM with customers who ask under the terms you agree with them. We cover the supply chain side in source code review and DevSecOps security.

To plan a test for your own systems, request a scoping call, or download the pre-test checklist and scoping questionnaire.

Links checked on 5 November 2026.

• NTIA, The Minimum Elements For a Software Bill of Materials, what a useful SBOM contains
• CycloneDX specification, one of the two common formats
• SPDX specification, the other common format
• SEBI, CSCRF circular of 20 August 2024, SBOM for new software procurement of core and critical activities