CI is the wrong place to first hear about your npm dependencies

Your CI catches the npm vulnerability. Your developer is already three branches away and one standup behind. The package is installed, the lockfile regenerated, the import wired into a service, and the human who made that decision did it on a Tuesday afternoon with a tab open to Stack Overflow. Now the scanner is yelling.

From the terminal, that is not security. That is grief counseling.

That is the frame Sonu Kapoor lays out in a DevOps.com essay this week, and the engineering bones of it are correct.

A scanner is not a gate. It is a status check.

Kapoor's argument is about feedback loops. A developer installs, codes, commits, pushes. Only then does CI run. By the time the finding surfaces, the decision to add the package, and the context for why, has evaporated. So has the lockfile churn that caused it. What started as "is this package safe?" becomes "fix this in a different sprint." The scanner did its job. The fix is now a project.

He backs it with a small case study from the NestJS repo: a scan of package-lock.json returned 1,626 resolved packages and 25 vulnerabilities. Of those, 12 were directly fixable. Thirteen were transitive, buried in upstream graphs, waiting on someone else's release. In a pipeline-first workflow, every dependency hop is a separate commit and a separate run. (Multiply by the number of services your team owns. Then by your runner-minutes budget. Send me the bill.)

The arithmetic gets ugly quickly. A single lockfile with more than fifteen hundred resolved packages is not exotic for a working Node app, it is the default. The chance that the first time anyone looks at that graph is during a pipeline run, after the merge intent is already in the reviewer's queue, is the structural bug.

Where the essay is right, and where it gets too tidy

Concede the obvious. CI is not the problem. CI is fine. It runs uniformly, it cannot be skipped, and it is the right place to fail a build when an OSV record drops mid-week against a dependency that was clean at merge time. Validation is its native job.

The bug is treating CI as the first place anyone hears about an issue. Discovery there is a category error. You are using the post-flight checklist to taxi the plane.

So far, so unobjectionable. Where the essay gets convenient is the pitch. The cure on offer is a local CLI that Kapoor's team ships, run against the lockfile before commit, splitting direct from transitive findings, OSV-backed. Useful, probably worth a try. Also: a tool. Tools come and go. A team can adopt this CLI today, lose interest in eight months, and the dependency problem will still be sitting in package-lock.json waiting for the next refactor.

A laptop CLI is the developer-ergonomics half of the answer. It is the half a vendor blog post is built to sell.

What actually moves the gate left

If CI is too late, the answer is not "tell the developer faster on their machine" and walk away. Laptops drift. Branches drift. The version of the scanner that ran on the senior engineer's machine is not the version that ran on the contractor's. A discovery step you can opt out of by closing a terminal is not a control. It is a courtesy.

What works, roughly in order of how cheap it is to set up:

1. A pre-commit hook that fails on a lockfile diff containing a known-bad package. Cheap, local, opt-in, fine as a first line.


2. A required PR check that runs the same scan against the lockfile before a reviewer is paged. Mandatory, visible inside the diff, blocking the merge instead of decorating the build.


3. A policy at the branch-protection layer that constrains what is allowed in the lockfile at all: license, registry source, signature, provenance. Unsigned additions to package-lock.json should not be a finding. They should be a closed PR.

Notice CI is in all three. It just stops being where you first find out.

The piece's case study quietly makes this point against itself. When the only fix for a transitive finding is a chain of iterative upgrades, the question is not "can a developer iterate faster on their laptop?" Yes, obviously. The question is "why was a dependency with thirteen unresolved transitive issues allowed into the merge queue in the first place?"

Verdict

Kapoor is right about the asymmetry. CI is great for validation and structurally bad for discovery on a Node tree where the majority of findings can be someone else's release schedule. If your security story today is "the pipeline will tell us," you are not gated. You are notified.

Fix the notification step. Then fix the part where you were ever relying on it.