Open security alerts rose on this board

[iderex]

Open security alerts on this board are higher than they were at the previous reading, or carry a rule id that reading did not hold.

kind	rule	was	now
code-scanning	PinnedDependenciesID	0	2

Every row is a count of open alerts grouped by rule id. The current state is read directly:

gh api "repos/Flowfin/site/code-scanning/alerts?state=open&per_page=100" --jq 'length'

What this is not

It is not a judgement of any alert. Nothing here reads a finding, weighs it, or says whether it is a true positive; the reading is a count of what the platform reports as open, grouped by rule id.

A count that falls produces no issue and no comment, so this body going quiet is not evidence that anything was fixed.

A kind that could not be read on a run contributes no count on that run and is named in that run's summary rather than passed over as a zero.

The sweep behind this is .github/workflows/fleet-alert-sweep.yml in iderex/wache, asked for by iderex/wache#31.

[iderex]

The rise is two alerts and both sit on the two lines #228 rewrote

gh api "repos/Flowfin/site/code-scanning/alerts?per_page=100&state=open" \
  --jq '.[]|"\(.number) \(.tool.name) \(.rule.id) \(.created_at) \(.most_recent_instance.location.path):\(.most_recent_instance.location.start_line)"'
36 Scorecard PinnedDependenciesID 2026-09-02T06:42:07Z .github/workflows/release.yml:76
35 Scorecard PinnedDependenciesID 2026-09-02T06:42:07Z .github/workflows/package-caller.yml:32
8 Scorecard MaintainedID 2026-08-07T22:08:54Z no file associated with this alert:1

Run 2026-09-02. Both carry the same creation moment and both were first seen at
f51005f, which is the merge of #228, and the two locations are exactly the two
lines that merge changed:

git show 38e2f71 --format= --unified=0 \
  -- .github/workflows/package-caller.yml .github/workflows/release.yml \
  | grep -E '^[-+]    uses|^\+\+\+'
+++ b/.github/workflows/package-caller.yml
-    uses: ./.github/workflows/package.yml
+    uses: $/.github/workflows/package.yml
+++ b/.github/workflows/release.yml
-    uses: ./.github/workflows/package.yml
+    uses: $/.github/workflows/package.yml

Run 2026-09-02. So the rise is accounted for to the line, and the third row above
is the pre-existing one this issue's table does not name.

What the alert asks for cannot be written at those two lines

gh api repos/Flowfin/site/code-scanning/alerts/35 \
  --jq '.tool.name + " " + .tool.version, .most_recent_instance.message.text'
Scorecard v5.5.0
score is 8: third-party GitHubAction not pinned by hash
Remediation tip: update your workflow using [https://app.stepsecurity.io](...)
Click Remediation section below for further remediation help

Run 2026-09-02, the remediation link elided for width. The reading is that
$/.github/workflows/package.yml is a third-party action wanting a commit hash.
A hash is the one thing that form cannot carry: it names this repository at the
commit that called it, so there is no second revision to pin to, and a call it
resolved somewhere else is the failure it exists to prevent.

The other spelling is refused by an audit that already runs here

The pin to the auditor version that carries this rule and the change to $/ are
in one branch, and its two heads separate them. Both readings are from runs on
this board:

gh api "repos/Flowfin/site/actions/workflows/zizmor.yml/runs?per_page=4" \
  --jq '.workflow_runs[]|"\(.id) \(.head_sha[0:7]) \(.conclusion)"'
33599989160 f51005f success
33599863350 38e2f71 success
33599538841 37782bf failure

Run 2026-09-02. 37782bf carries the auditor pin at 1.30.0 with the old
spelling still in place, and the step that fails the build on actionable findings
is the one that failed:

gh run view 33599538841 --repo Flowfin/site --log-failed \
  | perl -pe 's/\e\[[0-9;]*m//g' \
  | grep -E 'self-repository|findings \(|package-caller\.yml:32|release\.yml:76'
help[self-repository]: use GitHub's dedicated self-repository syntax
  --> ./.github/workflows/package-caller.yml:32:11
help[self-repository]: use GitHub's dedicated self-repository syntax
  --> ./.github/workflows/release.yml:76:11
12 findings (10 suppressed, 2 safe fixes): 0 informational, 2 low, 0 medium, 0 high

Run 2026-09-02, the documentation-link lines elided. So the two spellings are
refused by different tools and there is no third one. Restoring ./ takes these
two alerts down and reds Audit workflows (zizmor) on the same two lines, which
is a red gate traded for a count.

Neither tool has a newer release to move to

gh api "repos/ossf/scorecard-action/releases?per_page=1" --jq '.[].tag_name'
v2.4.4
gh api "repos/ossf/scorecard/releases?per_page=1" --jq '.[].tag_name'
v5.5.0
grep -n 'ossf/scorecard-action' .github/workflows/scorecard.yml
74:        uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4

Run 2026-09-02. The action pinned here is the newest published, it reports
v5.5.0, and v5.5.0 is the newest of that too, so waiting on an update is waiting
on a release that does not exist yet rather than on one already out.

What is left, and it is a call rather than a repair

Two answers, and neither of them is a change to this tree.

Dismiss the two as false positives. That makes this board's count fall and reads
in every later sweep as a fall, while the sentence explaining why lives only
here. It is also a judgement on an alert, which the body above says this issue
does not make.

Or leave them open. Then the count is honest and every later comparison against
this reading finds the same two standing, so the sweep goes on reporting a state
somebody has already read rather than a change.

What would end the question either way is a Scorecard release that knows the
syntax, and the two version readings above are what says whether one has arrived.

Adding blocked-on-a-decision and the milestone the gate's own checks sit in.