Hello — would a pull-request security scan be useful here, or is this
already covered?
The offer is one workflow that scans each pull request diff for hardcoded
credentials, injection, SSRF and unsafe deserialisation, and writes results to
the Security tab as SARIF plus a comment on the pull request. It is report-only
(failOn empty), so it annotates and never fails a build — a first install on a
repository with a backlog should produce a report, not a blocked pull request.
This is not a CodeQL replacement, and it is worth saying where it differs.
CodeQL does semantic dataflow analysis and is better at it than this is — a
repository already running it is not missing much by closing this. Two gaps it
does fill:
- Code scanning and secret scanning are free on public repositories, but need
paid GitHub Code Security / Secret Protection on private ones. This is MIT and
free on both, so the same gate can run across a mixed set of repositories.
- CodeQL analyses a fixed set of languages, and among compiled ones it analyses
only the language with the most source files unless it's explicitly configured
otherwise. In a polyglot repository the rest goes unscanned by default; this
reads every file it is pointed at.
It is additive and report-only, so running both costs a few CI minutes and
changes nothing else.
How it is wired, since this is the part worth objecting to:
- runs on
pull_request, not pull_request_target, so contributor code never
executes with your secrets in scope
- installs a pinned
@profullstack/threatcrush@0.11.0 with --ignore-scripts
contents: read, pull-requests: write, security-events: write, and
persist-credentials: false on checkout- two files, both under
.github/; nothing else in the tree is touched
Disclosure: I maintain ThreatCrush.
It is free and MIT, and the workflow installs it from npm — nothing here phones
home. I am opening a pull request alongside this so the diff is there to read if
you want it, and it can be closed and this discussed instead. That pull request
also carries the output of an actual run against this repository, so the thing
being offered can be judged without enabling anything: GitHub withholds workflow
runs from first-time contributors, so the check on it may never run by itself.
If this is not something you want, saying so is the right answer and I will not
ask again.
Hello — would a pull-request security scan be useful here, or is this
already covered?
The offer is one workflow that scans each pull request diff for hardcoded
credentials, injection, SSRF and unsafe deserialisation, and writes results to
the Security tab as SARIF plus a comment on the pull request. It is report-only
(
failOnempty), so it annotates and never fails a build — a first install on arepository with a backlog should produce a report, not a blocked pull request.
This is not a CodeQL replacement, and it is worth saying where it differs.
CodeQL does semantic dataflow analysis and is better at it than this is — a
repository already running it is not missing much by closing this. Two gaps it
does fill:
paid GitHub Code Security / Secret Protection on private ones. This is MIT and
free on both, so the same gate can run across a mixed set of repositories.
only the language with the most source files unless it's explicitly configured
otherwise. In a polyglot repository the rest goes unscanned by default; this
reads every file it is pointed at.
It is additive and report-only, so running both costs a few CI minutes and
changes nothing else.
How it is wired, since this is the part worth objecting to:
pull_request, notpull_request_target, so contributor code neverexecutes with your secrets in scope
@profullstack/threatcrush@0.11.0with--ignore-scriptscontents: read,pull-requests: write,security-events: write, andpersist-credentials: falseon checkout.github/; nothing else in the tree is touchedDisclosure: I maintain ThreatCrush.
It is free and MIT, and the workflow installs it from npm — nothing here phones
home. I am opening a pull request alongside this so the diff is there to read if
you want it, and it can be closed and this discussed instead. That pull request
also carries the output of an actual run against this repository, so the thing
being offered can be judged without enabling anything: GitHub withholds workflow
runs from first-time contributors, so the check on it may never run by itself.
If this is not something you want, saying so is the right answer and I will not
ask again.