sbomasm is a comprehensive toolkit for managing Software Bill of Materials (SBOMs) throughout their lifecycle. From assembling multiple SBOMs into unified documents, to editing metadata for compliance, removing sensitive information, and enriching with additional context - sbomasm handles it all.
# Install sbomasm
go install github.com/interlynk-io/sbomasm@latest
# Assemble multiple SBOMs into one
sbomasm assemble -n "my-app" -v "1.0.0" -o final.json service1.json service2.json service3.json
# Edit SBOM metadata for compliance
sbomasm edit --subject document --supplier "ACME Corp (acme.com)" --timestamp sbom.json
# Remove sensitive information
sbomasm rm --subject component-data --search "internal-tool" sbom.json
# Enrich SBOM with missing license information
sbomasm enrich --fields license -o enriched.json sbom.json
# Generate assembly configuration
sbomasm generate > config.yml- Community Recognition
- Why sbomasm?
- Core Features
- Basic Usage
- Industry Use Cases
- Advanced Features
- Command Reference
- SBOM Platform - Free Community Tier
- SBOM Card
- Installation
- Contributions
- Other SBOM Open Source tools
- Contact
- Stargazers
sbomasm has gained recognition across the SBOM ecosystem for its innovative approach to SBOM management:
OpenChain Telco SBOM Guide v1.1 (2025) references sbomasm as a recommended tool for telco operators managing complex software supply chains, particularly for its ability to merge and validate SBOMs across multiple vendors and formats.
SBOM Generation White Paper (SBOM Community, February 2025) highlights sbomasm as an exemplary tool that "demonstrates best practices in SBOM assembly, particularly its format-agnostic approach and preservation of component relationships during merging operations."
“I found several bugs, mostly invalid SPDX, but they were quickly fixed. The team is very reactive. The tool now produces valid SPDX for all examples I have tested...”
— Marc-Étienne Vargenau (Nokia), SPDX Implementers Mailing List
"The hierarchical merge capability in sbomasm is exactly what we needed for assembling microservice SBOMs while preserving their dependency relationships. It's become an essential part of our DevSecOps pipeline."
— Fortune 500 Financial Services CISO
"For medical device manufacturers needing FDA-compliant SBOMs, sbomasm's edit functionality has been a game-changer. We can now ensure all required metadata is present before submission."
— Medical Device Manufacturer, Regulatory Affairs
- GitLab/GitHub CI: Widely adopted in CI/CD pipelines for automated SBOM assembly
Modern software development involves complex supply chains with multiple components, each potentially having its own SBOM. Organizations face several challenges:
- Multiple Sources: Microservices, containers, and third-party components each generate separate SBOMs
- Compliance Requirements: Regulations like FDA medical device requirements, Auto-ISAC standards, and CISA guidelines require complete and accurate SBOMs
- Metadata Gaps: Generated SBOMs often lack critical metadata like supplier information, licenses, or proper versioning
- Sensitive Data: SBOMs may contain internal component names or proprietary information that shouldn't be shared
- Format Fragmentation: Different tools produce different SBOM formats (SPDX vs CycloneDX)
sbomasm solves these challenges with a unified toolkit that works across formats and use cases.
- 🔀 Assemble: Merge multiple SBOMs into comprehensive documents
- ✏️ Edit: Add or modify metadata for compliance and completeness
- 🗑️ Remove: Strip sensitive components or fields
- 🚀 Enrich: Augment SBOMs with missing license information from ClearlyDefined
- 📋 Format Agnostic: Supports both SPDX and CycloneDX
- ⚡ Blazing Fast: Optimized for large-scale operations
- 🔧 Flexible: CLI, configuration files, and API integration options
The most common use case is combining multiple SBOMs from different sources into a single comprehensive document.
Combine microservice SBOMs into an application SBOM:
# Basic assembly with automatic format detection
sbomasm assemble \
-n "e-commerce-platform" \
-v "2.1.0" \
-t "application" \
-o platform.cdx.json \
auth-service.json cart-service.json payment-service.jsonMerge container base image SBOM with application dependencies:
# Combine base image SBOM with application SBOM
sbomasm assemble \
-n "containerized-app" \
-v "1.0.0" \
--type "container" \
-o final-container.spdx.json \
alpine-base.spdx.json app-deps.spdx.jsonFix missing metadata or update information for compliance:
# Add supplier info required by procurement
sbomasm edit \
--missing \
--subject document \
--supplier "Interlynk (hello@interlynk.io)" \
--output compliant.json \
original.json# Fix missing license information
sbomasm edit \
--subject component-name-version \
--search "log4j (2.17.1)" \
--license "Apache-2.0 (https://www.apache.org/licenses/LICENSE-2.0)" \
input.jsonRemove internal or sensitive components before sharing:
# Remove internal components before sharing with customer
sbomasm rm \
--subject component-name \
--search "internal-telemetry" \
--output public.json \
internal.jsonEnhance SBOMs with missing license information using ClearlyDefined data:
# Enrich SBOM with missing license information
sbomasm enrich \
--fields license \
--output enriched.json \
original.json# Force update existing licenses with more complete data
sbomasm enrich \
--fields license \
--force \
--license-exp-join "AND" \
--max-retries 3 \
--max-wait 10 \
--output complete.json \
incomplete.jsonThis command is particularly useful for:
- Filling gaps in automatically generated SBOMs that lack license information
- Ensuring compliance with procurement and legal requirements
- Standardizing license expressions across components
- Meeting regulatory requirements that mandate complete license documentation
Modern cloud-native applications consist of dozens of microservices, each with their own dependencies. Organizations using Kubernetes need to track components across:
- Application code dependencies
- Container base images
- Kubernetes operators and controllers
- Service mesh components
Example: A fintech company running 50+ microservices on Kubernetes:
# Step 1: Collect SBOMs from CI/CD pipeline
# Each build generates an SBOM for the service
# Step 2: Assemble daily platform SBOM
sbomasm assemble \
-n "trading-platform" \
-v "$(date +%Y.%m.%d)" \
-t "application" \
--flat-merge \
-o daily-platform-sbom.json \
services/*.json
# Step 3: Add compliance metadata
sbomasm edit \
--subject document \
--supplier "FinTech Corp (fintech.com)" \
--tool "sbomasm (v0.1.0)" \
--timestamp \
daily-platform-sbom.json
# Step 4: Remove internal debugging tools
sbomasm rm \
--subject component-name \
--search "debug-console" \
daily-platform-sbom.jsonAutomotive manufacturers must comply with Auto-ISAC guidelines and track software across complex supply chains involving hundreds of suppliers.
Example: An electric vehicle manufacturer tracking infotainment system components:
# Assemble SBOMs from tier-1 suppliers
sbomasm assemble \
-n "infotainment-system" \
-v "model-y-2025" \
-t "firmware" \
-o infotainment-complete.spdx.json \
navigation-vendor.spdx audio-vendor.spdx connectivity-vendor.spdx
# Add automotive-specific metadata
sbomasm edit \
--subject primary-component \
--cpe "cpe:2.3:a:automaker:infotainment:2025.1:*:*:*:*:*:*:*" \
--lifecycle "manufacture" \
--output auto-compliant.spdx.json \
infotainment-complete.spdx.jsonFDA regulations require medical device manufacturers to provide comprehensive SBOMs. These must include all software components and their security status.
Example: Medical imaging device SBOM preparation:
# Create configuration for FDA submission
cat > fda-config.yml << EOF
app:
name: 'MRI-Scanner-Software'
version: 'v3.2.0'
description: 'MRI Scanner Control System - FDA Submission'
type: 'device'
supplier:
name: 'MedTech Inc'
email: 'regulatory@medtech.com'
author:
- name: 'MedTech Regulatory Team'
email: 'regulatory@medtech.com'
output:
spec: spdx
file_format: json
assemble:
hierarchical_merge: true
include_components: true
include_dependency_graph: true
EOF
# Assemble with configuration
sbomasm assemble -c fda-config.yml -o fda-submission.json \
imaging-software.json hardware-drivers.json third-party-libs.jsonFinancial institutions need SBOMs for risk assessment and regulatory compliance (PCI-DSS 4.0).
Example: Banking application quarterly compliance report:
# Assemble quarterly SBOM from all banking services
sbomasm assemble \
-n "digital-banking-platform" \
-v "2024-Q4" \
-o quarterly-sbom.cdx.json \
core-banking/*.json mobile-app/*.json web-portal/*.json
# Enrich with security metadata
sbomasm edit \
--subject document \
--tool "dependency-track (4.11.0)" \
--author "Security Team (security@bank.com)" \
--lifecycle "operations" \
quarterly-sbom.cdx.jsonFor complex assembly operations, use configuration files:
# assembly-config.yml
app:
name: 'enterprise-platform'
version: 'v2.0.0'
type: 'application'
supplier:
name: 'Enterprise Corp'
email: 'sbom@enterprise.com'
licenses:
- id: 'Apache-2.0'
output:
spec: cyclonedx
file_format: json
file: 'enterprise-platform.cdx.json'
assemble:
flat_merge: true
include_components: true
include_dependency_graph: falsesbomasm assemble -c assembly-config.yml services/*.jsonIntegrate with Dependency Track for continuous SBOM monitoring:
# Pull SBOMs from Dependency Track, assemble, and push back
sbomasm assemble dt \
-u "https://dtrack.company.com" \
-k "$DT_API_KEY" \
-n "aggregated-view" \
-v "latest" \
--flat-merge \
-o "project-uuid" \
project-uuid-1 project-uuid-2 project-uuid-3Process multiple SBOMs with shell scripting:
#!/bin/bash
# batch-process.sh - Add supplier info to all SBOMs
for sbom in sboms/*.json; do
echo "Processing $sbom..."
sbomasm edit \
--missing \
--subject document \
--supplier "ACME Corp (acme.com)" \
--timestamp \
--output "processed/$(basename $sbom)" \
"$sbom"
doneDetailed documentation for each command:
- assemble - Merge multiple SBOMs
- edit - Modify SBOM metadata
- rm - Remove components or fields
- enrich - Enrich SBOMs with missing license information
- generate - Create configuration templates
Our SBOM Automation Platform has a free community tier that provides a comprehensive solution to manage SBOMs (Software Bill of Materials) effortlessly. From centralized SBOM storage, built-in SBOM editor, continuous vulnerability mapping and assessment, and support for organizational policies, all while ensuring compliance and enhancing software supply chain security using integrated SBOM quality scores. The community tier is ideal for small teams. Learn more here or Sign up
go install github.com/interlynk-io/sbomasm@latestbrew tap interlynk-io/interlynk
brew install sbomasmdocker run -v $(pwd):/app ghcr.io/interlynk-io/sbomasm:latest assemble \
-n "my-app" -v "1.0.0" -o /app/output.json /app/input1.json /app/input2.jsonDownload from releases page
git clone https://github.com/interlynk-io/sbomasm.git
cd sbomasm
make build
./build/sbomasm versionWe look forward to your contributions! Please follow these guidelines:
- Fork the repo
- Create your feature/bug branch (
git checkout -b feature/amazing-feature) - Commit your changes (
git commit -sam "Add amazing feature") - commits must be signed - Push to the branch (
git push origin feature/amazing-feature) - Create a Pull Request
See CONTRIBUTING.md for detailed guidelines.
- SBOM Seamless Transfer - A primary tool to transfer SBOMs between different systems
- SBOM Quality Score - A tool for evaluating the quality and compliance of SBOMs
- SBOM Search Tool - A tool for context-aware search in SBOM repositories
- SBOM Explorer - A tool for discovering and downloading SBOMs from public repositories
- SBOM Benchmark - A repository of SBOMs and quality scores for popular containers and repositories
We appreciate all feedback. The best ways to get in touch with us:
- ❓&
🅰️ Slack - 📞 Live Chat
- 📫 Email Us
- 🐛 Report a bug or enhancement
- 🐦 Follow us on X
If you like this project, please support us by starring it.
