fix(threatcrush-scan): pin the CLI install spec instead of @latest - #952
Merged
Conversation
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
ThreatCrush Security Scan310 finding(s) HIGH/CRITICAL: 24 | MEDIUM: 50 | LOW: 236
…and 260 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 13, 2026
#952 pinned threatcrushPackageSpec to 0.11.0 and bumped the manifest to 1.2.0 while this branch was open, with a better reason than the one here: the `workspace:` protocol slip in 0.7.0/0.7.1 is what @latest actually cost, and that is worth more in the file than a rule number. Both sides reached the same default, so the manifest and README go back to master's wording verbatim — which also un-conflicts the branch. What is left is the half master still does not have: --ignore-scripts on the install, and persist-credentials: false on checkout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ralyodio
added a commit
that referenced
this pull request
Aug 13, 2026
) * fix(threatcrush-scan): pin the CLI, drop install scripts and the checkout token SonarQube fails the pack's own workflow on a repository that runs it, which is a poor look for a security scan: githubactions:S6505 omitting --ignore-scripts allows lifecycle scripts to run during package installation githubactions:S8543 using dependencies without locking resolved versions Both are fair. The job holds `pull-requests: write` and `security-events: write`, and it was installing a floating `@latest` with lifecycle scripts enabled — so an npm publish by anyone in the CLI's dependency tree ran arbitrary code inside a write-scoped job on a stranger's runner, with a checkout credential still in .git/config. - install with --ignore-scripts. The CLI declares no install hook, and `scan` was verified to run correctly from an --ignore-scripts install. - default to an exact version rather than @latest. Whoever installs the pack renders the version current at the time; the repository upgrades when it decides to. - persist-credentials: false on checkout. Nothing in this job pushes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(threatcrush-scan): defer to the pin that already landed on master #952 pinned threatcrushPackageSpec to 0.11.0 and bumped the manifest to 1.2.0 while this branch was open, with a better reason than the one here: the `workspace:` protocol slip in 0.7.0/0.7.1 is what @latest actually cost, and that is worth more in the file than a rule number. Both sides reached the same default, so the manifest and README go back to master's wording verbatim — which also un-conflicts the branch. What is left is the half master still does not have: --ignore-scripts on the install, and persist-credentials: false on checkout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
The problem
The
threatcrush-scanaction pack installs the CLI withthreatcrushPackageSpecdefaulting to@profullstack/threatcrush@latest, and that spec is baked into every consumer's workflow at install time. So a scanner that runs on every PR is an unpinned dependency shared across the whole fleet — one bad publish breaks CI in every repo that installed the pack, simultaneously.That is not hypothetical. A
workspace:protocol slip shipped in@profullstack/threatcrush0.7.0 and 0.7.1 madenpm installfail withEUNSUPPORTEDPROTOCOL, and every@latestconsumer's scan errored on it — ~28 repos plus the testbed's own CI — on a registry problem that had nothing to do with their diff. The retry loop in the workflow can't help: a broken publish fails deterministically, not transiently.The fix
Pin the default install spec to a known-good version (
@0.11.0) instead of@latest, and bump the pack1.1.0 → 1.2.0so the fleet re-syncs consumers off the unpinned spec.@latestpublish can no longer cascade — consumers are on a version that was checked first.Consumers that want to track a different version still override
threatcrushPackageSpecper-repo.Two files: the pack default + description, and the README's input table.
Follow-up for whoever runs the fleet: existing consumers keep the
@latestvalue baked in until they re-sync to pack 1.2.0 — a fleet re-apply propagates the pin to the ~28 repos already installed.