fix(threatcrush-scan): pin the CLI to 0.11.2, which has the false-positive fix - #966
Merged
Conversation
…itive fix The pin protects consumers from a bad publish. It equally withholds a good one, and that side of it just bit: pack 1.6.0 pinned 0.11.0, which predates the false-positive work released in 0.11.2. A consumer on the newer pack got the noisier scanner while an older install tracking @latest got the fixed one. On qryptchat-web that is 91 findings versus 13, and five spurious HIGHs versus none. All five were false — three flagged TOKEN="${TOKEN:-}", a shell reading a token from the environment, which is the remediation reported as the defect. Verified the hash against the published tarball with the same pipeline the workflow uses, rather than copying it from `npm view` alone: npm pack @profullstack/threatcrush@0.11.2 openssl dgst -sha512 -binary *.tgz | openssl base64 -A Both match sha512-8N3jqCQixK0Onc+/bvuJaNCSvGZlJYZcSAGsd1nEfRZ4kOu1Ifom 7Bd1t2muYJAmAxBTPmz1iseWSay/0gg3Gw==. Adds a test that the spec and the hash cannot drift apart, and that the README quotes the same version the manifest pins — a stale table is how someone bumps the spec while reading the previous version's hash, and a mismatched hash fails closed with a job log that does not say why. Confirmed the test fails when the spec is moved on its own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
ThreatCrush Security Scan84 finding(s) HIGH/CRITICAL: 24 | MEDIUM: 51 | LOW: 9
…and 34 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
ralyodio
added a commit
that referenced
this pull request
Aug 16, 2026
#966 landed the same version bump from the other direction — 0.11.0 -> 0.11.2 with the identical integrity hash — while this branch was open. The only conflict was the pack version line, and it is a conflict about arithmetic rather than about content: master said 1.6.1 for the pin, this says 1.7.0 for removing a file the pack installs. Removing an installed file is the larger change, so 1.7.0 stands and subsumes the patch bump. Nothing else disagreed. Both sides wrote the same spec and the same hash, which is the reassuring outcome — two people reading `npm view` got the same answer.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The pin protects consumers from a bad publish. It equally withholds a good one — and that side of it just bit.
Pack
1.6.0pins@profullstack/threatcrush@0.11.0, which predates the false-positive work released in0.11.2. So a repository on the newer pack gets the noisier scanner, while an older install tracking@latestgets the fixed one. That inversion is the whole reason this is worth a PR rather than a chore.On qryptchat-web, measured:
All five HIGHs were false. Three flagged
TOKEN="${TOKEN:-}"— a shell script reading a token out of the environment, i.e. the remediation reported as the defect. The one genuine finding in the original 91, a nested quantifier in a URL validator, is still reported.The hash
Verified against the published tarball using the same pipeline the workflow runs, rather than trusting
npm viewalone:npm pack @profullstack/threatcrush@0.11.2 openssl dgst -sha512 -binary profullstack-threatcrush-0.11.2.tgz | openssl base64 -AComputed and registry-reported values match:
Guard against the next one
threatcrushPackageSpecandthreatcrushIntegritymust move together — a hash left behind from the previous version fails closed, which is the right direction to fail and a thoroughly confusing one to debug from a job log.Added a test that both are present and well-formed, and that the README's inputs table quotes the same version the manifest pins. A stale table is exactly how someone bumps the spec while reading the old version's hash. I confirmed the test fails when the spec is moved on its own, so it isn't vacuous.
The README also now documents that a pinned pack does not receive scanner fixes until this pin moves — a scanner release isn't finished until it does.
Verification
pnpm vitest run packages/actions— 85 passed.pnpm --filter @profullstack/sh1pt-action-packs typecheck— clean.Pack version
1.6.0→1.6.1so the fleet re-syncs consumers.🤖 Generated with Claude Code