Enforce on the request path
License, version, and provenance rules run on every install. Consistent whether the install happens in CI, on a laptop, or inside a Dockerfile.
For DevSecOps & Compliance
Every install leaves evidence. Compliance stops being a spreadsheet project.
When a public npm or PyPI compromise hits the feed, a scanner tells you after the package is already installed. Chainsaw decides on the install path: the same license, version, and provenance rules run in CI, on a laptop, and in Dockerfiles, and a bad version never installs. Every verdict — the rule, the reason, the repo, the CI job, the user — lands in a structured log. So when the security questionnaire asks how you stop a poisoned dependency, the answer is a query, not a quarter of collection work.
The pain
- A public npm or PyPI compromise hits the feed — Shai-Hulud, event-stream, xz-utils — and you can't say whether it reached a build before you patched.
- Policy is written down but not enforced consistently across teams and pipelines, so a malicious version can still install.
- A security questionnaire lands asking how you stop a poisoned dependency at install — and the honest answer is a scanner that reports after the fact.
- When the evidence request comes, proof of what you blocked is a manual spreadsheet assembled at the end of the quarter.
What changes
Close the gaps a free CLI can't
Carry the same policy across CI, developer endpoints via MDM, and the network egress path — then export an audit trail of what was decided, with audit logs streaming to Splunk HEC, Microsoft Sentinel, or IBM QRadar on Enterprise. That closure and audit trail are the paid wedge: a local CLI cannot produce them.
Monitor first, block later
Roll out policy without breaking builds. Capture what would have been blocked, then flip to enforce rule by rule when you're confident.
Evidence mapping
No framework requires install-time blocking. But whichever one your auditor works from, the same export answers it.
You don't turn Chainsaw on for a framework — you turn it on to stop the next compromised package. The audit trail it leaves happens to be the evidence a questionnaire or auditor asks for. Chainsaw doesn't certify you compliant; it produces the proof. Here's how the install-path firewall lines up against the frameworks we see most often.
SOC 2 Type II
CC 7.1 change management, CC 8.1 system changes, CC 6.6 logical access
Install-path audit log demonstrates approval boundaries. Exception expiry and RBAC-scoped API keys satisfy the access-change controls.
NIST 800-161r1 C-SCRM
SR-3, SR-4, SR-11 supply-chain controls
Supply-chain attack signals, SBOM export, and maintainer-change detection map directly to the supply-chain risk controls introduced in r1.
ISO 27001 / ISO 27002
A.8.9 config mgmt, A.8.22 segregation, A.5.19 supplier
Centralised policy and tenant-scoped rules satisfy the segregation controls. Supplier controls land on the provenance and attack-signal rules.
SLSA v1.0
Provenance L2–L3, Source L2+, Build L3
Chainsaw ingests Sigstore attestations, npm provenance, and Go sumdb to enforce the provenance levels your consumers require.
Enforce, then prove it
From draft policy to blocking bad installs in three steps
-
Model your policy once
Allow-list licenses, block versions below a floor, require signed provenance. Single declarative surface; same YAML runs everywhere.
-
Watch monitor-mode traffic
Every install produces a verdict in the audit log even in monitor mode. You see what enforcement would do without breaking anyone's build.
-
Export evidence on demand
One-click CycloneDX SBOMs per repo. Audit trails stream to Splunk HEC, Microsoft Sentinel, or IBM QRadar on Enterprise. No spreadsheet assembly at quarter-end.
Before the next questionnaire
Turn on Chainsaw in monitor mode
See what a real compromise would have hit today — without breaking a single build. Flip to enforce rule by rule when you're ready, and the audit log is there when the questionnaire arrives.