Inventory

When the next CVE drops, "are we affected?" is a search box.

Every install captured at the install path, not at PR time. Free, default-on, and the same data the policy engine already collects.

Workflow

From advisory to answer, with transitive dependents

01 · Search

Paste the CVE ID

affected package and version ranges, as rows
02 · Walk dependents

Cycle-safe closure

repo, CI job and last install on every row
03 · Ship the answer

Export and quarantine

CycloneDX, per repo or org-wide
Next install refused

the error names the CVE; the audit trail covers the whole loop

The surface

What makes it operational

Captured at the install path

Every npm install, pip install and mvn dependency:resolve hits the same point, as it happens. Not at PR time, not at the next dependency-graph crawl.
Default-on

No 'enable inventory' checkbox. From the first install the row exists: package, version, ecosystem, repo, CI job, who pulled it, when.
Transitive dependents, not just direct

An N-level depgraph walk (default 5, capped at 10), with closure size and max depth on every package row.
Owned-by facet

Every row carries a CODEOWNERS-derived owner, so an incident groups by owning team.
Snapshots tied to incidents

Quarantining a package pins the exact set of installs at the moment of decision. It exports the same way the SBOM does.
MCP query tool for agents

chainsaw_inventory_summary(repo?) and chainsaw_query_affected_packages(cve) for Claude Code, Cursor and Windsurf. Same data, same ACLs.

Inventory shows what flowed through the proxy. Unproxied installs stay invisible until Hardening Level 2+.

Stop firing on every advisory you read on Twitter

Point one package manager at Chainsaw, run for a week, and see what you actually shipped.