ci: scan every pull request with ThreatCrush - #1
Merged
Conversation
Runs on pull requests and pushes to master, uploads SARIF so findings are annotated on the diff and collected under Security -> Code scanning. Uses `pull_request` rather than `pull_request_target`, so a contributor's code is never executed with this repository's secrets or write access, and checks out with `persist-credentials: false`. The version is pinned: a scanner that runs on every patch is a dependency, and an unpinned one takes whatever the registry serves that morning. The scan is advisory — no `--fail-on` — so it annotates without blocking a merge. Two things do fail the job, both of them cases where a green tick would be a lie: - the scanner produced no SARIF, so the diff was not scanned; - the scanner read zero files. The second guard is specific to this repository. Everything here is one bash script in a file with no extension, and a scanner that picks files by extension alone reads none of it and still exits 0. If that check fires it means the file stopped being recognised, which is not the same as the code being clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ralyodio
marked this pull request as ready for review
August 10, 2026 17:26
GitHub runs a `run:` block with `bash -e`, so the step died on the first npx failure and every check below it — the ones that explain whether the diff went unscanned — never executed. The log showed a bare npm error with no indication of what it meant for the scan. Capture the exit codes instead, and fail with a message naming the likely cause when neither report is produced. Co-Authored-By: Claude Opus 5 <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
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.
Adds a ThreatCrush security scan on every pull request, with SARIF uploaded so findings are annotated on the diff and collected under Security → Code scanning.
Why the version matters here
debtapis one bash script in a file with no extension. ThreatCrush 0.5.1 picks files by extension alone, so it never opens it:A clean scan that scanned nothing is worse than no scan. profullstack/threatcrush#87 adds shebang detection and a shell rule set; with it, this repository scans properly.
What it finds today
8 findings, all genuine, all the same class — package sources fetched without a trustworthy channel:
sh-insecure-transport-flagcurl -k -s https://packages.ubuntu.comsh-plaintext-downloadhttp://ftp.debian.org/debian/dists/sid/…sh-plaintext-downloadhttp://archive.ubuntu.com,http://ports.ubuntu.comsh-insecure-transport-flagcurl -k -L https://github.com/helixarch/virtual-packages-list-generator/…master.tar.gzsh-insecure-transport-flagcurl -k -C - -f https://aur.archlinux.org/packages.gzLines 120 and 128 are the ones worth a look: an archive and a package list fetched over HTTPS with certificate verification disabled, written into
/var/cache/debtap/, and then used to build packages. Anyone able to intercept those connections chooses what gets packaged. Dropping-kon those three calls costs nothing — all three hosts present valid certificates.The plain-HTTP fetches are inherited from upstream and are a larger change, since Debian's
Contents-*.gzis served over HTTP by default. They are worth tracking rather than fixing in this PR.Nothing is auto-fixed here; the scan is advisory.
Safety of the workflow itself
pull_request, notpull_request_target. The job checks out contributor code, so it must not hold this repository's secrets or write access. Forks get neither.persist-credentials: false— the scanner has no reason to push.permissions:limited tocontents: readandsecurity-events: write.@latestwould be an unreviewed one.--fail-on. Advisory: it annotates, it does not block a merge.What does fail the job
Only the two cases where a green tick would be false:
The second is specific to this repository, for the reason above. If it ever fires, it means the script stopped being recognised — which is not the same as the code being clean, and is precisely the failure this PR exists to avoid.