Security Guides

What to do with a software bill of materials

Estimated Reading Time =

2 minutes

Technical Level =

Advanced

Threat Level =

Medium

Attack Type =

Supply Chain Attack

Editorial illustration for what to do with a software bill of materials

What you will learn

What you will learn

A software bill of materials lists components in a product or release. Its value comes from matching that inventory to deployed systems, relevant advisories, owners, and update decisions.

A software bill of materials, or SBOM, lists components included in a software product or build. It can help answer whether a reported component weakness affects something you run. It is an inventory input, not a guarantee that the software is secure.

Understand the idea

Connect the SBOM to the exact release in use. Identify who updates the inventory, compares relevant security notices, and decides what needs action. A component may be present without the vulnerable feature being used, while an incomplete list may miss a real dependency. Context is needed before prioritizing work.

A simple way to follow the process
  1. Inventory

    Link the component list to a specific product version.

  2. Match

    Check whether an advisory affects the actual deployed component.

  3. Action

    Assign a decision, remediation route, and verification step.

A practical example

Imagine a supplier announcing a library vulnerability. The team uses the SBOM for its deployed application to find the library and version, then asks whether the affected code path is used. It records the decision, update owner, and verification plan.

Visual guide: What to do with a software bill of materials
Link the component list to a specific product version. Check whether an advisory affects the actual deployed component. Assign a decision, remediation route, and verification step.

What to do next

  1. Associate the SBOM with a specific product, release, build or digest, supplier, and acquisition date.
  2. Validate that identifiers and versions can be matched reliably to your component and advisory sources.
  3. Map the product to deployed services and accountable owners.
  4. Triage relevant findings using exposure, affected functionality, exploit information, and available mitigations.
  5. Record the decision, update or exception, and verification result.

How to check the result

Check that the inventory matches a known build and can support a real component query. An SBOM saved in a folder but disconnected from releases will quickly lose value.

The component name matches an advisory. Do we patch every service immediately?

Confirm the version, deployment, and affected behavior, then prioritize using exposure and consequence. Record the decision rather than treating a name match as the entire assessment.

Sources and useful guides

The following resources provide background and more detailed guidance. Use the sections that match your service and situation.

Scroll to Top