What should organisations prioritise first in SBOM programmes?

They should prioritise build-time generation over later cataloguing, because the inventory must reflect the artifact at the moment it is created. After that, the next priority is coverage for the systems that create the most drift, especially transitive dependencies and container builds.

Why the first SBOM priority is build-time generation, not after-the-fact cataloguing

An SBOM only becomes operationally useful when it describes the artifact as it is produced, not as it is later remembered. Build-time generation anchors the inventory to the exact package, layer, and dependency set that shipped. That is why late cataloguing is weaker: it can miss transitive changes, rebuilt images, and drift introduced after release.

For that reason, the first programme decision is to embed SBOM creation in the build pipeline, where provenance and component attribution are still intact. That also makes the SBOM more trustworthy for downstream consumers, because the inventory is tied to a specific build event rather than to a separate documentation process.

Build-time generation also creates a cleaner control point for both software teams and security teams. Once the artifact is created, any later reconstruction has to infer what was present, which is exactly where mismatches and blind spots begin.

Why drift-prone systems deserve the next wave of coverage

After build-time generation, the next priority is the software that changes most between source, build, and deployment. Transitive dependencies are a common source of hidden risk because they pull in components that teams do not directly select, review, or update. Container builds are equally important because image layering and base-image reuse can introduce component drift across many releases at once.

Those two areas matter because they are where the SBOM tends to become stale fastest. If the programme starts with low-drift applications, it can create a false sense of coverage while leaving the most volatile software under-documented. The practical goal is not just more SBOMs, but better fidelity where the inventory is most likely to diverge from reality.

This is also why SBOM prioritisation should follow change density, not business visibility alone. A widely used container base image or a heavily composed application can affect many downstream products, so a single missed dependency update can propagate broadly.

How to sequence the programme so it stays useful in practice

SBOM programmes work best when they are phased around repeatability. First, make build-time generation mandatory for new builds and rebuilds. Second, extend coverage to the repos, pipelines, and image patterns that introduce the most dependency churn. Third, only then expand into broader cataloguing and reconciliation tasks, because those efforts are more useful once the core inventory is already being produced automatically.

That sequence helps avoid a common failure mode: teams spend effort manually cataloguing components that will soon change again. If the source of truth is not generated at build time, every later control becomes harder, including vulnerability matching, change impact analysis, and supplier attribution.

Programmes also benefit from treating SBOM quality as a build discipline rather than a documentation project. The question is whether the inventory can be trusted at the artifact boundary, not whether the organisation has a spreadsheet of components somewhere else.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
SLSA	Build provenance	SBOM accuracy depends on producing inventory from the actual build output.
Recommendation — Tie SBOM creation to the build pipeline so provenance and component state are captured at release time.
CIS Controls v8	CIS-16 — Application Software Security	SBOM programmes support secure software tracking and composition awareness across builds.
Recommendation — Integrate SBOM generation into software delivery controls for every release.
NIST SP 800-53 Rev 5	CM-8 — System Component Inventory	SBOMs are a component inventory mechanism, especially when build-time and drift coverage matter.
Recommendation — Maintain a current component inventory that is generated and refreshed from build outputs.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Build-time SBOMs help keep component records aligned with controlled software configurations.
Recommendation — Record components from the controlled build so inventory stays aligned with released configurations.
OWASP ASVS	V15 — Secure Coding and Architecture	Build-time composition tracking supports secure software architecture and dependency oversight.
Recommendation — Track dependencies during build to keep security review aligned with shipped software.

Practitioner Guidance

What to prioritise: Make build-system integration the first success criterion. If SBOMs are not emitted as part of the build, the programme will struggle to keep pace with release drift and dependency churn.

What to verify: Confirm that the SBOM is generated from the exact build output, not from source estimates or post-release reconstruction. Then verify that transitive dependencies and base/container layers are actually represented, because those are the places where missing components most often hide.

Implementation sequence: Start with the pipelines that ship the most frequently or change the most, then expand to other build paths once the generation pattern is stable. That gives the organisation a working control surface before it tries to scale coverage.

Practitioner takeaway: The best SBOM programme is the one that can keep up with software change, so begin where drift is highest and make generation part of producing the artifact itself.