Book a demo Get started

Enterprise rollout

Monitor, audit, enforce — and ship in four weeks, not four quarters

Enforcement goes on gradually — per rule, per team, at your pace — so security gets policy on without developers losing a build. Most dependency-control rollouts stall because there's no way to do that. Chainsaw is built around the phased path: monitor, then low-risk enforce, then high-risk enforce.

The schedule

Four weeks, ≈ 40 platform-engineering hours total

Concrete estimates, not hand-waving. Slip a week if you need to; every rule can stay in monitor as long as you want before you flip it.

Week 1 ≈ 8 platform-eng hours

Deploy and point one pilot team

Stand up Chainsaw, route one team's installs through the proxy. No policy yet — everything passes with an audit record.

View the 4 steps
  • Stand up Chainsaw on your cloud or managed SaaS. Docker Compose for dev; Kubernetes or ECS for prod.
  • Provision the control-plane database and (optional) Redis for webhook delivery at scale.
  • Issue scoped client credentials to one pilot team's CI and laptops.
  • Confirm installs flow through the proxy. No policy active yet; everything passes with an audit record.
Week 2 ≈ 8 platform-eng hours

Turn on monitor mode, org-wide

Roll out the baseline policy in monitor mode for every team. Nothing breaks — it logs without blocking while you tune.

View the 4 steps
  • Roll out the baseline policy template — CVE floor, license allowlist, and every supply-chain attack signal your proxied ecosystems support — in monitor mode.
  • Point the remaining teams at the proxy. Nothing breaks because monitor mode logs without blocking.
  • Review the daily monitor report. Expect noise on the first day; every legitimate install that trips a rule is a candidate for exception or rule tuning.
  • Assign owners for exceptions: one reviewer per team, tracked in the dashboard with expiry dates.
Week 3 ≈ 12 platform-eng hours

Enforce the low-risk rules

Flip the near-zero-false-positive rules to block — typosquat, known-malware, dependency-confusion, hidden-Unicode.

View the 4 steps
  • Flip typosquat, known-malware, dependency-confusion, and hidden-Unicode rules to block. These have near-zero false positives in practice.
  • Flip the Docker malware feed and per-layer image enforcement to block for new image builds.
  • Coordinate one short announcement: developers know what now fails and who owns the exception path.
  • Shift monitor reports to weekly cadence once the signal is steady.
Week 4 ≈ 12 platform-eng hours

Enforce the high-risk rules

Flip CVE floor, license, and exfiltration rules to block; wire SIEM; document the process for your SOC 2 / ISO evidence pack.

View the 4 steps
  • Flip CVE floor, license allowlist, install-script exfiltration, publisher-changed, and publish-velocity rules to block or quarantine.
  • Wire SIEM stream (Splunk HEC, Microsoft Sentinel, or IBM QRadar) if you're on Enterprise.
  • Document your rollout and exception process. That doc feeds your SOC 2 / ISO evidence pack.
  • Move to steady state: weekly review of new exceptions, quarterly policy review, rule additions as new attack patterns land.

Availability

What "HA" means in practice

Chainsaw's proxy tier is stateless. Put two replicas behind a health check and failover is automatic. The control plane runs on a managed relational database; bring your own managed instance or self-host. Redis and NATS are optional for webhook delivery at scale.

  • Stateless proxy tier: scale horizontally behind any load balancer. No sticky sessions, no local state.
  • Managed-database control plane: bring your own RDS, Cloud SQL, or self-managed instance. Daily snapshots and standard failover apply.
  • Blob-store cache: local disk for dev, S3-compatible for prod. Purge and re-populate without downtime.
  • Fail-open or fail-closed: configurable per policy. Cache continues to serve previously-allowed installs during a full outage.
  • 50+ Prometheus counters: out of the box. OpenTelemetry tracing opt-in. Structured slog on stdout.
  • RTO / RPO: RTO depends on your control-plane failover; Chainsaw itself recovers in seconds once the DB is reachable.

Migration

Front your existing registry — don't rip it out

Most teams already run something. Chainsaw slots in front of whichever you have. No dual-publish, no cut-over day.

  • Artifactory / Nexus Keep them. Chainsaw sits in front of the public registries they proxy. Internal artifacts keep resolving out of Artifactory; public installs route through Chainsaw.
  • Cloudsmith / JFrog SaaS Point Chainsaw's upstream at Cloudsmith. Your team keeps using Cloudsmith URLs; Chainsaw enforces policy on every fetch.
  • Verdaccio / internal npm mirror Chainsaw replaces the public-upstream hop and keeps the mirror in place. No change to the developer's .npmrc.
  • Snyk / SCA scanners Run both. Chainsaw decides what can enter; SCA reports on what's already there.
Chainsaw vs Cloudsmith, JFrog, Nexus →

Hardening levels

Four levels of enforcement, one rollout path

Most teams start at Level 1 (monitor) and stop at Level 2. Regulated environments push to Level 3 or 4. Each level is additive — same proxy, same policy, more tooling around it. The /onboarding/hardening wizard generates the manifests, firewall snippets, and MDM payloads ready to apply.

  1. L1

    Monitor only

    Audit every install. Block nothing.

    The proxy logs every package decision with a structured row. Rules ship in monitor mode by default; the daily report tells you which installs would have failed. Zero developer disruption — every CI job, every laptop install passes through the audit log.

    Tooling: proxy + dashboard.

  2. L2

    + Admission webhook

    Cluster-side enforcement on Kubernetes.

    Add a Kubernetes ValidatingAdmissionWebhook so workloads pulling images outside policy are rejected at apply-time. Closes the 'CI sneak-around via direct kubectl apply' gap that monitor mode can't see. Helm chart and Kustomize overlay shipped with the runbook.

    Tooling: + K8s admission controller.

  3. L3

    + Network egress allowlist

    Block direct registry access at the network edge.

    Push a firewall / egress-policy snippet that allowlists Chainsaw's proxy and denies direct egress to npmjs.org, pypi.org, registry-1.docker.io, etc. Now the proxy is the only path — no developer can fall back to the public registry by editing one line of .npmrc.

    Tooling: + network egress policy.

  4. L4

    + MDM payloads on managed laptops

    Lock the developer machine.

    Distribute MDM (Jamf, Intune, Workspace ONE) payloads that pin the package-manager registry config, prevent override, and bake the proxy URL into the laptop image. Air-gapped variant available for regulated environments. The CLI ships with a baked server URL so engineers never see a public origin.

    Tooling: + MDM profile + checksum-verified CLI build (SHA-256).

Ready to brief your rollout?

Book a 30-minute working session

We walk through your environment — pilot team, policy baseline, SIEM wiring, on-prem constraints — and hand back a rollout plan you can share with your team.

Get started Talk to sales