You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix Opengrep differential scan re-reporting pre-existing findings as new (SEC-1975) (#26)
Opengrep's --baseline-commit classifies a finding as new/old via a
location- and content-sensitive fingerprint of the matched range. Whole-file
"absence" rules (e.g. missing-permissions, which matches a whole job) span a
large range, so editing any line inside it (such as pinning an action SHA)
changes the fingerprint and the pre-existing finding is mis-reported as new.
This blocked the SHA-pinning campaign and any workflow edit on repos lacking
an explicit permissions: block (SEC-1975).
Replace --baseline-commit with a stable-identity diff: full-scan both the head
tree and the base tree (checked out in a git worktree) with the same ruleset,
then in opengrep-report.sh treat a finding as new only when its (rule, file)
key gained findings — new count = max(0, head_count - baseline_count), never
keyed on line number or matched text. Edits inside a pre-existing match no
longer re-report it; a genuinely new gap (added job/file/line) still is, and
still blocks. A missing/failed baseline scan conservatively treats every head
finding as new so a baseline problem never hides a finding.
Copy file name to clipboardExpand all lines: sast/opengrep/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# opengrep
2
2
3
-
Differential SAST with [Opengrep](https://opengrep.dev) for pull requests. Scans the current branch and compares against the base branch using `--baseline-commit`, **failing only on newly introduced findings**. Pre-existing findings are reported in the job summary but don't block the PR.
3
+
Differential SAST with [Opengrep](https://opengrep.dev) for pull requests. Full-scans both the PR head and the base branch, then **fails only on newly introduced findings** — a finding is "new" only if its `(rule, file)` had fewer findings on the base. Pre-existing findings are reported in the job summary but don't block the PR. Identifying new findings by stable identity rather than by line/content fingerprint means editing a file (e.g. pinning an action SHA) does not re-report a pre-existing whole-file finding such as a missing `permissions:` block.
0 commit comments