Known-malicious blocks

Reference 5 minutes Operators Security & Policy

Why Chainsaw blocks known-malicious package installs at the proxy before policy evaluation, what data backs the gate, and the supported false-positive path.

Audience: operators wiring up policies and triaging blocked installs.

What this page covers

Chainsaw blocks known-malicious package installs at the proxy. The block fires before any policy is evaluated. This page explains why that gate exists outside the policy engine, what data backs it, and what to do when a block turns out to be a false positive.

Threat model

Every install request that flows through the Chainsaw proxy is checked against an in-memory index of known-malicious package names and versions. If the request matches, the proxy returns HTTP 403 with error code CHW-MALWARE-BLOCKED and writes an audit event with rule_id malware:<malware-id> and outcome blocked. The policy stack is not consulted.

This is intentional. A policy precedence stack is a powerful tool, and operators routinely write Allow exceptions that whitelist specific packages, package classes, or whole namespaces. Once an exception is in place, every match that lands in its scope skips the rest of the stack. We treat published-malicious as a hard floor that exception authors do not get to override by accident.

See tutorial 19 (Manage policy precedence and exceptions, Rule 3 under “Rules for Ordering”) and tutorial 23 (Detect known malware in your supply chain, callout under Step 3) for the original design references. Both say the same thing: no exception should override a confirmed malware detection.

Data source

Matches come from the OpenSSF Malicious Packages feed (https://github.com/ossf/malicious-packages). The feed is mirrored into Chainsaw’s supply-chain index on every intelligence-bundle refresh.

The audit drawer renders the feed origin underneath the “Blocked by” field whenever the block came from the malware gate. Use that as the ground-truth signal during incident response: if the audit row reads Source: OpenSSF Malicious Packages feed, the block did not come from the policy stack.

Why this is not policy-controlled

The seeded Demo: Block known malware policy (precedence 151, condition isKnownMalicious=true) exists so that operators can see malware events surface in the policy UI and write narrower follow-on rules around them. Toggling that policy’s mode from Block to Monitor does not change the outcome of a malware request. The proxy short-circuits before the policy engine runs.

If you need the policy stack to surface malware in a different way (for example, an additional Slack alert, or a Monitor row in addition to the hard block), wire that on top of the hard block. Don’t try to disable the hard block.

False positives

If a known-malicious match is wrong, the fix is upstream. Two steps:

  1. File a correction against the OpenSSF Malicious Packages feed so the entry is retracted at the source.
  2. Open a support ticket against Chainsaw so we can refresh the local cache out-of-band ahead of the next bundle refresh.

Don’t write a policy exception. An Allow rule scoped to the affected package will not let the install through; the request still trips the malware gate before the policy stack is reached.

If the package is urgent and the upstream correction is going to take time, the supported escape hatch is a separate proxy upstream (e.g. a direct registry connection scoped to the one CI job that needs the package) until the feed entry is fixed.