boring.tools does not scan your source code. It works from a Software Bill of Materials that your build tooling produces, so it sees exactly what you ship.
Supported formats
| Format | Versions | Encoding |
|---|---|---|
| CycloneDX | 1.x (bomFormat: "CycloneDX") |
JSON |
| SPDX | 2.x (spdxVersion: "SPDX-2.x") |
JSON |
Files can be up to 25 MB. XML, tag-value and other encodings are not supported.
Components are identified by their package URL (purl). A component without a purl is still imported, but it can’t be matched against vulnerability data. Most generators add purls by default.
Generating an SBOM
For most repositories one tool covers everything:
- cdxgen, any language:
npx @cyclonedx/cdxgen -r --spec-version 1.6 -o sbom.json . - Syft, source trees and container images:
syft dir:. -o cyclonedx-json@1.6=sbom.json
Ask for CycloneDX 1.6 or newer: Germany’s BSI TR-03183-2, the usual reference for CRA SBOMs, requires at least CycloneDX 1.6 or SPDX 3.0.1. Ecosystem-specific generators work too:
| Ecosystem | Generator |
|---|---|
| npm | npx @cyclonedx/cyclonedx-npm --spec-version 1.6 --output-file sbom.json |
| Python | cyclonedx-py environment -o sbom.json (cyclonedx-python) |
| Go | cyclonedx-gomod mod -json -output sbom.json (cyclonedx-gomod) |
| Containers, any | syft <image> -o cyclonedx-json=sbom.json (Syft), trivy image --format cyclonedx --output sbom.json <image> |
Prefer a generator that records the dependency graph (CycloneDX dependencies, SPDX DEPENDS_ON relationships). With it, boring.tools can tell direct from transitive dependencies and show which of your direct dependencies pulls a vulnerable package in. Without it, the dependency type is shown as unknown.
If your generator marks development dependencies (for example cyclonedx-npm without --omit dev), we keep that information; AI triage uses it to rule out findings in tooling that never ships.
Ways to upload
- In the app: project → Integration → Upload manually. You can override the version and artifact name before uploading.
- From CI: with an upload key and one
curlcall — see CI integration. - Via the API: see the Upload API.
What happens after an upload
- The upload is accepted immediately (HTTP
202). Your pipeline doesn’t wait for the analysis. - Import: we validate the document, extract the components, the dependency graph and, for CycloneDX, the declared scope.
- Analysis: every component is matched against the vulnerability database.
Both steps usually take seconds. The status is shown next to each upload in the project overview. If a file can’t be read — not JSON, not CycloneDX or SPDX, or invalid against the format — the upload is marked failed with the reason; fix the file and upload again.
Privacy
We store the uploaded file and the list of components it contains. SBOMs contain package names and versions, not your source code. Component data is only used to find vulnerabilities for you; it is shared with an AI provider only if you enable AI triage for a project.