# Enterprise rollout | Chainsaw > A concrete four-week rollout: deploy, monitor, enforce low-risk rules, enforce high-risk rules. HA, migration, and air-gapped options explained. Source: https://chain305.com/product/enterprise-rollout/ --- Enterprise rollout # Monitor, audit, enforce. Ship in four weeks. Enforcement goes on per rule, per team, at your pace, so no developer loses a build. The schedule ## Four weeks, ≈ 40 platform-engineering hours Every rule can stay in monitor as long as you want before you flip it. 1. Week 1 Deploy, point one pilot team ≈ 8 platform-eng hours 2. Week 2 Monitor mode, org-wide ≈ 8 platform-eng hours 3. Week 3 Enforce the low-risk rules ≈ 12 platform-eng hours 4. Week 4 Enforce the high-risk rules ≈ 12 platform-eng hours Every step, week by week Week 1 · Deploy, point one pilot team - 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 · Monitor mode, org-wide - 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. 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 · Enforce the low-risk rules - Flip known-malware, dependency-confusion, and hidden-Unicode rules to block. Each fires on coordinate-exact or byte-level evidence, so a refusal names the specific thing it found. - Flip typosquat to block, and budget for exceptions. It infers from name similarity, so it refuses some real packages: measured on 24,206 real packages held outside the popularity corpus, 1.02% are refused. Each clears in one command, per coordinate, offline: an exception, not an outage. - 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 · Enforce the high-risk rules - 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 Two proxy replicas behind a health check, and failover is automatic. Proxy tier stateless; scales horizontally, no sticky sessions Control plane your RDS, Cloud SQL or self-managed database Blob-store cache local disk for dev, S3-compatible for prod Degraded data source fails open with an audit row; CHAINSAW\_COVERAGE\_MODE=closed refuses anything not fully evaluated against your mandatory sources Upstream registry outage served from cache Observability 50+ Prometheus counters, opt-in OpenTelemetry RTO / RPO follows your control-plane failover; Chainsaw recovers in seconds once the DB is reachable Migration ## Front your existing registry No dual-publish, no cut-over day. Artifactory / Nexus Keep them. Public installs route through Chainsaw. Cloudsmith / JFrog SaaS Chainsaw's upstream points at Cloudsmith. Verdaccio / internal npm mirror Chainsaw replaces the public-upstream hop. .npmrc unchanged. Snyk / SCA scanners Run both. Chainsaw decides what enters; SCA reports on what's there. [Chainsaw vs Cloudsmith, JFrog, Nexus →](https://chain305.com/vs-artifact-managers/) Hardening levels ## Four levels, one rollout path Most teams start at Level 1 and stop at Level 2. Each level is additive. Level Adds Needs L1 · Monitor only Audit every install, block nothing proxy + dashboard L2 · Admission webhook Cluster-side enforcement on Kubernetes K8s admission controller L3 · Network egress allowlist Block direct registry access at the network edge network egress policy L4 · MDM payloads Lock the developer machine MDM profile, checksum-verified CLI On Team and Enterprise, the /onboarding/hardening wizard generates the manifests, firewall snippets and MDM payloads. Ready to brief your rollout? ## Book a 30-minute working session We walk through your environment and hand back a rollout plan you can share with your team. [Get started](https://chain305.com/chainsaw/signup) [Talk to sales](https://cal.com/chain305/30min) --- ## Long form The full text behind this page, including detail the page itself leaves out. 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 evidence-based rules to block — known-malware, dependency-confusion, hidden-Unicode — then typosquat, with an exception path. View the 5 steps - Flip known-malware, dependency-confusion, and hidden-Unicode rules to block. Each fires on coordinate-exact or byte-level evidence, so a refusal names the specific thing it found. - Flip typosquat to block, and budget for exceptions. It infers from name similarity, so it refuses some real packages: measured on 24,206 real packages held outside the popularity corpus, 1.02% are refused. Each clears in one command, per coordinate, offline — an exception, not an outage. - 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:** a deployment-level setting, fail-open by default. CHAINSAW\_COVERAGE\_MODE=closed makes Chainsaw refuse any package it could not fully evaluate against the data sources you declare mandatory; left unset, a degraded source fails open with an audit row. Upstream-registry outages are served from cache. - **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 →](https://chain305.com/vs-artifact-managers/) 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. On Team and Enterprise, 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](https://chain305.com/chainsaw/signup) [Talk to sales](https://cal.com/chain305/30min)