What is an SBOM?
A Software Bill of Materials (SBOM) is a complete, machine-readable inventory of all components in a software artifact — direct dependencies, transitive dependencies, and their metadata. Think of it as an ingredient list for your software.
boring.tools generates SBOMs in the following industry-standard formats:
| Format | Versions | Output |
|---|---|---|
| CycloneDX | 1.5, 1.6 | JSON, XML |
| SPDX | 2.3 | JSON |
All outputs are compliant with NTIA minimum elements and EU CRA requirements.
Supported package ecosystems
boring.tools detects the package manager automatically from your project’s lockfile:
| Lockfile | Package manager |
|---|---|
bun.lock | Bun |
package-lock.json | npm |
pnpm-lock.yaml | pnpm |
go.sum | Go modules |
poetry.lock / requirements.txt | Python (PyPI) |
Cargo.lock | Rust |
pom.xml | Java (Maven) |
Ways to generate an SBOM
1. Automatic — via Git integration (recommended)
Connect a Git repository to a project and boring.tools generates an SBOM automatically on every new commit. Scans run approximately every 30 minutes by polling for new commits. You can also trigger a manual scan at any time.
See Git Integration for setup.
2. Manual upload
Upload an existing SBOM file directly in the UI:
- Open your project
- Click Upload SBOM
- Select a CycloneDX (JSON or XML) or SPDX (JSON) file
- Click Upload
SBOM detail view
Click any SBOM in the project’s SBOM list to open its detail page. The page has three main sections:
Header
Shows the SBOM name, version, format (e.g. CycloneDX 1.6), scan status, upload date, and the time of the last scan. A Re-scan button lets you re-run vulnerability matching at any time.
While a scan is in progress, a live progress bar shows how many packages have been checked (X / Y).
Vulnerability summary
Six stat tiles (Critical, High, Medium, Low, Unknown, Total) show the current vulnerability counts for this specific SBOM.
Vulnerabilities table
The full list of detected CVEs with the following columns:
| Column | Description |
|---|---|
| ID | CVE ID or OSV ID, links to the CVE detail page |
| Severity | Color-coded badge: Critical / High / Medium / Low |
| Component | The affected package name and version |
| CVSS | Numeric CVSS score (sortable) |
| Fixed In | Version where the vulnerability is patched, if known |
| Latest | Latest available version in the package registry (links to registry page) |
| Ecosystem | Package ecosystem (npm, Go, PyPI, etc.) |
| Analysis | Your triage status for this CVE (see below) |
| Published | Date the CVE was published (sortable) |
| Links | Direct links to OSV.dev and NVD/NIST |
You can search across all columns using the search box (fuzzy matching by CVE ID, component name, severity, etc.) and sort by Severity, CVSS, or Published date.
If you have suppressed vulnerabilities, a Show suppressed (N) button appears to toggle their visibility.
Components table
A searchable, sortable list of every package in the SBOM:
| Column | Description |
|---|---|
| Name | Package name |
| Version | Installed version |
| Type | Component type (library, framework, etc.) |
| Supplier | Vendor or maintainer if available |
| PURL | Package URL — the unique identifier for the package |
Search by name, version, supplier, or PURL.
Scan history
A paginated table of every vulnerability scan run for this SBOM:
| Column | Description |
|---|---|
| Trigger | How the scan was started (Upload, Manual, Scheduled) |
| User | Who triggered it (for manual scans) |
| Started | Timestamp when the scan started |
| Completed | Timestamp when it finished |
| Status | completed / failed (with error message on hover for failures) |
| Found | Total vulnerabilities found |
| New | Newly introduced CVEs compared to the previous scan |
| Resolved | CVEs no longer present compared to the previous scan |
Vulnerability analysis (triage)
For each vulnerability in an SBOM, you can record a triage decision. Click the + Add link in the Analysis column (or click an existing analysis badge) to open the analysis panel.
Analysis state
| State | Meaning |
|---|---|
| Not set | No decision recorded yet |
| In triage | Under investigation |
| Exploitable | Confirmed as exploitable in your environment |
| Not affected | The vulnerability does not affect your usage |
| False positive | Incorrectly identified |
| Fixed | A fix has been applied |
Justification (for “Not affected”)
When marking a vulnerability as Not affected, you must provide a justification:
- Code not reachable
- Code not present
- Inline mitigations
- Protected at perimeter
- Protected by compiler
- Requires configuration
- Requires dependency
- Requires environment
- Requires other component
- Not in affected subset
Responses
Select one or more response actions that have been taken:
- Can’t fix
- Rollback
- Update
- Will not fix
- Workaround available
Detail / Notes
A free-text field to explain the analysis decision. Supports any notes you want to keep alongside the triage record.
Suppressing a vulnerability
Toggle Suppress vulnerability to hide it from the default view. Suppressed vulnerabilities are excluded from counts and hidden in the table unless you explicitly click Show suppressed. Use this for vulnerabilities you’ve assessed as not actionable in your context.
Click Save Analysis to persist your triage. Click Reset to clear the analysis entirely.