SBOM
SBOMs that live in a PDF folder are compliance theater. Chainsaw's SBOM is the same data the install-path inventory already collects — snapshot at quarantine, queryable by CVE, exportable as CycloneDX 1.6 with real dependency edges.
Why operational
When the policy engine quarantines a package, the SBOM pins itself: the exact dependency graph at the moment of decision. You can re-export the same artifact six months later for an auditor and the bytes match. No 'oh, the inventory has moved on' problem.
An SBOM that lives in a PDF is not operational. Chainsaw's SBOMs are first-class objects: search by CVE, by license, by package name, by transitive depth. The same query language the inventory uses, against snapshots tied to incidents.
Direct vs transitive dependents are encoded in the CycloneDX 1.6 dependency edges, not implied. Your downstream tooling — compliance scanner, vendor-risk tracker, agency audit — gets a graph it can walk, not a flat list it has to re-derive.
Workflow demo
Four steps. No on-demand graph crawl, no 'rebuild the dependency tree from lockfiles', no 'wait until the next nightly job'. The SBOM is current as of the last install through the proxy — usually seconds ago.
CVE-2025-XXXXX hits the OSS feed at 09:14 UTC. CVSS 9.1, exploit in the wild. Your AppSec team has thirty minutes before the first all-hands ping.
Top-level nav → SBOM. Pick the org-wide snapshot or one per repo. Pre-rendered, queryable, current as of the last install through the proxy.
Paste the CVE ID. The SBOM resolves the affected package + version ranges and lists every direct importer, with transitive dependents one click deep. Closure size and max depth on every row.
Click export. A CycloneDX 1.6 file with the affected component, its transitive blast radius, and a deterministic incident-tied hash. Drop it in the SOC 2 evidence folder, attach it to the customer notice, ship.
Compliance footprint
Both formats supported on every export. CycloneDX is the operational default (richer dependency graph); SPDX is the regulator-friendly fallback when the auditor mandates it.
Snapshots can be scoped to a single repo for vendor-side review, or rolled up to the org for a regulator. Same data, different filter.
chainsaw_export_sbom(format, repo, snapshot_id) and chainsaw_query_affected_packages(cve) ship with the MCP server. Claude Code, Cursor, and Windsurf can pull SBOMs and answer affected-package questions on your audit log.
Every SBOM export is itself an audit-log row: who exported, what scope, which snapshot, what hash. SOC 2 reviewers stop asking how you generated the artifact — the artifact is its own evidence.
Stop hand-rolling SBOMs the day before an audit
Free tier captures every install, builds the depgraph, and exposes the SBOM read view. Export and snapshot retention scale with the paid tiers — but the read and search of your own data are on every plan.