Conversation
…n threshold Record the blocking-gate policy as an FNXC block and resolve FAIL_ON from an optional repository variable with a trim-then-default of `high`. The previous hardcoded empty literal made --fail-on unreachable and the findings arm dead. Co-authored-by: Fusion <noreply@runfusion.ai> Fusion-Task-Id: FUSI-052
… by executing the step body Extract the real Scan step body from the workflow, run it under bash with a contract-faithful threatcrush stub, and assert on exit code plus status= output. The stub returns exit 1 only when --fail-on was actually received, so the suite is red on the pre-fix workflow and green after — verified by reverting FAIL_ON to the bare literal (8/9 fail) and restoring. Co-authored-by: Fusion <noreply@runfusion.ai> Fusion-Task-Id: FUSI-052
…lly applied Replace the three user-facing "this diff" strings with the real scope (full working tree at the merge ref), add a header scope line, and thread the resolved threshold from the scan step through to the report so a red job states the severity boundary that produced it. Co-authored-by: Fusion <noreply@runfusion.ai> Fusion-Task-Id: FUSI-052
Co-authored-by: Fusion <noreply@runfusion.ai> Fusion-Task-Id: FUSI-052
ThreatCrush Security ScanScanned: the full working tree at the merge ref (not just the changed files). HIGH/CRITICAL: 44 | MEDIUM: 4035 | LOW: 511
…and 4540 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| # PR and a clean tree both concluded "success". | ||
| # | ||
| # Threshold `high` is measured, not taste: on the pinned | ||
| # @profullstack/threatcrush@0.11.0 a committed `postgresql://user:pass@host` |
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
2 participants
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.
Automated PR for FUSI-052.
Reviewer finding (2026-09-26 tick, Workflow Merger agent-8de5231c): the repository's security gate is STRUCTURALLY UNABLE TO FAIL ON A FINDING.
.github/workflows/threatcrush-scan.yml:142hardcodesFAIL_ON=\"\", and the only consumer (:148) appends--fail-ononly when that string is non-empty. There is no env override, noworkflow_dispatchinput, no default. ThreatCrush therefore never receives a severity threshold, per the workflow's own comment at:191it can never return exit 1, and the1)arm at:190-193that exists specifically to fail the job on findings is unreachable. Every other exit path in that step fails on a broken SCAN, not on a detected problem. A PR with a live credential in it and a PR with a clean tree both concludesuccess.This is not a style preference; it is the workflow contradicting its own recorded intent. The FNXC comment immediately above the unreachable arm says: "a gate that records the finding and then lets the job pass is not a gate." The code below that comment does exactly the thing the comment forbids.
Live proof, measured 2026-09-26 (read-only, no PR mutation)
PR
Runfusion/Fusion#3664(head71b2cf4c7c2c8429a23074ef7a8e3642a3892f31): check runThreatCrushconclusion = success (run 108348368205), while the PR simultaneously carries 6 unresolvedgithub-advanced-securityreview threads, all titledThreatCrush / predictable temporary file path (CWE-377)— alert IDs 4882, 4883, 4884 and 5442, 5443, 5444. Green gate, six open security findings, same commit.The six threads all land on one file,
docs/solutions/test-failures/main-full-suite-census-2026-09-25.md, at lines 357, 358 and 522. Those lines are markdown table rows quoting vitest assertion text verbatim, e.g. line 522 containsexpected '/tmp/fusion-test-workers-xiv9Xv/redir…' to contain '.worktrees'. The scanner reads a documentation table cell as a temporary-file path in code. The PR author already reached that conclusion independently: commite2ccb9fe3on the fork is titleddocs(FUSI-020): redact the Postgres URL that tripped ThreatCrushand its message states "The three CWE-377 hits are pre-existing false positives: shard-log assertion strings quoted verbatim in the census rows."That same commit is the second-order cost. A real
postgresql://postgres:***@localhost:5432URL in prose DID trip a HIGHDatabase URL with credentialsfinding, and a human spent a commit hand-redacting it. The scanner's signal on prose is unreliable in both directions, and neither direction is actionable because the gate cannot fail either way.Why the scan produces this class at all
SCAN_PATH=\".\"(:143) with a defaultactions/checkoutscans the whole tree at the merge ref, not the diff. So a PR that adds a documentation file inherits scanner verdicts on prose it merely quotes. The workflow's own failure text at:180calls the artifact "this diff", which is not what was scanned.Blast radius beyond Runfusion#3664
Swept all 100 open PRs' unresolved threads by author.
github-advanced-securityhas unresolved threads on 6 PRs: Runfusion#3664 (6), Runfusion#3647 (3), Runfusion#3627 (3), Runfusion#3632 (3), Runfusion#3429 (3), Runfusion#3428 (2), Runfusion#3432 (2). Every one of those threads lands on a file that PR actually modifies — checked individually, not inferred. So the alerting is at least correctly scoped to touched files; the defect is purely that none of them can ever block.What This Delivers
The security check either blocks on a real finding or stops claiming to be a gate. A red X on a committed credential has to be possible, and a green check on a PR with six open HIGH/MEDIUM findings must not read as "security clean" to the humans and agents making merge decisions.
Before → After Transformation
FAIL_ON=\"\"is a literal with no override path, so--fail-onis never passed and thestatus=findingsarm at:190is dead code.ThreatCrush: successon a PR head is reported as a green security signal on 41 open PRs, while up to 6 unresolved security threads sit on the same head.SCAN_PATH=\".\"scans the merge ref, not the diff, so prose that quotes an assertion string is judged as code, and the failure text at:180misnames the scope.status=findingsarm is reachable — or the arm is deleted and the job is honestly named as advisory, so no merge decision reads it as a gate.Steps (bounded)
FAIL_ONa real source (repo variable with a documented default, or a hardcoded severity) and prove thestatus=findingsarm is reachable. A workflow edit that leaves the arm unreachable has fixed nothing.SCAN_PATH=\".\"scans the merge ref, not the diff. Decide whether that is intended, and make the report text at:180describe the real scope either way.github-advanced-securityalerts on docs(FUSI-020): name and classify the main Full Suite red streak (1762 runs, 233 cases, 0 flakes) Runfusion/Fusion#3664, and do not touch any PR. Confirming the CWE-377 verdicts there are false positives is worth recording, but that is a human call on the Security tab — thecode-scanning/alertsREST endpoint returns 403 for this identity, so the alerts could not be independently read back this tick and their state is unverified beyond the thread titles and locations.Constraints
stash,reset,clean,switch,add, orrestore. Per project memory,git pushis blocklisted in this environment; a PR-bound implementation of this card needs thegh apiroute.docs/**is a separate decision from whether the gate can fail; a card that does both will do neither.e2ccb9fe3already shows where that road ends: every assertion string in a 545-line failure census is a candidate for the next redaction commit.Non-duplication (checked 2026-09-26 against open cards)
todo) — "Extração de threads não resolvidas de todos os bots". A data-extraction task about reading bot state. It consumes the threads this card explains; it does not own the gate that produces them.todo) — the merge-gate livelock on FUSI-020. It citese2ccb9fe3only as evidence that the card's branch diverges from the live PR branch. Different layer: that card is about the engine's review-fingerprint loop, not about whether the security check can fail. Neither card mentionsthreatcrush-scan.yml.threatcrush,SARIF,security-events,fail-on,code scanning, andCWE-377across the board: no card names this workflow.Out of scope (operator holds, untouched)
#3664and every other open PR sit atreviewDecision: REVIEW_REQUIREDwith a required human approving review. The 4 ungoverned chain PRs (Runfusion#3430-Runfusion#3433,reviewDecision: null) remain FUSI-038's hazard. Neither is touched here. Runfusion#3664's own merge gate is separately stuck in the FUSI-051 livelock.