octoscope 0.33.0 — your lockfile, read for you
Your lockfile is the one part of a pull request nobody reads line by line. 0.33.0 reads it for you.
Until now octoscope could tell you that something in your repo started auto-executing — a hook that appeared, a workflow whose contents changed. It couldn't see the other half: a dependency that starts running code the moment you npm install. That isn't a new file and it isn't a code change, it's a lockfile diff. Branch protection and required reviews do nothing about it, because there's nothing in there a reviewer would recognise as suspicious.
Now the scan reads package-lock.json on your default branch and compares the subset of dependencies that carry an install script. A package that didn't run code at install and now does is a finding. The same version shipping different bytes is a heavier one — no upgrade explains that. An ordinary version bump gets listed and scores nothing.
Tip: it rides the same baseline as the rest of the delta axis, so the 30-day window and the "compared against a baseline recorded N days ago" line apply here too. Hit s on any repo in the Repos tab.
Second tip: if your lockfile is pnpm's or Yarn's, the report says so out loud rather than going quiet. pnpm had a build declaration at lockfileVersion 6 and dropped it at 9, so building on it would have shipped a rule that decays — and silence would look exactly like "nothing here runs code at install", which is the one thing this must never imply.
The detail I enjoyed getting right: recording the subset rather than the file. I measured the last 20 lockfile revisions of axios, npm/cli and undici — 57 in all. The files churn constantly; the install-script subset moved twice, and the same version was republished zero times. That zero is what lets the sharp case carry real weight instead of teaching you to skip the axis
brew upgrade gfazioli/tap/octoscopeWhat does your team actually do with a lockfile diff today — read it, skim it, or trust the bot that opened the PR?
Site: https://gfazioli.github.io/octoscope
Newsletter: https://octoscope.substack.com
Mastodon: https://hachyderm.io/@undolog
Replies
This is genuinely useful — and honestly, I think most teams want to read the lockfile diff but just don't have the time or context to spot what matters. Your point about install scripts is spot on; that's exactly the kind of change that slips through PR reviews because nobody's actively looking for it.
On your question: in my current project, we mostly skim it — and I'll admit, we often just trust the bot. That's worked so far, but it's also a bit of a gamble. A tool like this would give me actual confidence instead of just blind trust.
Curious — does octoscope also detect when a dependency drops an install script? Or is the focus only on new/added ones? That could be interesting for cases where a package suddenly becomes less risky, which might affect your security baseline. Either way, this is definitely getting installed this week.🔒"
Netfox
@sumonmatrix yep, drops are caught too — and "we skim it and mostly trust the bot" is exactly the honest answer I was hoping that question would get. Your framing is better than mine, too: I'd filed departures under inventory, and "a package becomes less risky, which moves your baseline" is the more useful way to read it...
A dependency that stops carrying an install script gets its own line, at weight 0 — listed, never scored, since an improvement shouldn't move a verdict on its own. imo the interesting half is what happens after: the baseline drops it too, so if that package picks a script back up later it arrives as a new one at full weight. I ran that round trip before answering — drop, then regain, and the second one scores... the one limit worth naming.. it only reads as a drop when the package leaves the install-script set entirely, so a version bump of something that still runs a script is a bump, not a drop plus an add
@gfazioli "Ah, that's a really elegant design choice — the baseline dropping the weight too is something I wouldn't have thought of, but it makes complete sense. Otherwise, you'd get stuck with 'false positive' noise forever just because a package used to be risky.
The weight 0 approach for drops is actually clever — listing it as informational but not penalizing the team for removing risk. That's the kind of nuance that makes a security tool actually usable, instead of just generating alert fatigue.
One follow-up: does the baseline drop happen automatically as soon as the lockfile diff is detected, or is there a manual confirmation step? Just wondering how that works in practice when you're running it across multiple repos with different security postures.
Also, really appreciate you running that round-trip test before shipping it — that level of care shows in the final product. Already installed it, and I'm impressed with how fast it runs.🔒"
Netfox
@sumonmatrix Automatic, no confirmation step — though the bit worth correcting is "as soon as the lockfile diff is detected": nothing is watching. octoscope scans when you press s on a repo, so the baseline moves at that moment and not before. Each repo keeps its own, keyed by owner/name in a single file beside your config, so different postures across repos never interfere — and deleting that file just starts everything fresh...
tbh the sharp edge is the flip side of the thing you liked: the write is unconditional, so scanning a repo while it is already compromised makes that the baseline, and the next scan would happily report nothing changed. Which is why the report carries its own line for exactly that case, saying the baseline was recorded while the repo was already flagged and that an absence of changes is not a clean bill of health. Your "stuck with false-positive noise forever" is the reason it works this way at all, and that line is what it costs.
glad it's quick on your end — the lockfile read has a fetch budget of its own, precisely so it can't crowd out the axis that catches the actual payload 👍
@gfazioli "That's a really important edge case to call out — and honestly, I appreciate that you're surfacing it rather than hiding it. The line about 'baseline recorded while already compromised' is exactly the kind of honesty that makes a security tool trustworthy.
Makes total sense that the write is unconditional — otherwise you'd have to build a whole separate 'is this repo clean' system just to decide when to record. The trade-off you described (false positives vs silent baseline) feels like the right one.
Already using it on a few internal repos, and the speed is genuinely impressive. Thanks for the detailed breakdown — this thread alone has been more educational than most tool docs I've read this year."