A 40-line CEL integration snapshots .npmrc files every 6 hours to catch cooldown removals. This post walks through the three ways we broke filestream before landing on snapshot semantics.

Why developer workstations are the npm supply-chain  gap

What does an npm cooldown config file look like?

First approach: Monitoring .npmrc with the Custom Logs Filestream integration

Three filestream behaviours that don't fit config file monitoring

Native file identity beats fingerprint for small files

clean\_inactive and ignore\_older are coupled

Filestream emits on append, not on removal

Why nvm inflates npm version counts for cooldown adoption

Second approach: Monitoring .npmrc with CEL snapshot semantics

How the CEL integration evolved: emit-on-change, tombstones and heartbeat

How to filter .npmrc auth tokens before they leave the host

The npm cooldown ingest pipeline

CEL vs. filestream for config file monitoring

npm cooldown monitoring on Linux and Windows

Rollout status and extending beyond npm

What we learned about npm cooldown monitoring with Elastic Agent

Track npm cooldown (min-release-age) adoption and catch silent removals on developer workstations using a 40-line CEL integration in Elastic Agent.

Run a snapshot-based CEL integration in Elastic Agent that reads each `.npmrc` on a fixed interval and re-emits the host's current state as a heartbeat (we use 6 hours). A removed `min-release-age` line shows up as `cooldown.absent = true` in the next snapshot, and a deleted file drops out of subsequent snapshots. Log-tailing inputs like `filestream` can't produce this signal, because they emit on appended content and stay silent on retractions. Detection latency equals the heartbeat interval, which fits adoption tracking over days or weeks rather than real-time alerting.

How do I detect when an npm cooldown setting is removed with Elastic Agent?

An npm cooldown is a delay between a package version being published and npm being willing to install it, set with the `min-release-age` key (in days). Malicious releases are typically detected and pulled from the registry quickly, so a cooldown of days keeps fresh compromised versions out of `npm install` during the window when they do the most damage. It's a workstation-level guardrail against supply chain attacks, complementing the controls in CI/CD.

What is an npm cooldown and why does it matter for supply chain attacks?

npm 11.10 and later. Set it with `npm config set min-release-age 7` (the unit is days), which writes to the user-level `~/.npmrc`. Every npm installation on the machine reads that file, but versions older than 11.10 ignore the key.

What npm version supports min-release-age?

The setting is shared, but enforcement is per-version. `npm config set min-release-age 7` writes to the user-level `~/.npmrc`, which every npm installation on the machine reads, including the per-Node copies that nvm installs. Versions older than 11.10 ignore the key, so a machine with a mix of npm 10.x and 11.10+ installations is only protected when the active npm is 11.10 or later. Machines with nvm routinely report several npm versions (one machine in our test pulls reported 34), which is why we track the config file directly instead of inferring adoption from version counts.

Does an npm cooldown set in \~/.npmrc apply to every npm version installed through nvm?

The full file body sits in the `message` field before the event leaves the host, and `.npmrc` includes registry auth tokens alongside the cooldown setting. We add an agent-side script processor in the integration's Advanced options that keeps only `min-release-age` lines and drops everything else before transit. Tokens never reach the ingest pipeline. We verified by adding a test token to `.npmrc` and confirming zero hits for the token string in Elasticsearch after a full cycle.

How does the CEL integration keep `.npmrc` auth tokens off the wire?

Filebeat's default file identity strategy (fingerprint) requires files to be at least 1024 bytes before they're indexed. User-level config files like `.npmrc` are 10 to 50 bytes, so they sit in a deferred state with no error in the agent log. Switch the integration to native file identity (inode plus device) and the size floor goes away. The fingerprint length cannot be lowered below 64 bytes, so for files that small, native is the only path.

Why are my filestream events missing for small config files?

A Windows-specific variant is needed, but it shares the dataset and ingest pipeline with macOS and Linux. The Windows integration enumerates `C:/Users/*`, excludes the built-in profiles (`Public`, `Default`, `Default User`), and watches each user's `.npmrc` plus the globals under `C:/ProgramData`. The Grok pattern's `[^
]*` value capture already handles CRLF line endings, and the agent-side token filter is unchanged. We designed this variant but haven't deployed it in our own macOS-heavy fleet yet.

Author

Wieger van der Meulen

Articles

The security signal log tailing can't see: tracking npm cooldown removals with Elastic Agent