Distribute to Customers
Publication mechanisms and delivery channels for SBOM sharing
Creating high-quality, validated SBOMs delivers no value if customers cannot access them. The distribution problem is both technical (how to make files available) and operational (how customers discover availability, how to handle access control, how to communicate updates). Software producers must design distribution strategies that balance accessibility, security, automation, and customer experience.
Effective distribution means customers receive SBOMs automatically when they need them, through channels that integrate with their existing workflows, without creating operational friction that discourages adoption. Poor distribution means SBOMs sit unused in producer systems while customers struggle to obtain or integrate them, undermining transparency objectives.
Distribution Strategy Considerations
Choosing appropriate distribution approach requires balancing multiple factors specific to your products, customers, and business model.
Public vs. Controlled Access
Public distribution: SBOMs are freely available without authentication or authorization. Anyone can download. Appropriate when software itself is publicly distributed (open source projects, freely downloadable applications, SaaS products with no competitive sensitivity).
Benefits: Frictionless access, broad transparency, no distribution infrastructure overhead. Simple static file hosting suffices.
Risks: Competitive intelligence exposure if SBOM reveals strategic technology choices. Potential scrutiny of dependency hygiene before customers commit to purchase. No ability to track who's accessing SBOMs.
Controlled access: SBOMs require authentication and authorization. Only licensed customers, partners under NDA, or authorized personnel can access. Appropriate for proprietary enterprise software, products with competitive sensitivity, or regulatory compliance requirements limiting disclosure.
Benefits: Control over who sees component composition, ability to track access, compliance with confidentiality requirements. Can provide different SBOM variants to different customer classes.
Risks: Access control infrastructure complexity, friction in customer experience, delays when customers need urgent access during incidents. Key management and authentication overhead.
Push vs. Pull Distribution
Push distribution: Producer actively sends SBOMs to customers. Email attachments, automated delivery to customer SBOM repositories, portal notifications. Customer receives SBOMs without requesting them.
Benefits: Ensures customers have current SBOMs, works for customers without sophisticated infrastructure, good for critical updates requiring customer awareness.
Risks: Requires maintaining current customer contact database, email deliverability issues, spam filtering, customers overwhelmed by unrequested files. Doesn't scale well for products with thousands of customers.
Pull distribution: Customers retrieve SBOMs from producer-operated repository or download location. Customer initiates transfer when needed.
Benefits: Scales to arbitrary customer count, customers access on their schedule, integrates with customer automation, reduces producer overhead.
Risks: Customers must know SBOMs exist and where to find them, passive approach means some customers never discover availability, requires customer-side automation for full benefit.
Hybrid approach: Combine methods. Notify customers via email when new SBOMs available (push notification), but actual SBOM retrieval happens via download (pull mechanism). Provides awareness benefits of push with scalability of pull.
Format and Variant Management
Single format: Provide SBOMs in one format only (typically CycloneDX or SPDX). Simpler for producer, but some customers may need format conversion for toolchain compatibility.
Multiple formats: Provide same SBOM content in both CycloneDX and SPDX formats. Customers choose preferred format. Increases producer overhead (maintain dual formats, validation, signing) but improves customer experience.
Granularity variants: Offer different SBOM depths for different customer needs. "Basic" SBOM with direct dependencies only for general transparency. "Complete" SBOM with full transitive tree for security analysis. Allows balancing disclosure comfort with customer requirements.
Redacted versions: Provide standard SBOM to most customers but redacted versions hiding competitive-sensitive components for broader distribution. Useful when some transparency is better than none but full disclosure is problematic.
Distribution Channels
Static File Hosting
Simplest distribution mechanism: host SBOM files on web server or object storage.
Implementation pattern:
https://sbom.example.com/
├── product-a/
│ ├── v1.2.3/
│ │ ├── sbom.json
│ │ ├── sbom.json.sig
│ │ └── sbom.spdx.json
│ ├── v1.2.4/
│ │ ├── sbom.json
│ │ ├── sbom.json.sig
│ │ └── sbom.spdx.json
│ └── latest/ (symlink to newest version)
│ ├── sbom.json
│ └── sbom.json.sig
├── product-b/
│ └── v2.0.1/
│ └── sbom.json
└── index.json (machine-readable catalog)Predictable URL structure allows automation: https://sbom.example.com/{product}/{version}/sbom.json. Customers can programmatically construct URLs without discovery protocols.
Access control for controlled distribution: Use CDN with authentication (Cloudflare Access, AWS CloudFront with signed URLs), HTTP basic auth, or certificate-based authentication. Trade-off: adds complexity but provides necessary access control.
Advantages: Simple infrastructure, high availability through CDN, easy to implement, works with customer automation, scalable to arbitrary file counts.
Disadvantages: No built-in discovery mechanism beyond directory structure, no notification capability, requires customers know where to look, version management is manual.
SBOM Repository Systems
Dedicated SBOM repository tools provide structured storage, search, access control, and API access.
Example systems:
- Dependency-Track (open source, comprehensive SBOM and VEX management)
- SBOM Observer (commercial, enterprise-focused)
- OSS Review Toolkit (open source, supply chain tooling including SBOM management)
API-based access pattern:
# Customer queries for product SBOM
curl -H "Authorization: Bearer €API_TOKEN" \
https://sbom-api.example.com/v1/products/product-a/versions/1.2.3/sbom
# Customer subscribes to update notifications
curl -X POST \
-H "Authorization: Bearer €API_TOKEN" \
-d '{"product": "product-a", "webhook": "https://customer.com/sbom-updates"}' \
https://sbom-api.example.com/v1/subscriptionsAdvantages: Professional-grade features (search, versioning, access control, notifications, audit logs), API-first design enables automation, structured metadata beyond just files, supports discovery protocols.
Disadvantages: Infrastructure setup and maintenance overhead, learning curve for producers and customers, potential vendor lock-in for commercial solutions, requires customers adapt to your repository's API.
Software Repository Integration
Embed SBOMs into existing software distribution mechanisms.
Container registries: Attach SBOMs to container images as artifacts using OCI registry conventions. SBOM is stored alongside image layers, accessed using same registry authentication.
# Attach SBOM to container image
oras attach --artifact-type application/cyclonedx+json \
registry.example.com/app:v1.2.3 sbom.json
# Customer retrieves SBOM
oras pull registry.example.com/app:v1.2.3 \
--artifact-type application/cyclonedx+jsonBenefits: SBOM travels with software artifact it describes, no separate distribution channel needed, existing authentication and authorization apply, versioning inherently synchronized.
Package managers: Include SBOM in package metadata for npm, Maven, PyPI, NuGet distributions. SBOM becomes part of package itself.
// npm package.json
{
"name": "example-package",
"version": "1.2.3",
"sbom": "./sbom.json",
// ... other fields
}Benefits: SBOM bundled with software, customers receive automatically when installing package, no separate retrieval needed.
Challenges: Package size implications, not all package ecosystems support SBOM metadata, customers may not have tooling to extract/use embedded SBOMs.
Release attachments: Include SBOMs as release assets in GitHub Releases, GitLab Releases, or similar distribution platforms.
# GitHub release with SBOM attachment
gh release create v1.2.3 \
./binary \
./sbom.json \
./sbom.json.sig \
--title "Release v1.2.3" \
--notes "See attached SBOM for component details"Benefits: Leverages existing release infrastructure, SBOMs visible to anyone viewing releases, download mechanics already familiar to customers.
Customer Portal Integration
For enterprise software with existing customer portals, integrate SBOM access into portal experience.
Portal features:
- Customer logs into support/license portal
- Downloads section includes SBOMs alongside installation packages and documentation
- Per-customer access control based on licensed products
- Notification preferences for SBOM updates
- Historical SBOM versions for deployed product versions
Implementation approach: Customer portal backend queries SBOM repository API, applies license-based filtering, presents results in unified interface. Customer experience is seamless—one authentication, one interface for all vendor resources.
Benefits: Matches customer expectations for enterprise software, leverages existing authentication infrastructure, allows product-specific access control, provides consistent experience across different vendor offerings.
Challenges: Portal development overhead, requires integration between customer management systems and SBOM repositories, portal becomes single point of failure for multiple resources.
Email Distribution
Direct email delivery for push distribution scenarios or small customer bases.
Automated email workflow:
# Triggered by release pipeline
send-sbom-notification:
runs-on: ubuntu-latest
steps:
- name: Render email template
run: |
cat > email.txt <<EOF
Subject: SBOM Available for Product v€{{ github.ref_name }}
A new SBOM is available for Product version €{{ github.ref_name }}.
Download: https://sbom.example.com/product/€{{ github.ref_name }}/sbom.json
Signature: https://sbom.example.com/product/€{{ github.ref_name }}/sbom.json.sig
Verification instructions: https://example.com/sbom-verification
Key changes from previous version: ...
EOF
- name: Send to customer mailing list
run: |
sendmail customers@example.com < email.txtWhen email makes sense: Small customer count (dozens, not thousands), high-touch enterprise relationships where personal communication is expected, critical updates requiring explicit customer acknowledgment, regulatory requirements for explicit notification.
When email doesn't scale: Large customer bases (spam filters, deliverability issues), frequent releases (notification fatigue), automated customer workflows (email doesn't integrate well with automation), need for structured machine-readable distribution.
Discovery Mechanisms
Distribution is useless if customers don't know SBOMs exist or where to find them. Explicit discovery support reduces friction.
Documentation and Communication
Product documentation: Include SBOM distribution information in standard product documentation. Security section explains: "SBOMs are available for all releases at https://sbom.example.com/{product}/{version}/sbom.json. See verification instructions at [link]."
Release notes: Every release announcement mentions SBOM availability. "Version 1.2.3 released. SBOM: [link]." Normalizes SBOM as standard release artifact.
Website prominent placement: Dedicated SBOM page on company website explaining philosophy, providing links to repositories, offering verification instructions. Positions transparency as organizational value.
Machine-Readable Discovery
/.well-known/sbom:
Proposed standard location for SBOM metadata. Customer queries https://example.com/.well-known/sbom and receives structured information about available SBOMs and access methods.
{
"sboms": [
{
"product": "example-app",
"version": "1.2.3",
"formats": ["application/cyclonedx+json", "application/spdx+json"],
"url": "https://sbom.example.com/example-app/v1.2.3/",
"published": "2024-01-15T10:30:00Z"
}
],
"contact": "security@example.com",
"documentation": "https://example.com/sbom-docs"
}Allows automated tools to discover SBOM availability without human intervention.
In-product metadata:
Software includes manifest file or API endpoint revealing its SBOM location. Running application exposes /api/sbom-location returning URL where SBOM can be retrieved. Enables runtime discovery—customer deploys software, queries for SBOM location, automatically retrieves and ingests.
Update Notification
When SBOMs change (new releases, updated VEX status), notifying customers enables timely awareness.
Webhook subscriptions: Customers register webhook URLs that receive notifications when relevant SBOMs update. SBOM repository system calls customer webhooks with update metadata.
POST https://customer.com/sbom-webhook
{
"event": "sbom.updated",
"product": "example-app",
"version": "1.2.4",
"sbom_url": "https://sbom.example.com/example-app/v1.2.4/sbom.json",
"changes": {
"components_added": 2,
"components_removed": 1,
"vulnerabilities_fixed": 3
},
"published": "2024-01-20T08:15:00Z"
}Customer automation receives webhook, fetches updated SBOM, ingests into internal systems. Fully automated transparency pipeline.
RSS/Atom feeds: Publish RSS feed of SBOM updates. Customers subscribe using feed readers or automation tools polling for updates. Lower-tech alternative to webhooks, but proven and reliable.
Email digests: Periodic email summaries of SBOM changes for subscribed customers. "Three products you licensed received SBOM updates this week: Product A v1.2.4 (3 vulnerability fixes), Product B v2.0.1 (dependency updates), Product C v1.5.2 (no security changes)." Balances awareness with inbox management.
Access Control Implementation
For controlled distribution, implement appropriate access mechanisms without creating excessive friction.
API Token Authentication
Pattern: Customers request API token through customer portal or support channel. Token grants access to SBOMs for licensed products. Include token in API requests or download URLs.
# Token in header
curl -H "Authorization: Bearer abc123..." \
https://sbom-api.example.com/product-a/v1.2.3/sbom.json
# Token in URL (less secure, more convenient)
curl https://sbom.example.com/product-a/v1.2.3/sbom.json?token=abc123...Token management: Scope tokens to specific products based on customer licenses. Rotate tokens periodically. Revoke tokens when licenses expire or on customer request. Audit token usage to detect sharing or abuse.
Certificate-Based Authentication
Pattern: Customers present client certificates for authentication. Certificates issued to licensed customers based on verified identity. Mutual TLS validates both server and client.
# Access with client certificate
curl --cert customer.pem --key customer-key.pem \
https://sbom.example.com/product-a/v1.2.3/sbom.jsonMore secure than token authentication but higher setup friction. Appropriate for high-security contexts, government customers, or when certificate infrastructure already exists.
IP Allowlisting
Pattern: Customers provide IP ranges, access allowed only from those addresses. Simple for customers with stable infrastructure, problematic for dynamic environments or remote workers.
Useful as additional security layer combined with other authentication, but insufficient as sole control mechanism.
Performance and Scalability
Distribution infrastructure must handle both routine access and spike loads during incidents when many customers simultaneously request SBOMs.
Content delivery networks: Use CDN for static file hosting to achieve global low-latency access and handle traffic spikes. CloudFront, Cloudflare, Fastly provide massive scale without infrastructure management overhead.
Caching strategies: SBOM content rarely changes after publication. Aggressive caching (long TTL) reduces origin load. Versioned URLs enable indefinite caching without staleness concerns.
Rate limiting: Protect against accidental or malicious overload with rate limits. Customer API tokens support per-customer rate limits. Public endpoints need global rate limiting.
Monitoring and alerting: Track SBOM download rates, error rates, access patterns. Alert on anomalies suggesting infrastructure problems or security issues. Measure latency to ensure acceptable customer experience.
Communication Best Practices
Distribution mechanics matter, but clear communication ensures customers understand availability and usage.
Initial announcement: When first offering SBOMs, explicitly communicate availability, access methods, formats, update frequency. "Beginning with release 1.2.3, we provide SBOMs for all products. Access at [URL]. Questions? Contact [email]."
Documentation: Maintain comprehensive, customer-facing documentation covering: What is SBOM?, Why we provide them, Where to find them, How to verify authenticity, How to request support, How to report discrepancies.
Support training: Ensure customer support teams understand SBOM distribution so they can answer questions. Common questions: "Where's the SBOM?", "How do I verify the signature?", "Why doesn't the SBOM match what I see?", "Can I get historical SBOMs?"
Feedback loops: Provide mechanism for customers to report access problems, request formats or features, suggest improvements. Distribution strategy should evolve based on customer needs.
Common Distribution Mistakes
Mistake 1: Obscure URLs or locations SBOMs exist but customers can't find them because location isn't documented, URLs are non-obvious, or no discovery mechanism exists.
Prevention: Publish clear documentation, use predictable URL patterns, implement discovery standards, communicate proactively.
Mistake 2: Excessive access friction Authentication process is complex, tokens expire frequently, certificate setup requires specialized knowledge. Customers give up rather than navigate obstacles.
Prevention: Balance security with usability. Provide clear setup instructions. Offer multiple access methods accommodating different customer capabilities.
Mistake 3: No update notifications New SBOMs published but customers unaware. Continue using stale SBOMs, missing vulnerability fixes or important changes.
Prevention: Implement notification mechanisms (webhooks, feeds, emails). Make subscription easy and obvious.
Mistake 4: Inconsistent distribution across products Product A uses email distribution, Product B uses download portal, Product C doesn't offer SBOMs. Customers confused about where to look.
Prevention: Standardize distribution approach across product portfolio. Consistent experience reduces customer burden.
Mistake 5: Ignoring customer feedback Customers request different formats, complain about access problems, or suggest improvements, but feedback goes unaddressed.
Prevention: Treat SBOM distribution as product feature requiring ongoing development. Incorporate customer feedback, measure satisfaction, continuously improve.
Maturity Progression
Level 1 (Basic): Email distribution or static file hosting. Manual upload process. No automated notifications. Basic documentation. Single format.
Level 2 (Advanced): Automated distribution integrated with release pipelines. Repository system with API access. Webhook notifications. Comprehensive discovery mechanisms. Multiple formats. Performance optimization through CDN. Audit logging and access analytics.
Progression requires infrastructure investment but dramatically improves customer experience and adoption.
Next Steps
- Prepare SBOMs through Validate and Sign
- Handle ongoing changes via Publish VEX
- Understand customer perspective in Request from Suppliers
- Review access models in Security and Access Control