Implementing Software Bill of Materials (SBOM) Verification in CI/CD Pipelines

Modern software applications depend on hundreds of open-source libraries, frameworks, and third-party components. While these dependencies accelerate development, they also introduce security and compliance risks. A vulnerable package or compromised dependency can affect every application that includes it.

A Software Bill of Materials (SBOM) provides a structured inventory of all software components used in an application. By verifying SBOMs during Continuous Integration and Continuous Deployment (CI/CD), development teams can identify vulnerable dependencies, enforce security policies, and improve software supply chain transparency before applications reach production.

In this article, you'll learn how SBOM verification works, integrate it into .NET CI/CD pipelines, and implement production-ready practices for securing your software supply chain.

What Is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable inventory of the software components that make up an application.

An SBOM typically includes:

Package names
Package versions
Licenses
Suppliers
Component relationships
Dependency hierarchy

Rather than manually tracking dependencies, an SBOM provides an automated and standardized inventory.

Why SBOMs Matter

Modern applications often contain:

Application
      |
-------------------------
| ASP.NET Core         |
| NuGet Packages       |
| JSON Libraries       |
| Logging Frameworks   |
| Authentication SDKs  |
-------------------------

Each dependency introduces potential security, licensing, and maintenance considerations.

SBOM verification helps organizations answer questions such as:

Which libraries are included?
Are any components vulnerable?
Which applications are affected by a newly disclosed vulnerability?
Are approved licenses being used?

SBOM in the Software Supply Chain

A simplified software supply chain looks like this:

Source Code
      |
Restore Packages
      |
Build
      |
Generate SBOM
      |
Verify SBOM
      |
Security Scan
      |
Deploy

Verification should occur before deployment rather than after release.

Common SBOM Formats

Several industry-standard formats exist.

Format	Description
SPDX	Open standard for software component inventories
CycloneDX	SBOM format focused on software supply chain security
SWID	Software identification tags
Proprietary Formats	Vendor-specific implementations

Many modern security tools support both SPDX and CycloneDX.

Why Verify SBOMs in CI/CD?

Generating an SBOM alone is not enough.

Verification helps ensure:

Dependencies meet security requirements.
Vulnerable packages are detected early.
License policies are enforced.
Unauthorized packages are identified.
Build artifacts remain traceable.

Automating these checks reduces the likelihood of introducing risky components into production.

Generating an SBOM

Many build tools and package ecosystems support SBOM generation.

A simplified workflow:

Build
   |
Package Restore
   |
Dependency Analysis
   |
Generate SBOM

The exact generation tool depends on your build platform and preferred SBOM format.

Example Build Pipeline

A CI/CD workflow might include:

Developer Commit
        |
Build
        |
Unit Tests
        |
Generate SBOM
        |
Verify SBOM
        |
Security Scan
        |
Package
        |
Deploy

Each stage contributes to overall software quality and security.

Reading an SBOM

A simplified SBOM entry might resemble:

{
  "name": "Newtonsoft.Json",
  "version": "13.0.3",
  "license": "MIT"
}

Real-world SBOMs typically contain additional metadata such as package identifiers, suppliers, hashes, and dependency relationships.

Automating Verification

Create a verification service.

public class SbomVerifier
{
    public bool Verify(
        IEnumerable<PackageInfo> packages)
    {
        return packages.All(
            p => !string.IsNullOrWhiteSpace(
                p.Version));
    }
}

Production implementations typically validate additional attributes such as approved licenses, version constraints, and policy compliance.

Checking Dependency Policies

Organizations often maintain approved package policies.

Example:

Approved

Microsoft.Extensions.*

Serilog.*

Npgsql.*

Blocked

Unknown Packages

Deprecated Libraries

Policy validation ensures only approved dependencies are included in released software.

Detecting Vulnerable Components

Verification should identify dependencies that require attention.

Typical workflow:

SBOM
   |
Security Database
   |
Known Vulnerabilities
   |
Build Result

If critical vulnerabilities are detected, organizations may choose to fail the build or require manual approval before deployment.

License Compliance

Dependency licenses are an important part of software governance.

Validation may include:

Approved licenses
Restricted licenses
Missing license information
License reporting

License verification helps reduce legal and compliance risks.

Integrating with GitHub Actions

A simplified workflow:

name: Build

steps:
- uses: actions/checkout@v4

- name: Build
  run: dotnet build

- name: Generate SBOM
  run: dotnet tool run sbom

- name: Verify SBOM
  run: dotnet run --project SbomVerifier

The exact commands depend on the SBOM generation and verification tools selected for your pipeline.

Logging Verification Results

Record verification outcomes for auditing.

Example:

logger.LogInformation(
    "SBOM verification completed successfully.");

Useful information includes:

Build number
SBOM version
Verification result
Timestamp
Security policy version

Avoid logging confidential repository or infrastructure details.

Handling Verification Failures

Not every issue has the same severity.

A typical workflow:

Verification
      |
-----------------------
| Pass | Warning | Fail |
-----------------------

Examples:

Missing metadata → Warning
Unsupported license → Fail
Critical vulnerability → Fail

Severity levels should align with organizational security policies.

Monitoring Supply Chain Security

Useful metrics include:

Packages analyzed
Vulnerable dependencies
License violations
Failed builds
SBOM generation time
Verification duration
Policy compliance rate

Monitoring these trends helps teams improve supply chain security over time.

Security Considerations

When implementing SBOM verification:

Protect build pipelines.
Secure artifact storage.
Verify package sources.
Restrict pipeline permissions.
Audit dependency changes.
Protect generated SBOM files.
Review third-party dependencies regularly.

SBOM verification should be one layer within a broader software supply chain security strategy.

Production Best Practices

Practice	Benefit
Generate SBOMs automatically	Consistent inventories
Verify every build	Early issue detection
Enforce dependency policies	Improved governance
Review vulnerable packages promptly	Reduced security risk
Monitor license compliance	Better legal compliance
Archive SBOMs with releases	Improved traceability
Automate verification	Consistent enforcement

Common Mistakes

Mistake	Better Approach
Generating SBOMs without verification	Validate every build
Ignoring transitive dependencies	Analyze the complete dependency graph
Manual verification	Automate policy checks
Missing license reviews	Validate licenses during CI
No audit history	Store SBOMs with release artifacts
Updating packages without validation	Re-run verification after every dependency change

Troubleshooting

SBOM generation fails

Verify:

Build completed successfully
Required tools are installed
Package restore succeeded
Output paths are correct

Verification reports missing packages

Check:

Dependency restoration
Build configuration
Package references
Tool compatibility

Unexpected build failures

Review:

Security policies
License rules
Dependency updates
Verification logs

Vulnerabilities continue appearing

Investigate:

Outdated packages
Unsupported libraries
Dependency update process
Third-party package sources

SBOM Generation vs SBOM Verification

Feature	SBOM Generation	SBOM Verification
Creates component inventory	Yes	No
Detects policy violations	No	Yes
Validates dependency rules	No	Yes
Checks license compliance	Limited	Yes
Supports deployment decisions	Limited	Yes
Improves software governance	Moderate	High

Generating an SBOM is the first step. Verification transforms that inventory into an actionable security control.

Frequently Asked Questions

Is generating an SBOM enough?

No. An SBOM lists software components, but verification checks whether those components comply with security and organizational policies.

Should SBOM verification run on every build?

Yes. Integrating verification into CI/CD helps detect dependency issues before software reaches production.

Can SBOM verification replace vulnerability scanning?

No. SBOM verification and vulnerability scanning complement each other. An SBOM provides component visibility, while vulnerability scanning identifies known security issues associated with those components.

Should SBOMs be stored after deployment?

Yes. Retaining SBOMs alongside release artifacts improves traceability and helps organizations quickly identify affected applications when new vulnerabilities are disclosed.

Does SBOM verification only apply to open-source software?

No. Organizations can include both proprietary and third-party components in their SBOMs to improve overall software inventory management and governance.

Conclusion

As software supply chain security becomes increasingly important, SBOMs provide the transparency needed to understand what applications are built from and how dependencies evolve over time. However, generating an SBOM is only the beginning. Automated verification within CI/CD pipelines enables organizations to enforce dependency policies, identify vulnerable components, validate license compliance, and improve release confidence.

By integrating SBOM verification into the software delivery process, development teams can strengthen application security, enhance compliance, and establish a more resilient and auditable software supply chain without significantly increasing development complexity.