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:
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:
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.