What Changed
GitHub's Secure Open Source Fund (SOSF) has added two Software Bill of Materials (SBOM) generators to its portfolio: cdxgen and CycloneDX .NET. These projects now receive funding, security training, and expert guidance from GitHub, Microsoft, and other sponsors. This development signals that SBOM tooling is now considered critical infrastructure worthy of systematic investment.
During its SOSF engagement, cdxgen identified and mitigated five significant vulnerabilities in its codebase. This demonstrates the program's effectiveness in catching issues before they affect downstream dependencies.
Key Findings
SBOM Generation Is Now a Funded Capability
SBOM tools have often been underfunded despite their widespread use. The SOSF model changes this by treating SBOM generators as essential security infrastructure requiring ongoing maintenance. CycloneDX .NET focuses on .NET ecosystem integration, while cdxgen supports multiple environments, including JavaScript, Python, Java, and container images.
Self-Auditing Under Expert Guidance Works
cdxgen's discovery of five vulnerabilities highlights the importance of allowing maintainers time and training to audit their tools. SBOM generators are crucial as they inventory your dependencies. A compromised SBOM tool can give false confidence about what's running in production.
CI/CD Integration Drives Adoption
CycloneDX .NET's focus on CI/CD pipeline integration reflects where SBOM generation occurs in practice. Your compliance team might require SBOMs, but build engineers determine if generating them is a quick pipeline step or a forgotten manual task. Tools that integrate into GitHub Actions, Azure DevOps, or GitLab CI are more likely to be used.
Standards-Based Tooling Reduces Vendor Lock-In
Both projects generate CycloneDX format SBOMs, an OWASP supported standard. This is important for compliance teams managing multiple requirements: PCI DSS v4.0.1 Requirement 6.3.2 requires maintaining an inventory of bespoke and custom software. NIST 800-53 Rev 5 control SA-15 includes development process documentation. ISO 27001 requires asset inventories. A standardized SBOM format allows you to generate once and map to multiple frameworks.
The Funding Model Scales
GitHub's SOSF provides more than just funding—it offers security training, code review expertise, and infrastructure support. This model addresses the main constraint in open-source security: maintainer time and expertise. Structured training helps convert domain expertise into security-aware development.
What This Means for Your Team
If you're building or maintaining a compliance program, this funding shift has three immediate implications:
Your SBOM tooling is getting more reliable. The projects you're using now have dedicated resources for security hardening, reducing the risk of vulnerabilities in SBOM generation.
CI/CD integration is becoming essential. If your SBOM process involves manual exports or separate scanning tools, you're behind. Modern compliance tooling runs in-pipeline, generates artifacts automatically, and fails builds on policy violations.
Standards-based formats give you negotiating room. When auditors ask for a software inventory, you can provide a CycloneDX SBOM and map it to their requirements instead of creating custom reports.
Action Items by Priority
Priority 1: Audit Your Current SBOM Generation
Identify where SBOMs are generated in your build process. If it's manual or nonexistent, start there. Ensure the format is standards-based (CycloneDX or SPDX) and machine-readable.
Priority 2: Integrate SBOM Generation into CI/CD
Add SBOM generation as a build step. For .NET projects, evaluate CycloneDX .NET's GitHub Actions integration. For polyglot environments, cdxgen supports multiple package managers. Aim for every build to produce an SBOM artifact versioned alongside the binary.
Priority 3: Map SBOMs to Your Compliance Requirements
Document which compliance obligations your SBOMs satisfy. For PCI DSS v4.0.1 Requirement 6.3.2, note that your SBOM provides the required inventory of bespoke software. For SOC 2 Type II change management controls (CC8.1), your versioned SBOMs demonstrate changes between releases. For NIST 800-53 Rev 5 SA-15, they document your development environment's dependencies.
Priority 4: Establish SBOM Retention and Access Policies
Decide how long to keep SBOMs (hint: match your binary retention policy) and who can access them. SBOMs contain your dependency tree—useful for security teams but sensitive if they reveal proprietary components. Define access controls before accumulating unprotected SBOM files.
Priority 5: Monitor for Funded Tool Updates
Projects with SOSF backing will release security improvements and new features more rapidly than unfunded alternatives. Subscribe to release notes for cdxgen and CycloneDX .NET. Evaluate new features for reducing manual work in your compliance program.
