By February 2023, the conversation around SBOMs had shifted. Organizations were no longer asking "what is an SBOM?" — they were asking "how do I share it?" The generation tooling had matured significantly, but the practices around distribution, access control, and lifecycle management were still nascent.
Generating an SBOM is a technical problem with well-understood solutions. Sharing an SBOM is a business problem with organizational, legal, and security dimensions that most teams haven't thought through.
The Distribution Challenge
An SBOM contains detailed information about every component in your software. That information is valuable for security — but it's also valuable for attackers. A detailed SBOM tells an attacker exactly what libraries and versions you're running, making it easier to identify exploitable vulnerabilities.
This creates a tension: SBOMs need to be available to those who need them (customers, regulators, security teams) while not being freely available to attackers.
Who Needs Your SBOM?
Customers: Enterprise customers increasingly require SBOMs as part of vendor risk assessments. They need to know what's in the software they're deploying in their environment.
Regulators: The FDA, CISA, and other regulatory bodies require or recommend SBOMs for specific use cases. These requirements are expanding.
Internal security teams: Your own security team needs SBOMs to monitor for newly discovered vulnerabilities in deployed software.
Incident responders: When a new CVE is disclosed, incident responders need to quickly determine which products and deployments are affected.
Auditors: Compliance auditors may need to verify software composition as part of security assessments.
Distribution Models
1. Embedded Distribution
Include the SBOM as part of the software package itself — in the Docker image, the installer, or the application bundle.
Pros:
- SBOM always accompanies the software it describes
- No separate distribution infrastructure needed
- Easy to verify the SBOM matches the software
Cons:
- Increases package size
- Anyone who obtains the software gets the full SBOM
- Updates to the SBOM require a new software release
2. API-Based Distribution
Provide SBOMs through an authenticated API that customers and partners can query.
Pros:
- Access control — only authorized parties can retrieve SBOMs
- Can provide real-time vulnerability information alongside the SBOM
- SBOMs can be updated independently of software releases
- Supports querying by version, component, or CVE
Cons:
- Requires building and maintaining API infrastructure
- Adds an availability dependency
- Customers need to integrate with your API
3. Portal Distribution
Provide SBOMs through a customer portal where authenticated users can download them.
Pros:
- Familiar user experience for most enterprise customers
- Access control through existing customer authentication
- Can include additional context and documentation
Cons:
- Manual process — doesn't scale for automation
- Customers need to remember to check for updates
- Portal availability becomes a dependency
4. Registry Distribution
Publish SBOMs to a dedicated SBOM registry or repository, similar to how packages are published to npm or PyPI.
Pros:
- Standardized format and access patterns
- Can leverage existing infrastructure (OCI registries)
- Supports automated retrieval and processing
Cons:
- Ecosystem is still emerging
- Limited access control options in some registries
- Requires adoption of registry standards
Format Considerations
SPDX vs. CycloneDX
Both formats are widely supported and acceptable for most use cases:
SPDX (System Package Data Exchange):
- ISO/IEC 5962:2021 international standard
- Strong support for license information
- Supported by the Linux Foundation
- Formats: JSON, YAML, RDF, tag-value
CycloneDX:
- OWASP project
- Strong support for vulnerability information
- Native support for VEX (Vulnerability Exploitability eXchange)
- Formats: JSON, XML, Protocol Buffers
For most organizations, the choice between SPDX and CycloneDX is less important than consistency. Pick one and use it across your organization.
VEX: The SBOM Companion
A VEX (Vulnerability Exploitability eXchange) document accompanies an SBOM and specifies which known vulnerabilities actually affect the product. A component might have a known CVE, but if the vulnerable code path isn't reachable in your product, VEX lets you communicate that.
VEX documents are essential for making SBOMs actionable. Without VEX, an SBOM consumer sees every CVE in every component and has no way to prioritize.
Access Control Best Practices
Authenticate All Access
Don't publish SBOMs on unauthenticated URLs. Even if the SBOM is for an open-source project, knowing the exact versions of every dependency in a specific deployment is useful to attackers.
Role-Based Access
Different stakeholders need different information:
- Security teams: Full SBOM with vulnerability details
- Compliance auditors: License information and component inventory
- Procurement: Vendor and component summary information
- Incident responders: Quick lookup by CVE or component
Audit Access
Log who accesses SBOMs and when. This helps detect unauthorized access and supports compliance requirements.
Time-Limit Access
Access to SBOMs for old product versions should be reviewed periodically. When a customer relationship ends, their access to your SBOMs should be revoked.
Lifecycle Management
Versioning
Every software release should have a corresponding SBOM version. The SBOM should be linked to the specific build it represents.
Updates
When vulnerability information changes (new CVEs, updated VEX status), the SBOM or its companion VEX document should be updated and stakeholders should be notified.
Retention
SBOMs should be retained for at least as long as the software version they describe is in use. For regulated industries, retention requirements may be longer.
Revocation
If an SBOM is found to be inaccurate, there should be a mechanism to revoke it and issue a corrected version.
How Safeguard.sh Helps
Safeguard.sh provides comprehensive SBOM lifecycle management:
- Automated Generation: Safeguard.sh generates SBOMs automatically as part of your build process, in both SPDX and CycloneDX formats.
- Centralized Management: Safeguard.sh provides a central platform for storing, versioning, and managing SBOMs across your entire product portfolio.
- Secure Distribution: Safeguard.sh offers authenticated access to SBOMs with role-based access control, ensuring the right people have access to the right information.
- Continuous Monitoring: Safeguard.sh monitors your SBOMs against vulnerability databases and automatically updates vulnerability status, reducing the manual effort required to keep SBOMs current.
SBOM generation is the foundation. But the real value comes from distribution, monitoring, and lifecycle management — turning a static document into a living tool for supply chain security.