1. Purpose
The Software Bill of Materials (SBOM) provides a structured inventory of software components contained within or used to build a software product, application, service, or release.
The SBOM helps the organization understand:
- What software components are included
- Which versions are being used
- Where components originate
- Which components are direct or transitive dependencies
- Which components may contain known vulnerabilities
- Which components are unsupported or outdated
- Which licenses apply
- Which applications or releases are affected by a vulnerability
- What third-party software contributes to the software supply chain
The SBOM supports software supply-chain security, vulnerability management, secure development, incident response, and risk assessment.
2. Scope
An SBOM may include, where applicable:
- Open-source libraries
- Commercial libraries
- Frameworks
- Runtime components
- Operating-system packages
- Container images
- Container packages
- SDKs
- Plugins
- Application dependencies
- Transitive dependencies
- Build dependencies
- CI/CD components
- Infrastructure-as-Code dependencies
- Third-party software components
- AI/ML libraries and models
- Other software components included in the product
The level of SBOM coverage should be appropriate to the organization’s technology and risk.
3. SBOM Identification
| Field | Details |
|---|---|
| SBOM ID | SBOM-[XXXX] |
| Product/Application | |
| Product Owner | |
| Application ID | |
| Release Version | |
| Build ID | |
| Build Date | |
| Release Date | |
| Repository | |
| Commit/Revision | |
| Build Pipeline | |
| Environment | |
| SBOM Format | CycloneDX / SPDX / Other |
| SBOM Specification Version | |
| Generation Tool | |
| Generator Version | |
| SBOM Owner | |
| Approval Status | |
| Classification | |
| Next Review |
4. Product Information
Product/Application Name:
[Enter name]
Description:
[Brief description]
Business Purpose:
[Purpose of the application]
Business Owner:
[Name/Role]
Technical Owner:
[Name/Role]
Production Status:
[Yes/No]
Customer-Facing:
[Yes/No]
Internet-Facing:
[Yes/No]
Criticality:
[Low/Medium/High/Critical]
5. SBOM Component Inventory
The following is the core component-level inventory.
| Component ID | Component Name | Version | Type | Direct/Transitive | Supplier/Maintainer | Source | License | Scope | Vulnerability Status |
|---|---|---|---|---|---|---|---|---|---|
| COMP-001 | Library | Direct | Runtime | ||||||
| COMP-002 | Library | Transitive | Runtime | ||||||
| COMP-003 | Framework | Direct | Runtime | ||||||
| COMP-004 | Container | Direct | Production |
6. Required Component Information
For each significant component, record:
Component Name
Official name of the software component.
Version
Exact version included in the release.
Component Type
Examples:
- Library
- Framework
- Package
- SDK
- Runtime
- Operating-system package
- Container
- Plugin
- Application
- Model
- API dependency
Supplier/Maintainer
Vendor, organization, project, or maintainer.
Source
Examples:
- Official package repository
- Vendor repository
- Internal repository
- Container registry
License
Applicable software license.
Dependency Type
- Direct
- Transitive
Scope
Examples:
- Runtime
- Build
- Development
- Test
- Production
- CI/CD
7. Component Identifiers
Where supported, record standardized identifiers.
Examples include:
- Package URL (PURL)
- CPE
- Supplier identifier
- Component identifier
- Hash
- Repository URL/reference
| Component | Version | PURL | CPE | Hash | Other Identifier |
|---|---|---|---|---|---|
Identifiers improve the ability to correlate components with vulnerability and security information.
8. Component Hash / Integrity
Where technically appropriate, record integrity information.
| Component | Version | Hash Algorithm | Hash | Verification Status |
|---|---|---|---|---|
Possible status:
- Verified
- Not Applicable
- Not Available
- Requires Review
Do not store secrets, private keys, credentials, or sensitive authentication information in the SBOM.
9. Dependency Relationships
The SBOM should identify relationships between components where the chosen format supports them.
Example:
Application
↓
React
↓
Dependency A
↓
Dependency B
Record:
| Parent Component | Relationship | Child Component |
|---|---|---|
| Application | Depends On | React |
| React | Depends On | Dependency A |
| Dependency A | Depends On | Dependency B |
This helps identify the impact of vulnerabilities in transitive dependencies.
10. Direct Dependencies
Direct dependencies are components intentionally included by the development team.
| Component | Version | Application | Purpose | Owner |
|---|---|---|---|---|
Examples:
- React
- Express
- Django
- Spring
- AWS SDK
11. Transitive Dependencies
Transitive dependencies are introduced through another dependency.
| Parent Dependency | Transitive Component | Version | Vulnerability Status | Risk |
|---|---|---|---|---|
Transitive dependencies should be considered because a vulnerability may exist in a component that the development team did not directly select.
12. Runtime Dependencies
Identify components required when the application executes.
Examples:
- Runtime libraries
- Database drivers
- Frameworks
- Operating-system packages
- Container base images
| Component | Version | Runtime Environment | Production Use |
|---|---|---|---|
| Yes/No |
13. Build Dependencies
Identify dependencies used to build the software.
Examples:
- Compilers
- Build tools
- Package managers
- Build plugins
- Build containers
Build dependencies can be important to software supply-chain security even if they are not included in the final production application.
14. Development and Test Dependencies
Where relevant, identify:
- Development libraries
- Testing frameworks
- Code-quality tools
- Test runners
- Development plugins
These may not be deployed to production but can still introduce risks into the development environment or build process.
15. Container Components
For containerized applications, identify:
- Base image
- Operating-system packages
- Runtime
- Application packages
- Libraries
- Container-specific components
Example:
Application Container
→ Linux Base Image
→ OS Packages
→ Node.js
→ npm Packages
→ Application Code
| Container | Base Image | Version | Registry | Vulnerabilities |
|---|---|---|---|---|
16. Infrastructure-as-Code Components
Where applicable, include:
- Terraform providers
- Terraform modules
- CloudFormation components
- Helm charts
- Kubernetes packages
- Infrastructure plugins
| Component | Version | Source | Environment | Risk |
|---|---|---|---|---|
17. CI/CD Components
Where applicable, include:
- GitHub Actions
- CI/CD plugins
- Build runners
- Deployment tools
- Security scanners
- Package-management tools
- Build containers
| Component | Version | Pipeline | Purpose | Risk |
|---|---|---|---|---|
CI/CD dependencies should receive appropriate attention because compromise of a build component can affect software delivered to production.
18. AI/ML Components
Where AI/ML functionality exists, the SBOM or related inventory may identify:
- ML frameworks
- AI libraries
- Model packages
- SDKs
- Model-serving components
- Vector-database components
- AI APIs
- External model providers
| Component/Model | Version | Provider | Source | Purpose | Data Exposure |
|---|---|---|---|---|---|
Where appropriate, AI model provenance and associated security risks should be tracked separately or linked to the organization’s AI governance records.
19. Vulnerability Mapping
The SBOM should be capable of being correlated with vulnerability information.
| Component | Version | Vulnerability ID | Severity | Exploitability | Exposure | Risk | Status |
|---|---|---|---|---|---|---|---|
| CVE-XXXX-XXXX | |||||||
Possible vulnerability sources include:
- Vendor advisories
- Package security advisories
- Vulnerability databases
- Software Composition Analysis tools
- Container scanners
- Security monitoring platforms
20. Vulnerability Assessment
A vulnerability identified in an SBOM should be assessed in context.
Consider:
- Is the vulnerable component actually deployed?
- Is the vulnerable functionality used?
- Is the application internet-facing?
- Is exploitation known?
- Is sensitive information accessible?
- Are compensating controls available?
- Is a patched version available?
- Can the component be removed?
- What is the business impact?
The SBOM identifies the component; the organization’s risk-management process determines the appropriate treatment.
21. Vulnerability Remediation
| Vulnerability | Component | Affected Version | Treatment | Owner | Target Date | Status | Verification |
|---|---|---|---|---|---|---|---|
| Upgrade | |||||||
| Replace | |||||||
| Remove | |||||||
| Compensating Control |
After remediation, the organization should verify that the affected version is no longer present or that the documented compensating control remains effective.
22. Unsupported Components
Identify components that are:
- End-of-life
- Deprecated
- No longer maintained
- No longer receiving security updates
- Unsupported by the vendor
| Component | Version | Support Status | Risk | Planned Action | Target Date |
|---|---|---|---|---|---|
| EOL |
23. License Inventory
Where relevant:
| Component | Version | License | License Risk | Review Status |
|---|---|---|---|---|
The SBOM should support license visibility but should not replace formal legal/license review where required.
24. SBOM Generation
The organization should define how SBOMs are generated.
Possible methods include:
- CI/CD pipeline
- Software Composition Analysis tool
- Package-manager tooling
- Container scanning tool
- SBOM generation platform
- Build process
Preferred process:
Source Code → Build → Dependency Discovery → SBOM Generation → Validation → Storage → Vulnerability Correlation
25. SBOM Validation
Before an SBOM is accepted, verify where applicable:
- Correct application identified
- Correct release version
- Correct build/commit
- Dependencies included
- Versions accurate
- Direct dependencies identified
- Transitive dependencies included where supported
- Container components included where applicable
- Identifiers populated
- SBOM format valid
- Generation date recorded
- Tool/version recorded
- SBOM stored in approved location
26. SBOM Storage
SBOMs should be stored in an appropriate controlled location.
Possible locations:
- Artifact repository
- Secure document repository
- GRC platform
- Security platform
- Release-management system
- Software supply-chain platform
Access should be restricted according to the sensitivity of the information contained in the SBOM.
27. SBOM Release Management
An SBOM should be associated with a specific software release.
Example:
| Application | Release | Build | SBOM | Date |
|---|---|---|---|---|
| Customer API | 2.4.1 | Build-8741 | SBOM-2026-041 | [Date] |
| Customer API | 2.4.2 | Build-8812 | SBOM-2026-042 | [Date] |
This allows the organization to determine which released versions contain an affected component.
28. SBOM Update Triggers
Generate or update an SBOM when:
- New software release occurs
- Dependency is added
- Dependency is removed
- Dependency version changes
- Container base image changes
- Major build changes
- Critical vulnerability is identified
- Build pipeline changes materially
- Significant third-party component changes
For modern CI/CD environments, generating an SBOM as part of the build/release pipeline can reduce manual effort.
29. SBOM Incident Response
During a software security incident, the SBOM can help answer:
- Is the affected component present?
- Which applications contain it?
- Which versions are affected?
- Which customers/releases may be affected?
- Is the component production-deployed?
- What dependencies use it?
- Has the vulnerable version been removed?
Example:
New Vulnerability Identified
↓
Search SBOM Repository
↓
Identify Affected Components
↓
Map Components to Releases
↓
Identify Exposure
↓
Assess Risk
↓
Patch/Replace/Mitigate
↓
Verify
↓
Generate Updated SBOM
30. AWS SaaS Startup Example
Consider a SaaS company running its application on AWS.
The production architecture contains:
- React frontend
- Node.js API
- PostgreSQL
- AWS SDK
- Docker container
- GitHub Actions
- Terraform
- Third-party npm packages
A simplified SBOM could contain:
| Component | Version | Type | Relationship | Environment |
|---|---|---|---|---|
| Customer API | 3.2.0 | Application | Root | Production |
| Node.js | [Version] | Runtime | Direct | Production |
| Express | [Version] | Framework | Direct | Production |
| Package A | [Version] | Library | Transitive | Production |
| AWS SDK | [Version] | SDK | Direct | Production |
| Ubuntu Base Image | [Version] | Container | Direct | Production |
| Terraform Provider | [Version] | IaC | Build/Deploy | Production |
| GitHub Action | [Version] | CI/CD | Build | CI/CD |
If a new vulnerability is announced for Package A, the organization can use the SBOM to determine whether the affected component exists in the production release.
The process becomes:
Vulnerability → Component → Version → Application → Release → Risk → Remediation
31. SBOM Review Checklist
Identification
- Product identified
- Release identified
- Build identified
- SBOM version identified
Components
- Direct dependencies included
- Transitive dependencies included where supported
- Runtime dependencies included
- Container components included
- Build dependencies included where appropriate
- CI/CD components considered
Security
- Vulnerability correlation performed
- Critical vulnerabilities assessed
- Unsupported components identified
- Security advisories reviewed where appropriate
Governance
- SBOM generated by approved process
- SBOM validated
- SBOM stored securely
- Ownership assigned
- Update triggers defined
32. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Software Dependency Inventory | Broader inventory of software dependencies |
| Third-Party Software Assessment | Assesses software before use |
| ICT Dependency Register | Records broader ICT dependencies |
| Vulnerability Register | Tracks vulnerabilities |
| Asset Register | Identifies systems/assets |
| Application Register | Identifies applications |
| Secure Development Policy | Defines development security requirements |
| Change Management | Controls software changes |
| Patch Management | Manages security updates |
| Supplier Register | Identifies external suppliers |
| Supplier Risk Assessment | Assesses supplier-related risks |
| Risk Register | Tracks significant risks |
| Incident Management | Uses SBOM during security incidents |
33. Required Evidence
Depending on the organization’s environment, evidence may include:
- SBOM files
- SBOM generation logs
- SBOM validation records
- CI/CD pipeline records
- Software Composition Analysis reports
- Dependency lock files
- Container scan reports
- Vulnerability reports
- Release records
- Software versions
- Remediation records
- Risk acceptance records
- Updated SBOM after remediation
34. Common Mistakes
Mistake 1 — Creating an SBOM Once
An SBOM becomes outdated when software dependencies change.
Mistake 2 — Recording Only Direct Dependencies
Transitive dependencies can introduce vulnerabilities.
Mistake 3 — Not Recording Exact Versions
A component name without a version is often insufficient for vulnerability correlation.
Mistake 4 — Treating the SBOM as a Vulnerability Report
An SBOM tells you what is present.
It does not by itself determine what is vulnerable or what risk treatment is required.
Mistake 5 — Keeping SBOMs Separate From Releases
An SBOM should be traceable to the specific software build/release it represents.
35. Quick Audit Checklist
An auditor may ask:
- Do you maintain SBOMs for relevant software?
- How are SBOMs generated?
- Which SBOM format do you use?
- Can you identify components in a specific production release?
- Do you track versions?
- Do you identify direct and transitive dependencies?
- How do you identify vulnerabilities affecting your components?
- How quickly can you determine whether a newly disclosed vulnerability affects your software?
- Do you track unsupported components?
- How are SBOMs updated?
- Are SBOMs linked to builds/releases?
- How are SBOMs protected?
- Can you demonstrate an SBOM for a current production release?
36. Final Audit Trail
A mature SBOM process should demonstrate:
Source Code
↓
Dependencies Identified
↓
Build Created
↓
SBOM Generated
↓
SBOM Validated
↓
Release Identified
↓
Vulnerabilities Correlated
↓
Risk Assessed
↓
Remediation Performed
↓
Testing Completed
↓
Release Verified
↓
Updated SBOM Generated
Final Principle
An SBOM is a software supply-chain visibility mechanism, not merely another inventory document.
Its practical value is the ability to answer quickly:
“Which components are inside this software release, where did they come from, which versions are present, and which applications or releases could be affected if a security issue is discovered?”
For a SaaS organization, the strongest approach is to generate the SBOM automatically as part of the CI/CD release process, link it to the exact build/release, correlate it with vulnerability information, and retain the resulting evidence as part of the software supply-chain security lifecycle.