SBOM creation and management | Anexia Digital Engineering

When creating software bills of materials, we determine which output is to be described: a container image, an installable application, a mobile package or a specific product version. A list taken from the development repository does not automatically reflect the delivered state. The time of generation and the link to the artefact are therefore essential parts of the scope of services. Components added at a later stage must also be taken into account.

For the Software Bill of Materials, the required formats and exchange partners are agreed. A machine-readable document is only of practical use if the identities and version details it contains are sufficiently unambiguous. In SBOM creation, we check whether, after a release, it remains traceable which versions could be affected by a vulnerability that becomes known later. Updating, archiving and handover are built into the delivery process. A clear distinction is made between a component inventory and a complete security assessment. The completion of SBOM management shows how the agreed bill of materials is created, which product it is linked to and how it can be used for specific enquiries or change decisions.

Scope of services for SBOM creation

The agreed scope for creating software bills of materials can include the following deliverables: generation process, choice of format, component mapping, archiving, validation and exchange procedure. For each key deliverable, we define what it is for, who reviews it and in what form it is handed over. This allows development, operations and procurement to assess the same service. Vague umbrella terms in the offer are replaced by concrete work packages.

The Software Bill of Materials also includes coordinating the necessary interfaces with your team. We clarify access, contact persons and available testing options before the relevant implementation steps. Changes to the scope are described together with their impact on effort and sequence. This gives you a clear overview of delivered results, outstanding prerequisites and additional requests.

The key technical decision in SBOM creation

The bill of materials is bound to the build and its dependencies. A subsequent scan of the source directory can produce different results. For SBOM management, we document the relevant assumptions and justify the chosen option. Key alternatives are considered against the same functional requirements. This makes later adjustments easier when load, data volume or organisational responsibility change.

A sound decision also takes maintainability and handover into account. When creating software bills of materials, we check which skills are available internally and what additional support is needed. Technical possibilities are thus linked to a realistic operating model. The client can see which tasks will arise regularly after the project and which decisions remain with them.

Incomplete or incorrectly assigned lists create an apparent transparency that does not hold up when a specific security enquiry arises. In the Software Bill of Materials, we treat this point as a concrete test question. A risk is linked to the affected process, its possible impact and a suitable measure. Where prerequisites are still missing, the statement explicitly remains open until the necessary investigation has taken place.

We compare known components, check schema and identifiers and trace selected packages through the build up to the delivered version. For SBOM creation, we record the initial situation, the tested configuration and the result. Acceptance refers to the agreed scope. Open limitations are visibly documented and assigned to an owned next step. This allows your team to distinguish between proven functionality, a deliberate decision and an assumption not yet confirmed.

Project example as an illustrative scenario

The following scenario is a use case example and not a customer reference. A software vendor is to provide customers with information about the components it contains. In SBOM creation, the first step would be to define which product artefact the list refers to. A bill of materials generated on a developer machine could differ from the delivered container or installation package. The pilot would therefore accompany a uniquely identified release through the existing build process.

For SBOM management, component identifiers, versions and relationships would be checked for plausibility. In-house developed parts, bundled libraries and transitive dependencies must not be missing by mistake. The team would examine which information is generated automatically and where supplementary details are required. A later rebuild of the same product would have to produce a list that can again be assigned. Changes between releases would need to be presented in such a way that a security report can be related not only to a package name, but to the deliveries actually affected.

Acceptance of the software bills of materials created would include a spot check against the finished product and a repeat generation run. The planned results would be a reproducible creation path, documented coverage limits and a usable exchange format. The bill of materials would be a basis for further assessments, but not independent proof of the security of all components it contains. Who evaluates new reports and updates customer information would have to be explicitly defined in the subsequent process.

Our experience and our engineering approach

We combine custom software development with the technical tasks of introduction and further development. For SBOM management, we bring the perspectives of application, integration and operations together in a shared workflow. Business requirements remain linked to technical decisions. You work with a defined scope of services and traceable results.

Our experience should become concretely verifiable for your project. That is why, in a technical exchange, we explain how we examine the relevant risks, which deliverables are planned and how your team can assess them. For creating software bills of materials, we align the roles involved with actual needs. Available references are presented in the context of the respective project and company; confidential customer details are not used as general advertising claims.

Effort for creating software bills of materials

Build variants, container contents, proprietary modules and the desired granularity influence the capture. We therefore calculate SBOM creation on the basis of a defined scope and explicitly stated prerequisites. An initial analysis step can be useful if essential technical information is still missing. Work packages and acceptance criteria can then be agreed more reliably.

SBOM management can be organised as a limited project, as a joint implementation with your team or with subsequent support. Usage rights, access, documentation and responsibilities are clarified in the contract. Ongoing operating hours, response times and external consumption costs are separate agreements. This makes it clear which services are provided once and which tasks arise regularly after introduction.

Scope boundaries of SBOM creation

A bill of materials is an inventory and not independent proof that all components are secure or legally unobjectionable. For the Software Bill of Materials, we already record this boundary in the offer. Required additional services are included with their functional justification and not tacitly assumed. Your team can therefore plan suitable internal skills and divide the overall work sensibly between those involved.