How it works
Every npm install, pip install, docker pull runs
through a policy engine before it touches the registry. Allow it (cached), or block it
with a clear error. Watch one of each below.
npm installWhat changes for developers: almost nothing. No SDK, no laptop agent, no CI plugin. The only difference is that bad packages fail with a message telling them why.
Why this exists
event-stream, ua-parser-js, xz-utils, and the March
2025 tj-actions/changed-files GitHub Action compromise all shipped to
developer machines before any vulnerability scanner caught them. A post-hoc SCA finds the
bad package after it's on disk — sometimes after it's already run a postinstall
script. Chainsaw blocks these at install time, on rules you can read and change.
From npm install to package-on-disk
Setup · one-time
Change one registry URL in the config your package manager already reads. Nothing else changes — no SDK, no laptop agent, no CI plugin, no new build step.
// before
registry=https://registry.npmjs.org/
// after
registry=https://your-org.chain305.com/npm/
Same pattern for pip.conf, settings.xml,
Dockerfile FROM lines, NuGet, Cargo, Go, Composer, APT — one
URL per ecosystem. See the per-ecosystem guides →
Every install · runtime
On every request, Chainsaw evaluates the package in parallel against your rules — low single-digit milliseconds — before forwarding to the upstream registry or returning an error.
added 1 package. Chainsaw is invisible.The developer sees the exact rule that fired, in their own terminal:
$ npm install log4j-core@2.14.1
npm ERR! Chainsaw: blocked
npm ERR! rule: block-critical-vulns
npm ERR! reason: CVE-2021-44228 (CVSS 10.0, EPSS 0.97)
npm ERR! contact: security@your-org.comEPSS is the likelihood of real-world exploitation — it filters out the long tail of "technically a CVE, nobody exploits it" noise.
Rollout · ongoing
Every rule ships with a monitor mode: the decision is recorded, but the install still succeeds. You see exactly what would have been blocked across every repo and pipeline, add exceptions where needed, then flip the rule to enforce — per rule, per repo, per team.
rule: block-critical-vulns
match:
cvss: ">= 9.0"
epss: ">= 0.5"
mode: monitor # week 1–2: just record what would fire
mode: enforce # week 3+: block the installEvery allow/block is logged with timestamp, user, rule, and package metadata. Export a CycloneDX SBOM (standard file that lists everything you shipped) per repo, stream the audit log to your SIEM, or roll a policy back from the dashboard — no developer workstation touched.
When things go wrong
In monitor mode, Chainsaw fails open with an audit record — installs never break. In enforce mode, the default is fail-closed, but you can flip to fail-open with cache-only fallback per policy. The cache continues to serve previously-allowed installs during a full outage.
npm, PyPI, or Docker Hub having a bad day doesn't block your builds. Cached versions serve from Chainsaw's content-addressed blob store. Only packages you haven't installed before fail, and they fail with the upstream's own error — not ours.
A blocked legitimate install is one click away from an exception. The exception carries a reviewer, a reason, and an expiry date. The reviewer dashboard queues the request; the developer sees a structured error naming the rule and the exception contact. No escalation to platform-eng needed.
Still skeptical? Start in monitor mode. Every rule supports it out of the box — we log the decision but still let installs through, so you can measure exactly what would have been blocked across every repo and pipeline before you enforce a single thing.
Read the getting-started guides →Ready to roll out?
Start free, switch to blocking when you're ready, or chat with us about custom deployments.