What is an SBOM and why knowing every project dependency matters

Hook

An SBOM is an inventory of what your application is actually made of. Not only your own code, but libraries, transitive dependencies, versions, licenses, and components the team may not look at every day.

When a new CVE appears, the first practical question is not “is this scary?” but “do we have this component?”. That is the exact moment where an SBOM earns its keep.

Problem / Context

Modern projects are rarely built from scratch. Even a small web application can pull hundreds of packages through npm, pnpm, pip, Maven, Go modules, Docker images, or system packages. Some dependencies were added directly by the team. Others arrived through other libraries.

While everything works, this layer stays mostly invisible. Then a high-profile CVE appears in a popular library, the security team asks about exposure, a customer asks for proof, and the team starts searching through the lockfile, container image, CI logs, and old release notes. Without an inventory, response becomes slow and stressful.

An SBOM moves the team from “we think we do not use it” to “here is the component list and versions”. It does not fix vulnerabilities by itself. It gives you the map that makes dependency audit possible without guessing.

Why it matters

SBOM matters not because it is a fashionable compliance document. Its value is practical.

First, it speeds up CVE triage. If a vulnerability affects a specific library version, the team can quickly check whether that version exists in the production artifact. That is better than manually comparing package.json, the lockfile, and Docker layers under pressure.

Second, SBOM reveals transitive dependencies. This is where surprises often live: the team did not install a package directly, but it entered the build through another library. From a security point of view, that distinction does not help much. If the component is in production, it belongs in the risk model.

Third, SBOM helps teams talk to customers, auditors, and internal security without hand-waving. Instead of “we will check”, the team can show a process: SBOM is generated at release, SCA scans the components, and critical findings flow into backlog or incident handling.

One more benefit: dependency inventory disciplines releases. If a team cannot explain what it ships to production, that is already a warning sign for software supply chain visibility.

The mental model

Think of an SBOM as the parts list for an assembled bicycle. Frame, wheels, brakes, chain, manufacturer, model, and version. If a brake batch later turns out to be defective, you do not inspect the bicycle randomly. You check the inventory.

For software, the picture looks like this:

• application code;
• direct dependencies the team added explicitly;
• transitive dependencies that arrived through them;
• package manager and lockfile;
• build artifact or container image;
• SBOM in CycloneDX or SPDX format;
• SCA check that compares components with known vulnerabilities.

The important detail is that an SBOM should describe the real artifact, not an idealized view of the project. If production is shipped as a Docker image, an SBOM for the image or release artifact is usually more useful than one generated only from the source tree.

How to do it

1. Choose the source of truth

Start by deciding what the SBOM is generated from. For Node.js, that may be the lockfile. For container-based deployment, it may be the image. For a monorepo, you may need separate SBOMs per service or one aggregated report.

A weak approach is manually maintaining a dependency list in README. It will drift. A better approach is generating the SBOM automatically from the package manager, lockfile, or artifact.

Useful questions:

• what exactly reaches production;
• where exact versions are pinned;
• which build steps add components;
• whether system packages exist inside the container image;
• whether frontend, backend, and infrastructure modules need separate inventories.

2. Pick a format

The two names you will most often see are CycloneDX and SPDX. For most teams, the priority is not debating formats for a week. Pick the one supported by your tools, customers, and CI/CD workflow.

CycloneDX is commonly convenient for application security and supply chain checks. SPDX is widely used for software materials, licenses, and provenance. In real life you may eventually need both, but starting with one format is fine if it solves the current workflow.

3. Generate SBOM in CI/CD

SBOM should be part of the release workflow, not a manual command someone runs when they remember. A minimal flow:

1. install dependencies from the lockfile;
2. build the application or image;
3. generate the SBOM;
4. run SCA or a vulnerability scan;
5. store the SBOM as a release artifact;
6. block the release only on critical rules the team is ready to maintain.

For a local start, teams can use tools such as Syft, Trivy, CycloneDX generators, or built-in platform features. The tool name matters less than repeatability.

4. Check direct and transitive dependencies

After the first generation, do not trust the file blindly. Verify a few things:

• the report includes the main direct dependencies;
• transitive dependencies are visible;
• versions match the lockfile;
• system packages from the image are included when relevant;
• dev-only packages do not appear in the production SBOM unless they ship with the release;
• it is clear which commit or release this SBOM describes.

If an SBOM cannot be tied to a specific release, its value drops fast. A month later, nobody will remember which file described which build.

5. Connect SBOM with SCA

SBOM is the inventory. SCA is the check that compares the inventory with known problems. Together they create an actionable security picture.

A useful workflow:

• SBOM says the component exists in a release;
• SCA finds a CVE for that component;
• the team checks whether the vulnerable part is actually reachable;
• if context is needed, VEX captures it;
• the ticket is prioritized by real risk, not only headline volume.

This matters because not every CVE is equally dangerous for every product. But without an SBOM, it is hard to even start the right conversation.

Common mistakes

• generating an SBOM once and forgetting it;
• describing the source tree while production is built from a different image;
• leaving out transitive dependencies;
• storing an SBOM without a commit, tag, or release link;
• confusing SBOM with an SCA report;
• blocking every non-critical finding and breaking delivery;
• ignoring licenses because “this is only security”;
• failing to separate dev dependencies from production dependencies;
• keeping the SBOM only on a developer laptop.

Conclusion / Action Plan

SBOM does not make a project secure automatically. It makes the project visible. Visibility is the first step toward sane response to CVEs, license questions, and supply chain incidents.

Start small:

1. identify which artifact actually reaches production;
2. generate an SBOM from the lockfile or image;
3. choose CycloneDX or SPDX;
4. add generation to CI/CD;
5. store the SBOM next to the release;
6. connect it to SCA;
7. agree which findings block a release;
8. test the workflow against one known CVE.

If a critical vulnerability in a popular library appears tomorrow, a team with an SBOM can answer calmly: “we checked, here is the version, here is the impact, here is the action”. That is why the inventory matters.

Official sources:

• https://www.cisa.gov/sbom
• https://www.ntia.gov/page/software-bill-materials
• https://cyclonedx.org/
• https://spdx.dev/
• https://owasp.org/www-community/Component_Analysis