Maintaining an Accurate SBOM

A software bill of materials is often treated as a deliverable rather than a living record. It gets generated to clear a requirement, filed, and forgotten. The problem is that software does not hold still. Every release adds, removes, and updates dependencies, and the licenses on those dependencies can change without any action on your part. An SBOM captured once is a photograph of a moving subject. By the time anyone consults it, it may describe a system that no longer exists, and the relicensed component it was meant to catch will appear under the license it carried at the moment of the snapshot, not the one that governs it now.

Why an SBOM has to be current, not just complete

Completeness without currency is a trap. An SBOM that listed every component accurately last year can be dangerously wrong today, because the relicensing wave changed the terms of components already in it. As of August 2023, HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1. Redis moved to a dual model with the Server Side Public License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021. MongoDB moved to the Server Side Public License in 2018. An SBOM that still records any of these as the open license they once carried is not just incomplete. It is actively misleading, because it tells you the exposure does not exist when it does. Keeping the license field current against primary sources is therefore as important as listing the component at all.

Reach the transitive depth where risk hides

A shallow SBOM is a different failure. Most license risk lives not in the dependencies a team chose but in the ones those dependencies pulled in. An SBOM that stops at direct dependencies misses the layers where relicensed and copyleft components most often sit, unseen and unreviewed. Accuracy here means resolving the full graph, all the way down, so the components no one selected directly are still on the record. We explain how this indirect risk arises in transitive dependencies and hidden license risk. An SBOM that omits that depth cannot catch what it cannot see.

Reconcile the SBOM against what is deployed

An accurate SBOM describes what is running, not what a manifest claims should be running. Build artifacts, base images, and runtime environments often contain components that no source manifest lists, and they sometimes omit components a manifest includes. The discipline is to reconcile the generated SBOM against the actual deployed estate, so the record matches reality rather than intent. Without that reconciliation, an SBOM can be both complete and wrong, describing an idealized build that does not match the one in production. The same map that supports this reconciliation is what an open source license risk assessment produces.

Wire the SBOM into governance so it stays accurate

An SBOM stays accurate only when its upkeep is automatic. That means generating it on every build, refreshing license state against primary sources on a schedule, and pairing it with an intake gate that flags a relicensed or disallowed component before it merges. Maintained this way, the same record that satisfies a regulator is the one that surfaces a relicense the day it lands rather than the day an auditor asks. The SBOM becomes an early warning system rather than a compliance artifact. This is where the SBOM meets policy and approval gates, which we cover across the governance and SBOM pillar, and it underpins the contractor and third party controls discussed in third party and contractor code governance.

We help buyers stand up SBOM practices from the buyer side. We take no vendor fees and resell no software, so the tooling and the depth we recommend reflect your risk tolerance rather than a product we are paid to place. This is commercial and licensing risk advisory, not legal advice. For interpretation of specific license terms and your compliance position, engage your own counsel.