Software Bill of Materials (SBOM) Template

Name: AI Lawyer
Price: 9.99 USD
Availability: InStock
Rating: 4.8 (1250 reviews)

Typical length: 4-6 pages
AI Assisted
Export: PDF & DOCX
Multi-jurisdiction ready

Get your custom agreement in minutes Create Agreement

4.8 Rating Downloaded 5595 times

Google For Startups NVIDIA Inception Program

This Software Bill of Materials (SBOM) (the “SBOM”) is created for [Company Name] and applies to the product identified below.

1. Product Identification

1.1 Product Name. [Product Name].

1.2 Product Version/Release. [Version/Release].

1.3 Build Identifier (Optional). [Build ID / Commit SHA / Artifact ID].

1.4 Release Date. [Date].

1.5 SBOM Version. [SBOM version number].

1.6 SBOM Created On. [Creation date].

1.7 SBOM Created By / Tool. [Tool name/version or manual].

1.8 Point of Contact. [Name, email, team].

1.9 Distribution Model. ☐ SaaS ☐ On-prem ☐ Mobile app ☐ Desktop app ☐ Embedded ☐ Other: [Model].

2. Component Inventory

2.1 Component List. For each component, document:

Component name
Component type (library, framework, container image, OS package, etc.)
Supplier/Publisher
Source location (repo/URL)
Version
License(s)
Package identifier (PURL) (optional)
CPE (optional)
Hash (optional)
Dependency relationship (direct/transitive)
Notes/usage location (where used)

Component name

Component type (library, framework, container image, OS package, etc.)

Supplier/Publisher

Source location (repo/URL)

Version

License(s)

Package identifier (PURL) (optional)

CPE (optional)

Hash (optional)

Dependency relationship (direct/transitive)

Notes/usage location (where used)

2.2 Component Record (Repeat as Needed).

Component Name: [Name]

Component Type: [Type]

Supplier/Publisher: [Supplier]

Source/Repository: [URL or repo]

Version: [Version]

Direct or Transitive: ☐ Direct ☐ Transitive

License(s): [License name(s)]

Package URL (PURL) (Optional): [PURL]

CPE (Optional): [CPE]

Hash (Optional): [SHA-256 or other]

Where Used (Optional): [Service/module/path]

Notes (Optional): [Notes]

3. Dependency and Relationship Notes (Optional)

3.1 Dependency Graph Reference. Dependency graph stored at: [Link/location].

3.2 Notable Transitives. [High-risk or critical transitive dependencies].

3.3 Bundled Components. List any components bundled into binaries or containers: [List].

4. License and Notice Summary

4.1 License Summary. Summary of licenses present in this release: [List licenses].

4.2 Notice/Attribution Location. OSS notices and attributions are provided in: ☐ NOTICE file ☐ About screen ☐ Documentation ☐ Other: [Location].

4.3 Source Code Obligations (If Applicable). If any licenses require source code disclosure/offer, source code is provided at: [Link/location], with instructions: [Instructions].

4.4 Third-Party Requests. Requests related to OSS notices or source can be sent to: [Contact email].

5. Security and Integrity (Optional)

5.1 Vulnerability Scan Date. [Date].

5.2 Scan Tool and Version. [Tool].

5.3 Known Issues/CVEs (If Any). [List or “None known at time of creation”].

5.4 Integrity. This SBOM corresponds to build artifact(s): [Artifact references].

5.5 Signature (Optional). SBOM signed using: [Method], signature reference: [Link/ID].

6. Update and Maintenance

6.1 Update Trigger. This SBOM must be updated when:

dependencies change,
build process changes materially, or
a new production release is created.

6.2 Maintenance Owner. Owner responsible for SBOM updates: [Team/Role].

6.3 Retention. SBOMs will be retained for: [__] years or per policy: [Policy reference].

6.4 Exceptions. Exceptions to SBOM completeness must be documented and approved by: [Role].

dependencies change,

build process changes materially, or

a new production release is created.

6.2 Maintenance Owner. Owner responsible for SBOM updates: [Team/Role].

6.3 Retention. SBOMs will be retained for: [__] years or per policy: [Policy reference].

6.4 Exceptions. Exceptions to SBOM completeness must be documented and approved by: [Role].

Signatures

By signing below, the undersigned acknowledge that this SBOM is a record of the components included in the identified product release as of the SBOM creation date.

Prepared By: [Name]

Title/Role: [Title]

Date: [Date]

Signature: ___________________________

Approved By (Optional): [Name]

Title/Role: [Title]

Date: [Date]

Signature: ___________________________

Download Free Template

Get your complete
agreement in minutes

Select a template

Each template already follows legal structure and best practices.

Provide details

The agreement is automatically filled and adapted to your inputs.

Review & download

Check the generated document, make edits if needed, and download a ready-to-use agreement.

Details

Learn more about

Software Bill of Materials (SBOM) Template

Click below for detailed info on the template.
For quick answers, scroll below to see the FAQ.

Learn more

Frequently asked

Software Bill of Materials (SBOM) Template — quick answers

Reviewed July 2026 Free download, PDF & DOCX

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is a structured inventory of the components that make up a software product. It lists libraries, packages, modules, and other dependencies (including open source and third-party components), along with key details like version numbers, suppliers, licenses, and known identifiers. SBOMs help organizations understand what’s inside a product for security and compliance purposes.

When do you need an SBOM?

You may need an SBOM when shipping software to enterprise or government customers, responding to security questionnaires, managing supply chain risk, or meeting internal compliance requirements. It’s also useful for vulnerability response — when a new CVE is announced, an SBOM helps you quickly identify whether you are affected.

What should an SBOM include?

An SBOM typically includes product identification, the list of components, component versions, supplier/source, license information, dependency relationships, and integrity data such as hashes. Many SBOMs also include a creation date, tool used, and a point of contact for questions.

What formats are commonly used for SBOMs?

Common formats include SPDX and CycloneDX. Organizations often produce an SBOM using automated tools (dependency scanners) and keep it updated as part of the build/release process, rather than maintaining it manually.

How often should an SBOM be updated?

Update the SBOM whenever dependencies change, and at minimum for each production release. Keeping SBOMs aligned to build artifacts (and versioned in a repository) makes audits and incident response much easier.

What is AI Lawyer?

AI Lawyer is an AI-powered assistant that helps you create and customize legal and business document templates online. It guides you through key sections, suggests wording, and explains complex concepts in simple language. AI Lawyer does not replace a licensed attorney or provide legal advice, but helps you prepare better documents faster and more confidently.

Similar templates