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.
Join the conversation! Your thoughts help the community grow.