Setting up Software Bill of Materials (SBOM) generation

SBOM: Where Dependency Accounting Breaks in the Build

The build passes green, the image goes to the registry, the release goes to prod.

A few days later, a vulnerability notification arrives for a transitive dependency — and there is no way to reconstruct the exact composition of that delivery: the manifests have been overwritten by the next build, the lock file did not make it into the artifact, and versions were pulled by range.

The question "do we have a vulnerable component in this exact version?" remains unanswered.

Then manual trial and error begins.

An engineer looks for the commit by release date, rebuilds the project with the same set of sources, and still cannot claim to have obtained the same result: an updated minor package, a different set of system libraries in the base image, the internal proxy cache.

Such reconstruction takes hours, and the window between vulnerability discovery and a confirmed answer remains open the whole time.

The root cause is that the SBOM is born where it should not be.

It is generated as a separate post hoc step, from the dependency file and outside the build context: the list includes direct dependencies, but not what actually landed in the image layers — transitive packages from the system package manager, vendored libraries copied into the artifact.

Without binding to the immutable image identifier, the document describes "roughly this build" rather than a specific delivery, and component accounting ceases to be verifiable.

Add to that the fragmentation of formats: one team delivers the build composition in one form, another in another, and they cannot be consolidated into a single query without manual normalization.

We examine how to embed generation into the pipeline so that delivery transparency is confirmed for every artifact.

Practical Benefits of Regular SBOM Generation

Regular SBOM generation turns the dependency list from a one-off paper into a data stream.

The Anchore Syft generator runs in the build pipeline for every build of the main branch, reads the dependency tree from package manager manifests and the image filesystem, and stores the result as a CycloneDX document alongside the artifact itself.

The document is then signed and goes to the registry: the image version and its composition are tightly linked, not by an engineer's memory.

When a vulnerability notification arrives for a transitive library, the work is done by querying the registry rather than walking through dozens of repositories. The answer is a list of services and versions where the component is present, accurate down to the build.

Incident triage shrinks from several hours of coordinating "where is this even used?" to minutes: you immediately see what to patch and what can be left alone.

Traceability also works in the opposite direction. For any running container, its SBOM is retrieved, and the question "which components and under which licenses are currently in prod?" is answered by the document, not by reconstruction from change history.

This also closes external security requests: the delivery composition is exported from the registry rather than reassembled.

Dependency control rests on comparing two SBOMs: the difference shows what actually changed when the base image or library version was updated.

Unaccounted transitive dependencies that stretch several levels deep stop being a surprise — the failure class "after release, it turned out something extra came in" leaves practice.

The key effect comes precisely from regularity: a schedule in the pipeline provides a continuous picture, while a one-off snapshot is only a photograph on a date.

Instead of ten spreadsheets and notes in different places, a single component registry appears, used by both development and security.

Ways to Generate the Composition: Comparison of Approaches

A composition description can be obtained in three different ways, and they are not interchangeable.

Automatic generation at the build stage captures everything that actually landed in the artifact; semi-manual mode adds records for components that the analyzer does not recognize; one-off analysis of a finished artifact is needed where rebuilding is not planned.

Composition description formats — CycloneDX or SPDX — are chosen separately from the method: compatibility with the systems that will read this data matters.

The difference between the options is the difference between data freshness and the cost of maintaining it. Automatic mode provides maximum analysis depth: direct and transitive dependencies and nested system packages are visible.

The limitation of generation is that components loaded at runtime from external sources do not fall into such an analysis.

The semi-manual approach closes this gap at the cost of a procedure: each manual record must have a version and a source, otherwise the description loses credibility.

One-off analysis is useful as a starting point — it shows the full picture at the current moment but does not update with the system.

The working scheme is automatic generation in the pipeline as the foundation plus periodic re-generation of the composition for rarely updated systems.

How We Set Up SBOM Generation: Work Stages

Setting up SBOM generation is not connecting a single extension but a sequence of six steps: from component inventory to documentation handover.

Each stage is responsible for its own class of errors, and skipping any of them leads to a list that formally exists but does not reflect the actual composition of the artifact.

1. Component inventory. We go through repositories, record languages, dependency managers, the presence of transitive and vendored libraries, and components inside images. The output is a list of services with a note of where generation covers everything automatically and where manual refinement is needed.
2. Flow diagram. We determine at what point the document is formed — during artifact build or image release, where it is stored, and how it is linked to a specific build so that the release number can be used to find exactly its list.
3. Embedding into the build. Generation becomes a pipeline step: if the document is not generated, the build stops. This way the list stops being an optional artifact made "when asked."
4. Rule configuration. We choose the format — SPDX or CycloneDX, define the set of fields, the depth of dependency analysis, and behavior for components without metadata: mark them explicitly rather than silently discard them.
5. Result verification. We compare the composition from the document with the actual contents of the artifact, check versions, licenses, and duplicates. Discrepancies are either a generator error or traces of manual build edits.
6. Documentation handover. We provide the scheme, description of rules, developer instructions, and the update procedure when dependencies change, so that the setup does not diverge from the real build at the first major change.

Delivery Composition: Configurations, Schemes, and Procedures

Setting up SBOM generation is not a one-off report on a single release but a change to the build environment: the build itself forms the component list, signs it, and transfers it to storage.

What remains for the customer is not "contractor magic" but a set of artifacts that their team can use to continue independently and reproduce the result on a new project.

Specifically, what we hand over:

• Build environment configurations — jobs and stage templates where list generation is enabled, with explanations for each parameter.
• Process diagrams — the path from code change to SBOM publication: build, verification, and artifact handover points, with roles and owners.
• Composition control policies — rules for stopping the build when a component has a known vulnerability or an unacceptable license.
• Access policies — a permission matrix for lists, signature configuration, and artifact authenticity verification.
• Report templates — exports in standard composition description formats (SPDX, CycloneDX) with filters by criticality.
• Team instructions — how to release, roll back a rule, and investigate a composition discrepancy.
• Update procedure — the frequency of reviewing the prohibited list and the procedure for actions when dependencies change.

We accept each item in your environment: we run a build with a deliberately problematic dependency and verify that the rule triggers and the report is generated correctly.

Case Study: How Incident Triage Shrank After Implementation

What It Was Like Before Automation

An incident involving a vulnerability in a transitive library was handled manually: an engineer pulled up build logs and compared dependency manifests and lock files for each service.

Determining the full list of affected components took 4 to 6 hours, and for some builds the picture remained incomplete — services had to be rebuilt "just in case." With dozens of repositories, this stretched into a separate working day and delayed the release of the fix.

What We Changed

SBOM generation was enabled directly in the build step: the component composition document is created automatically and linked to the immutable image identifier rather than the tag name.

A vulnerability report from an external source triggers a search across all accumulated documents — in Dependency-Track, such a query returns the list of affected builds within minutes, including transitive dependencies that are not in explicit manifests.

We separately addressed the issue of data quality: an image is considered released only if an SBOM is present, so the share of builds with a composition document reached 100%.

Metrics After

The time to identify affected components dropped from 4–6 hours to 15–25 minutes, and this is a complete list, not a sample across several services.

The number of rebuilds "for insurance" fell almost to zero: you can see which images contain the component and which do not. Incident triage no longer depends on which engineer remembers the history of a particular repository.

How Does a One-Off Composition Report Differ from Regular SBOM Generation?

A one-off report is a snapshot of the composition at the time of request: an inventory of what is already deployed. Regular generation ties the SBOM to every artifact at the build stage, so a document exists for any version that has entered the environment. The difference is not in the file format but in which questions the system is able to answer.

Freshness is the key divergence. A snapshot answers the question "what was in the system at the time of audit" and after a couple of releases loses touch with reality: it still contains removed dependencies and lacks new ones.

When a vulnerability notification arrives, you need to understand within minutes which running versions contain it — with a snapshot, this requires a new walkthrough.

The second watershed is repeated checks. Regular generation turns the answer to a security request into a query by component index: the build publishes the SBOM to storage, and a search for the affected library returns a list of versions and environments.

A manual report cannot withstand such a scenario — the cost of repetition is comparable to the first inventory.

The working scheme is to combine: a one-off audit for legacy systems that are already running and are not rebuilt, and regular generation for everything released afterward.

SBOM signing and storage rules make such a check reproducible rather than dependent on who remembered to assemble the report and when.

Technical Concerns: Common Questions About Implementation

What raises doubts is not the generation of the list itself but its embedding into a working build pipeline: what will have to be changed, how to handle manually installed components, and whether the list might turn out incomplete. We have collected four objections most often heard at the evaluation stage, and an answer to each.

What about manually installed components?

They are found by scanning the image contents: installation paths, file signatures, and package manager records are compared. Such libraries enter the list with a source note, and the share of unrecognized files goes into the report.

How can we be sure the list is complete?

Completeness is checked by comparison with a reference and coverage by image layers: the share of files attributed to known components is calculated. A discrepancy above the threshold becomes a blocking rule rather than a warning.

We already have a scanner and storage — do we have to give them up?

The list is provided in standard open formats, so it is picked up by current scanners and the registry without replacement. The generator needs read access to images and write access to the list storage — we describe the policies separately.

Let's Discuss the Task: What to Send for an Estimate and Plan

To come back with a timeline estimate and a work plan for software composition generation (SBOM), access to your environment is not needed at the start.

A description of how the build and release are organized is sufficient — that is enough to see the scope of work and bottlenecks.

What to describe point by point:

• Build environment — which systems build artifacts, where dependencies are stored, and whether manifests are accessible at the build stage rather than only in the finished image.
• Languages and package managers by service — these determine which composition formats we generate and how we consolidate them into a single document.
• Artifact type — images, archives, system packages: each needs its own set of data sources.
• Composition consumer — registry, vulnerability management system, or external audit: this determines the export format and level of detail.
• Embedding point — the composition appears during the build process, before artifact publication, or on a schedule for already released versions.
• Storage and history — how many composition versions need to be kept and how quickly to find the composition of a specific release.
• Access restrictions — closed segments and isolated environments where the build runs without an external network.

If some data is not available yet, describe it as it is: we account for gaps in the work plan and close them during the assessment stage. Based on the description, we will come back with a timeline estimate, the set of stages, and what will be needed from your team.