Security: 1 code-scanning alert of class SASTID [code-scanning class SASTID]

[iderex]

Board: yes

Security and quality alerts are worked before any phase, one issue per class of alert (the rule of 2026-09-05 on steinbruch, fleet-wide since 2026-09-06). This is the class SASTID from code-scanning, 1 open alert, the highest severity medium.

What the class says

Determines if the project uses static code analysis.

The alerts

• alert Adopt a format for decision records, and an index that lists all of them #2, severity medium, at no file associated with this alert:1: https://github.com/Flowfin/core/security/code-scanning/2

Done when

• This class stands at zero open alerts on the Security tab: every alert repaired by a change that lands here, or dismissed with a reason written on this issue that names the predicate, pasted from the API rather than clicked.
• The planning issue for this class on the operations tracker, which asks how the class is kept from arriving again, is named here; nothing here waits on it.

Scope: .github/workflows

[iderex]

What the alert rests on, measured

The class is one alert, and its message names a ratio rather than a defect in the code:

gh api repos/Flowfin/core/code-scanning/alerts/2 --jq .most_recent_instance.message.text
score is 9: SAST tool detected but not run on all commits:
Warn: 29 commits out of 30 are checked with a SAST tool

The predicate behind that ratio is whether the head of each of the thirty most recently merged pull requests carries a successful check run from the code-scanning application. Walking them:

gh api "repos/Flowfin/core/pulls?state=closed&sort=updated&direction=desc&per_page=100" --paginate \
  --jq '.[] | select(.merged_at != null) | "\(.number) \(.merged_at) \(.user.login) \(.head.sha)"' \
  | sort -k2 -r | head -30 > prs.txt
while read -r n d u hs; do
  echo "PR#$n $u head=$(gh api "repos/Flowfin/core/commits/$hs/check-runs?per_page=100" \
    --jq '[.check_runs[]|select(.app.slug=="github-advanced-security" and .conclusion=="success")]|length')"
done < prs.txt

PR#256 dependabot[bot] head=0
PR#308 iderex head=3
PR#307 iderex head=3
... twenty-seven further rows, every one head=3 ...

One head in thirty, and it is the only Dependabot proposal in the window. The analysis did run on it and did gate it - Analyze (rust) succeeded on fe2fcb98 and .github/codeql/codeql.sh check judged its SARIF in the same job. What did not happen is the upload, because both SARIF uploads on this board excluded a Dependabot author, and the reason each gave for excluding one is refuted by that run's own log:

gh run view 33360249639 --repo Flowfin/core --log | grep -oE 'SecurityEvents: write|Contents: read|Metadata: read|GITHUB_TOKEN Permissions'
GITHUB_TOKEN Permissions
Contents: read
Metadata: read
SecurityEvents: write

What landed

#312, merged as 13defcfc4b8f660d946666c6a90dfe70f221ed6a, with all twenty-eight checks green at its head. Both upload conditions now exclude a fork's pull request and nothing else, and the corrected paragraph in each file carries the reading above.

Why this does not close, and what ends the wait

The class is not at zero and cannot be brought there by a change to this tree. The window is a fixed count of merged pull requests, and fe2fcb98 sits inside it with the history it has. Nothing that lands now gives that head a check run it did not get in August, and manufacturing one by re-running an old workflow would produce the tick without the analysis reaching the surface, which is the opposite of what the alert is about.

What clears it is fe2fcb98 leaving the window: thirty pull requests merged after #256, of which #312 is the first. Re-read rather than assumed, with the first row being the newest merge and the alert clearing when no row of the thirty answers head=0:

gh api repos/Flowfin/core/code-scanning/alerts/2 --jq '.state + " " + .most_recent_instance.message.text'

Scorecard re-scores on a push to main and weekly on 27 4 * * 1, so the reading moves without anything here being run.

The next Dependabot proposal is where the repair is read on the runner. The grant is measured; the upload call itself has never been made on a Dependabot head on this board. If it fails, the cost is bounded by an ordering both workflows keep - the upload step runs after the judging step - so a red upload names an upload that did not happen and stands behind a verdict already made. That is not an assurance that it will succeed.

blocked-on-dependency goes on for that reason: what is left is a count of merges and an upstream proposal, neither of which is work anybody can pick up here, and without the label a session listing what is available reads this body to find that out, one after another.

The planning issue for this class

It exists, and this comment cannot name it. The write gate refused an earlier draft of this text on exactly the line that carried the reference, because that tracker is not one a public board may name. So the second done-condition cannot be met in this issue's own text while both rules hold, and this is what stands in its place: the planning issue is open, it asks how a family of six supply-chain alert classes is kept from arriving again by declaring a floor every board of the family carries, it names this alert's class among the six, and it names this issue among the board issues it covers. Nothing here waits on it.

What is not covered

The fork half of both conditions is untouched and unmeasured: both files still say a fork's pull request runs with a token that cannot write security events, and no run on this board has been read for it. It stays a claim.

[iderex]

The fork half stays a claim, and why it stays one is measured now rather than only stated

The comment above closes by saying the fork half of both conditions is untouched
and unmeasured and that no run on this board has been read for it. There is no
such run to read, and that is a reading rather than an absence of effort:

gh api "repos/Flowfin/core/pulls?state=all&per_page=100" --paginate --jq '[.[] | select(.head.repo.full_name != "Flowfin/core")] | length'
0
gh api repos/Flowfin/core --jq '.forks_count'
0

No pull request on this board has ever come from anywhere but this repository,
and nothing has forked it, so the excluded case has never run and cannot be made
to run here without somebody forking. The claim stays a claim, and what is added
is that reading it needs an event this board has never had rather than a log
somebody has not opened yet.

What the condition excludes, read against the events that can reach it

The comment above says both upload conditions now exclude a fork's pull request
and nothing else. The half of that a reader cannot check from the condition alone
is the "nothing else", because a third event would fall through both disjuncts
and skip the upload in silence. There is no third event:

git rev-parse origin/main
13defcfc4b8f660d946666c6a90dfe70f221ed6a
git show origin/main:.github/workflows/codeql.yml | sed -n '40,45p'
on:
  pull_request:
    branches: ["**"]
    types: [opened, synchronize, reopened]
  push:
    branches: [main]
git show origin/main:.github/workflows/shell-analysis.yml | sed -n '30,34p'
on:
  pull_request:
    types: [opened, synchronize, reopened]
  push:
    branches: [main]

Two triggers per file, and the condition names both:

git show origin/main:.github/workflows/codeql.yml | sed -n '143p'
        if: always() && ((github.event_name == 'push' && github.ref == 'refs/heads/main') || github.event.pull_request.head.repo.full_name == github.repository)
git show origin/main:.github/workflows/shell-analysis.yml | sed -n '105p'
        if: always() && ((github.event_name == 'push' && github.ref == 'refs/heads/main') || github.event.pull_request.head.repo.full_name == github.repository)

A push reaches only main, so the first disjunct is true on every push that
runs either workflow; a pull_request from this repository satisfies the second.
Neither file declares a schedule or a manual trigger, so no run exists that
judges and then silently declines to publish. Adding one later is where that
would change, and the condition would then have to name it.

Neither reading moves this issue. The class is at one open alert and the window
is what it waits on, both unchanged from the comment above:

gh api repos/Flowfin/core/code-scanning/alerts/2 --jq '.state + " " + .most_recent_instance.message.text'
open score is 9: SAST tool detected but not run on all commits:
Warn: 29 commits out of 30 are checked with a SAST tool
Click Remediation section below to solve this issue

I have changed no condition, no scope and no label.