What Chainsaw Sees: Data Handling & Trust

Overview

Before you route your organization’s installs through Chainsaw, you’ll want to know exactly what it reads, what it never reads, and what — if anything — leaves your network. This page is the plain-English answer.

The short version: Chainsaw is an install-path firewall, and you choose where it runs — as managed SaaS, inside your own VPC, or fully air-gapped. Packages flow through the instance you picked. It reads package metadata and artifacts on the wire to decide whether an install passes policy. It does not read your application source code, and it does not write to your repositories.

What the proxy reads

Chainsaw evaluates what flows over the wire to public registries when a developer or CI job installs a package. Per install decision it captures:

• Package metadata — name, version, ecosystem, source registry, and the upstream URL.
• The artifact itself — tarball contents and install scripts, so it can catch install-script behavior, hidden Unicode, and the other supply-chain signals that live at install time.
• Manifests and lockfiles — so a malicious transitive dependency is caught, not just the package you named.
• Who installed it, when, and the decision — the requesting identity (user or service account), a timestamp, which policy fired, and the outcome (allow / refuse / quarantine).

That metadata is what produces your dashboards, audit log, and CycloneDX SBOMs.

What Chainsaw never reads

The boundaries below are load-bearing — they’re what lets the proxy decide in single-digit milliseconds and compose cleanly with the rest of your stack.

• Your application source code. The install-path decision is made from package metadata, manifests, lockfiles and package artifacts. It never requires your application code, and the proxy does not crawl your repository. Two CLI commands are the deliberate exception, and only over files you point them at, locally: chainsaw scan-repo reads build and package-manager config to find registry-bypass paths, and chainsaw scan-actions reads GitHub Actions workflow YAML.
• Your repositories — it never writes to them either. Chainsaw is a decision layer in front of the install path. It does not open PRs, edit lockfiles, push commits, or modify any file you own. Its outputs are policy decisions, audit events, and SBOMs — not source-tree mutations.
• Developer secrets at rest. The proxy detects install-script exfiltration attempts against ephemeral install traffic; it does not store the secrets it observes, and it does not crawl your repos or build artifacts looking for secrets that already exist.

In compliance terms, the PII surface is limited to signup and billing — name, work email, organization slug. No PII is extracted from package contents.

What leaves your network

This is the question procurement actually asks, so here it is directly.

Package installs go upstream because you asked them to. The proxy is a pull-through cache: it forwards the install requests your developers and CI initiate to the upstream registries (npm, PyPI, Docker Hub, Maven Central, and the rest). That’s the proxy doing its job, not a data export.

Your configured integrations receive only what you set up. SIEM or webhook endpoints you configure receive the events you ask them to. A blocked-install payload delivered to your own SIEM destination carries the full package name, version, and reason — by design, to your destination.

Telemetry to Chainsaw is opt-out on the cloud build, off by default when self-hosted, and tiered by sensitivity:

• Self-hosted builds do not phone home. A self-hosted server has no default telemetry endpoint and does not send usage analytics unless an operator explicitly opts in with CHAINSAW_TELEMETRY_ENABLED=1.
• The free local CLI guard is consent-gated. Nothing is sent until you opt in. The first interactive run asks once; in CI or any non-interactive (non-TTY) context it stays off and collects nothing until you run chainsaw telemetry on. Anonymous usage counts and the identifying blocked-package payload are both governed by that consent.
• Refused-package names need a second, explicit opt-in. On the proxy/server surfaces, the name, version, and malware id of a refused package never leave the box under the generic telemetry toggle alone. Sharing them upstream to Chainsaw requires CHAINSAW_REFUSAL_SHARING=1, which is off by default and fail-closed — without it, only anonymous dimensions survive and the package identity is dropped. This consent governs only the phone-home to Chainsaw; it does not affect the blocked-install payload you deliver to your own SIEM.

Telemetry data that is sent is scrubbed of secrets and tokens before it leaves the client, and the ingest re-runs the same scrubber server-side.

For the exact event catalog, fields, and every opt-out switch, see the Telemetry reference.

The engine is open source

Security buyers don’t trust a black box on the install path — so the part that decides whether a package is safe is open source. The CLI and the decision engine — proxy, policy, and the intelligence, risk, typosquat, malware, dependency-graph, SBOM, and provenance libraries — live in a public repository at github.com/chain305/chainsaw-core. Anyone can read it, build it, and run the CLI without an account.

You can read exactly how a block decision is made before you route your org’s traffic through it. The paid product is the multi-tenant server, dashboard, premium intelligence, SSO/SCIM, policy signing, and SIEM delivery — the control plane for running the open core across an organization, not the part that makes the firewall work.

In one table

Next Steps

• Block Malicious and Typosquatted Packages at Install Time — try the free, on-machine CLI guard.
• Set Up Chainsaw as Your Organization’s Package Proxy — deploy the self-hosted proxy.
• Deploy Chainsaw in an Air-Gapped Environment — run it with no outbound internet at all.