An SBOM can be created quickly on the first try. The bigger challenge is whether it will still be accurate for the next release. New packages, updated libraries, and changed build configurations alter the software inventory. A manually maintained file can easily lose track of the actual application.
When you integrate an SBOM into CI/CD, you link its generation and distribution to recurring development steps. In this presentation, our experts and speakers Ruben Brick and Yvette Teiken will introduce a workflow that spans from the .NET application through Azure DevOps to Dependency-Track. The live local demo will showcase the generation process and the resulting analysis views, serving as a clear illustration of the individual components.
Link the SBOM to a specific software build
Before setting up an additional pipeline step, the team should determine which stage the SBOM describes. A development build and a released product version serve different purposes. To facilitate future inquiries, it must be clear which SBOM corresponds to which release.
For implementation, we recommend archiving the product version and build identifier along with the SBOM. This makes it possible to determine later whether a security advisory affects a released version. A single file named “Current SBOM” would be insufficient for this purpose: it does not answer questions about older versions that are still in use by customers.
Integrating SBOM into CI/CD: Automating Generation and Verification
For a pilot project, a team can first run the locally tested generator in its build environment. Next, they should verify whether the output file was generated, can be technically imported, and conforms to the intended schema. Only then should it be saved as an artifact or passed on for further evaluation.
The exact timing depends on the item being analyzed. For a project analysis, the necessary dependency information must be available. If the SBOM is to describe a finished container image, that image must already exist. It is crucial that the generator and input data align with what the SBOM is intended to represent later on.
It is also worth making controlled changes to the generator version and configuration. An unexpectedly significant change in the component list should prompt an investigation. This way, the pipeline not only generates files but also helps ensure the quality of the information.
Passing the data to Dependency-Track
After generation, the data must be delivered to where it will be used. Dependency-Track supports the transfer of CycloneDX files via integrations and its API. The documentation on CI/CD integration describes, among other things, how to map files using a project ID or, alternatively, using the project name and version.
For your own implementation, this mapping should be unambiguous. Uploading data to the wrong project can skew subsequent evaluations. API credentials belong in the CI platform’s designated secret management system. Furthermore, the technical upload is only one part of the process: The team should also be able to verify whether the expected data was processed successfully.
Treat technical errors and analysis results separately
The pipeline should be able to distinguish between three states: generation failed, handoff or processing failed, or processing was successful and returned security findings. These cases require different responses and should be clearly distinguishable in the build results.
This distinction should be implemented before the broad rollout. A failed upload does not indicate anything about the product’s security, but it can result in the analysis being based on outdated data. A pipeline should therefore clearly flag such errors.
Whether certain findings prevent approval is a deliberate process decision. To get started, we recommend transparent rules, clear responsibilities, and a documented process for handling exceptions. Blanket blocks without evaluation can be just as problematic as warnings that no one acts on.
We’ve already addressed the broader issue of responsibility and collaboration in the article “Cybersecurity Isn’t Just for Tech Giants—SMEs Must Act Now.” The technical purpose of this workflow is to provide the responsible department with a reliably assigned and processed software inventory.
Start with a release and complete the process
A well-designed pilot project should cover one product and one release: generating, verifying, archiving, and transferring the SBOM, and assigning the results to the appropriate department. Only once this process is functioning reliably should it be expanded to other projects.
The SBOM thus becomes a recurring development artifact. The next article explains what happens with the security findings derived from it: “SBOM in Vulnerability Management: Targeted Review of Findings.”
Sources and Further Information
- Presentation, slide “Workflow with CI/CD” at the 28-minute mark.
- Dependency Track: Continuous Integration & Delivery.
- Dependency Track: Best Practices.
