How to implement SBOM in a development pipeline?

SBOM (Software Bill of Materials) is a structured inventory of the components that make up a software application, including libraries, dependencies, and versions. Implementing SBOM in development pipelines improves software supply chain visibility and supports security, compliance, and governance practices.

More than creating a list of software components, SBOM adoption requires integrating processes, tools, and responsibilities across the software lifecycle. This approach helps connect development teams, security professionals, compliance requirements, and technology governance into a more structured software risk management process.

Why does it matter? — Business impact

Modern software applications rely on multiple internal and external components, making visibility into libraries, dependencies, and versions an important element of application security and technology governance.

Implementing SBOM can help organizations improve transparency over software composition, support vulnerability management processes, and provide information for security decisions. When integrated into DevSecOps pipelines, software inventories can evolve together with application changes.

Within an IT GRC approach, SBOM helps connect software development, security, and compliance by creating structured information that can support audits, risk assessments, and governance activities related to the software supply chain.

Where does it apply? — Context, industries, and maturity

SBOM can be applied by organizations that develop, distribute, or maintain software applications and need greater visibility into the components and dependencies used across their technology environments.

Organizations with lower application security maturity can use SBOM implementation to establish component inventories and begin controlling software dependencies. Organizations with more advanced DevSecOps practices can integrate SBOM generation with pipelines, security tools, and continuous monitoring processes.

The adoption process typically involves DevSecOps Engineers, Tech Leads, application security teams, software developers, technology managers, and professionals responsible for compliance and software governance.

What risks exist?

Lack of visibility into software components can make it harder to identify and manage risks associated with the software supply chain. Common scenarios may include:

• Difficulty identifying libraries, dependencies, and versions used across applications.
• Limited ability to assess the impact of known vulnerabilities affecting software components.
• Lack of structured evidence to support security audits and compliance activities.
• Manual software inventories that become outdated as applications evolve.
• Insufficient alignment between development teams, security teams, and technology governance.

These challenges may be related to the absence of automated processes, limited integration between development and security tools, or undefined practices for monitoring software component risks.

A structured SBOM implementation helps organize this information and creates a foundation for security, compliance, and risk management decisions.

How to implement — Practical steps

SBOM implementation in development pipelines can be structured into progressive steps, considering the organization's technology environment, existing processes, and security objectives.

Step 1 — Assess software landscape and implementation requirements

Identify applications, programming languages, frameworks, existing pipelines, security requirements, and governance objectives to define where SBOM should be implemented and which information needs to be monitored.

Step 2 — Select SBOM standards and generation tools

Define compatible SBOM formats, dependency analysis tools, and required integrations according to the development environment. This step establishes a consistent approach for generating automated software component inventories.

Step 3 — Integrate SBOM generation into CI/CD pipelines

Implement automated pipeline stages to generate, update, validate, and store SBOM records throughout software development and delivery processes, maintaining evidence of software composition changes.

Step 4 — Connect SBOM with vulnerability analysis and evidence management

Integrate generated inventories with vulnerability databases, security workflows, audit evidence records, and risk treatment processes to support faster identification and prioritization of software risks.

Step 5 — Monitor and evolve software supply chain governance

Track indicators, review policies, improve integrations, and maintain continuous visibility over software component changes and associated risks throughout the application lifecycle.

Which frameworks support?

SBOM implementation can be supported by standards, practices, and frameworks related to application security, DevSecOps, risk management, and technology governance.

Framework or practice	Contribution to SBOM implementation
SBOM Standards	Define structured formats for representing software components, dependencies, and application composition information.
DevSecOps	Supports security integration throughout the software development lifecycle, including automation within CI/CD pipelines.
OWASP	Can support application security practices, risk analysis, and secure software development processes.
NIST Software Supply Chain Security	Can contribute to software supply chain security practices and technology risk management approaches.

The selection of standards, tools, and practices should consider organizational context, process maturity, security requirements, and governance objectives. A structured approach allows organizations to improve software component visibility and strengthen software supply chain management.

Which indicators should be monitored?

Monitoring indicators helps organizations understand whether SBOM implementation is generating the expected visibility and governance over software components. The selected indicators should reflect the organization's security objectives, development processes, and risk management practices.

Common indicators that can support SBOM governance include:

• Number of applications with generated and updated SBOM records.
• Coverage of development pipelines integrated with automated SBOM generation processes.
• Status of identified vulnerabilities associated with software components.
• Time required to identify and prioritize risks related to dependencies.
• Availability of evidence records for audits, compliance reviews, and security assessments.

These indicators should be reviewed continuously and adapted as software environments, security requirements, and governance objectives evolve.

Which tools should be used?

The selection of tools for SBOM implementation depends on the organization's technology stack, development practices, existing security processes, and integration requirements.

Tools can support different stages of the process, including dependency discovery, SBOM generation, vulnerability analysis, pipeline automation, and evidence management. The objective is not only to generate inventories but to integrate them into security and governance workflows.

A structured tool strategy typically considers compatibility with programming languages, CI/CD platforms, application environments, vulnerability databases, and existing DevSecOps practices.

How to automate SBOM processes?

Automation is a key element for maintaining updated software inventories as applications continuously change. Manual SBOM creation can become difficult to maintain in environments with frequent releases, multiple teams, and complex dependencies.

Organizations can integrate SBOM generation into CI/CD pipelines, automatically creating, validating, and storing software composition records during build and delivery stages.

Automation can also connect SBOM information with vulnerability analysis processes, security workflows, ticketing systems, and evidence repositories, creating a more consistent approach for risk identification and treatment.

How can AI help with SBOM management?

Artificial intelligence can support SBOM-related activities by helping analyze large volumes of software component information, identify patterns, and assist teams in prioritizing security activities.

AI-based approaches may help correlate component inventories with vulnerability information, support risk analysis, and improve visibility over software supply chain changes. These capabilities should be combined with defined governance processes and human validation.

Within an IT GRC context, AI can contribute to making security information more accessible for technical and governance teams while supporting more informed decision-making.

Common mistakes

SBOM implementation can face challenges when organizations focus only on generating files without establishing processes for ownership, review, and continuous management.

Common implementation mistakes may include:

• Creating SBOM inventories without integrating them into CI/CD workflows.
• Generating SBOM records without defining responsible teams for analysis and response.
• Using tools without considering compatibility with the organization's technology environment.
• Failing to connect SBOM information with vulnerability management and audit evidence processes.
• Treating SBOM as a one-time activity instead of an ongoing software governance practice.

A successful approach requires alignment between development, security, compliance, and technology governance teams throughout the software lifecycle.

Recommended implementation roadmap

A practical SBOM implementation roadmap can be organized into maturity phases, allowing organizations to evolve gradually according to their environment, risks, and operational capacity.

Phase 1 — Assessment and planning

Evaluate the software landscape, existing applications, programming languages, frameworks, pipelines, security requirements, and governance objectives. This phase establishes the scope and priorities for SBOM adoption.

Phase 2 — Automation and pipeline integration

Select SBOM standards and generation tools, then integrate automated generation, validation, and storage processes into CI/CD workflows to maintain updated software inventories.

Phase 3 — Security integration and governance evolution

Connect SBOM data with vulnerability analysis, audit evidence management, risk treatment processes, and continuous monitoring practices to strengthen software supply chain governance.

How WAAC can support — Assessment, Consulting, Implementation, and Sustaining

WAAC can support organizations throughout different stages of SBOM adoption, combining software engineering practices, application security, automation, and IT GRC approaches.

During an Assessment, the organization can evaluate its current software lifecycle, development pipelines, security practices, and governance requirements to identify implementation priorities.

Through Consulting and Implementation, WAAC can help structure SBOM processes, define integration strategies, support automation within development workflows, and connect component inventories with security and compliance activities.

In the Sustaining phase, continuous improvement practices can help maintain visibility over software components, review processes, and adapt governance according to technology changes and evolving security requirements.

Frequently asked questions

What is SBOM (Software Bill of Materials)?

SBOM is a structured inventory of software components, libraries, dependencies, and versions used in an application, providing greater visibility into software composition.

How can organizations generate SBOM automatically in development pipelines?

Automatic SBOM generation can be integrated into development workflows through dependency analysis tools, CI/CD pipeline stages, and DevSecOps practices to create and update software inventories.

How can SBOM be used in security audits?

SBOM can support security audits by providing visibility into software components, versions, dependencies, and evidence related to the composition of evaluated systems.

How can organizations identify vulnerable components using SBOM?

SBOM analysis can be combined with vulnerability databases to identify software components with known risks and support remediation and prioritization decisions.

Why implement SBOM in a development pipeline?

Implementing SBOM helps increase software supply chain transparency, improve security processes, and support technology governance practices.

Implementing SBOM requires more than adopting a generation tool. It involves creating an integrated approach between software development, security, compliance, and governance to maintain visibility and control over the software supply chain. A structured implementation journey can help organizations evolve their practices according to their risks, objectives, and technology environment.