TL;DR
- A transitive CVE slipped past CodeSlick because we were only reading
package.json. Snyk caught it. We shipped full lockfile parsing, OSV batch queries, and a nightly monitor in one day. - CodeSlick now scans 1,083 packages per repo, up from ~50. If your scanner still stops at
package.json, it's lying to you. - The CVE:
uuid@10.0.0— Improper Input Validation (CWE-1285, CVSS 6.3), pulled in as a transitive dep viaresend@6.9.4.
The Wake-Up Call
Last week our own production repo got flagged:
uuid@10.0.0 — Improper Input Validation (CWE-1285) CVSS: 6.3 (Medium) Introduced by: resend@6.9.4 → uuid@10.0.0 Fix: upgrade resend to 6.10.0+
uuid was a transitive dependency. We never declared it. We never saw it.
Because CodeSlick was only parsing package.json.
That's on us. And it was unacceptable.
The Dirty Secret Most Scanners Hide
npm installdoesn't just install what you declare. It resolves the entire tree, pins every version, and dumps the truth into package-lock.json.
~50
packages visible via package.json
1,083
packages visible via package-lock.json
We were scanning the 40. Snyk was scanning the 1,083.
Supply-chain attacks don't hit your direct deps. They ride the transitive ones. The attacker doesn't need you to npm install malicious-package directly — they need one of your 40 declared dependencies to pull it in. If your scanner stops at package.json, you're defending 4% of your attack surface and calling it “security.”
Most lightweight tools still do exactly that. We were one of them.
What We Shipped in 24 Hours
Three changes. Zero excuses.
Full Lockfile Parser
LockfileParser now reads npm lockfile v2 and v3, extracting every resolved package — name, version, direct vs. transitive, depth. 1,083 packages from our own lockfile in under 100ms.
OSV Batch Query
Instead of 1,000+ individual API calls, we now hit OSV's /v1/querybatch endpoint — one POST covers the whole lockfile. One call, full coverage.
Nightly Monitor
A cron job scans every connected repo's package-lock.json, diffs against the last snapshot stored in dep_scan_snapshots, and instantly creates a GitHub Issue and email alert for any new CVE found.
The exact vuln Snyk found? CodeSlick catches it on the first scan now.
What We Deliberately Didn't Ship (Yet)
Auto-fix PRs
If a dep has a known fixedVersion, the obvious next step is opening a PR that bumps it. The problem: regenerating a lockfile requires running real npm installin a sandboxed worker — not possible via the GitHub API alone. We're not building that yet.
A dep dashboard
Scan history, trend charts, fixability scores — nice, but not required. GitHub Issues plus email already do the job. We'll build the dashboard the day someone pays us to.
We move fast. We don't gold-plate features nobody asked for.
The Brutal Truth
Lockfile-aware scanning isn't a “nice-to-have.” It's the absolute minimum for a dependency scanner to be worth anything.
package.json is a declaration of intent. package-lock.jsonis what's actually installed and running. Every serious dependency scanner reads the lockfile. Tools that skip it aren't cutting corners on purpose — they just made an architectural shortcut that leaves most of your dependency tree dark.
If your tool only reads package.json, it's not a dependency scanner.
It's a config-file reader with delusions of grandeur.
We were below the bar. We just raised it in 24 hours.
See what's actually in your dependency tree
Your scanner might be doing the same thing ours was — reading package.json and reporting 40 clean packages while 1,000 are completely dark.
Install the CodeSlick GitHub App in 30 seconds. The free tier covers 1 repo and 20 PR analyses per month. The nightly dep monitor runs automatically.
You'll either get a clean bill of health — or finally see the 1,000+ packages that have been invisible until now.