Software Dependencies and SBOM

A development team writes a fraction of a modern application's code; the rest comes from external libraries. Those libraries pull in further libraries, and after a few levels nobody knows what actually runs.

The problem becomes visible when a serious vulnerability is found in a widely used component and the question is whether your system is affected.

Why that is hard to answer

Transitive dependencies. Behind the ten directly referenced libraries sit hundreds more. The vulnerability is typically in a deeper layer.

Version drift. The developer machine, test environment and production do not necessarily run the same version.

Containers. Beyond the application, the base image contains packages with their own vulnerabilities.

Legacy systems. What has run for years untouched typically has no inventory at all.

What an SBOM is

A Software Bill of Materials is an inventory of a software's components: which component, at which version, under which licence. In machine-readable format (CycloneDX or SPDX), so it can be matched automatically against vulnerability databases.

An SBOM protects against nothing by itself. Its value is that when a new vulnerability appears you can answer in minutes whether you are affected, rather than searching for days.

How to introduce it

1. Generate during build. Most package managers and build tools have SBOM generators. The key is making it part of the build rather than a separately run task, otherwise it goes stale.

2. Store tied to versions. Every released version should have an SBOM. If a question arises three months later about the February release, you must be able to look.

3. Automated matching. The SBOM must be compared against vulnerability databases regularly. Once at build time is not enough, because new vulnerabilities appear later.

4. Request supplier SBOMs. If you use purchased software, ask for its SBOM. This is an increasingly common contractual expectation.

Prioritisation

Dependency scanning on a medium application returns hundreds of findings. The same logic applies as in general vulnerability management:

• Is the vulnerable code reachable? If the library is present but the application never calls the affected function, risk is materially lower. Some tools analyse this.
• Is there active exploitation? The CISA KEV list is the best filter here too.
• Is the component reachable externally? A flaw in an internal utility is not the same as one in a public API.

We covered this in detail in our vulnerability management article.

Supply chain risk

Dependencies carry not only vulnerabilities but attack surface:

Typosquatting packages. The attacker publishes a package with a name similar to a popular one, hoping someone mistypes.

Taken-over packages. An abandoned but widely used package is taken over and malicious code added.

Build chain compromise. Not the package but the build process is subverted.

Pinning package versions (lockfiles), an internal package mirror and isolating the build environment defend against these.

What to measure

• Whether an SBOM exists for every production system
• How many open KEV-listed component vulnerabilities exist
• Mean time from vulnerability disclosure to update
• What percentage of production images are scanned

Our IT security services include reviewing the security of the development process.