octoscope 0.34.0 — it stops blaming you for your own refactor

You rename packages/cli to apps/cli. The next scan tells you a dependency started running code at install, and another one stopped. Nothing started — you moved a folder.

0.34.0 is four changes that are the same sentence from different angles: a security signal is only worth reading if it fires on what happened, not on what you did to your own repo. An axis that cries wolf is one you learn to skip, and then it's worth nothing on the day it's right.

The workspace fix: the lockfile parser keyed a package by its path, so a monorepo reorganisation produced a screenful of fake findings at once. It reads the declared name now. I measured 115 workspace entries across seven npm-workspace monorepos first — npm writes the name field exactly when it differs from the directory basename, 85 carried one, and all 85 differed.

The part I'm most pleased about is the one nobody would have seen: changing that key would have made the first scan after the release report every install-script workspace as newly arrived. The upgrade would have been indistinguishable from the thing the axis exists to warn you about. The baseline records which key format it holds now, so an old one reads "not comparable" instead of being diffed against a different scheme. Costs you one scan.

Tip: if you have a big monorepo, this release is the one that starts reading it. The lockfile read was sharing a 1.5 MiB cap meant for a different question — gutenberg's lockfile is 1.81 MiB, puppeteer's 1.63. The repos with the most dependencies to watch were exactly the ones where the axis had quietly gone silent. Own 4 MiB ceiling now.

Second tip: run a scan twice and diff the two reports by eye. That now actually works — findings of equal weight used to come out in Go map order, so the block shuffled between runs.

Also: Homebrew ships a cask rather than a formula, so it serves Linux Homebrew too. And a confession — 0.34.0's macOS cask installed a binary that macOS killed at launch, because a cask's download is quarantined where a formula's is not. brew upgrade --cask gfazioli/tap/octoscope fixes it. Every check in my pipeline was green; not one of them executed the thing it installed. That one's on me and there's now a gate for it.

brew upgrade --cask gfazioli/tap/octoscope

When a security tool fires on something you did yourself, how many times does it take before you stop reading that section entirely?

Site:

Newsletter:

Mastodon:

50 views

Add a comment

Replies

Best

The monorepo rename fix sounds really useful. Getting a bunch of false security alerts just because you moved things around can get annoying fast.

 'just because you moved things around' is the whole reason it got fixed — a folder move was reading as a package that had started executing code at install... annoying is exactly the word for it 🙂

 Exactly 😄 Glad you fixed that, because those false alerts could easily make people ignore a real one.

The install script example shows a tricky blind stop in testing. Have you added any checks specifically for binaries that install successfully but fail immediately when executed?

 yes, added yesterday — and your question is basically the postmortem of our own 0.34.0. That release passed brew install, brew info and brew style, then shipped a macOS binary that got SIGKILLed at launch: every check was on the recipe, none of them executed what got installed.

.. so there's now a job that downloads what was actually published, re-applies the quarantine flag by hand and runs it. The part I'd press on anyone building this is the negative control — the same binary re-signed ad-hoc, which has to die when quarantined, because otherwise the whole job passes on a machine where Gatekeeper isn't enforcing. ngl that earned its keep immediately: its first run went red, not because of the release but because GitHub's macOS runner reports "assessments enabled" and runs an ad-hoc quarantined binary anyway. It detects rather than prevents, though — it runs after publish