Security: 2 code-scanning alerts of class PinnedDependenciesID [code-scanning class PinnedDependenciesID]

[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 PinnedDependenciesID from code-scanning, 2 open alerts, the highest severity medium.

What the class says

Determines if the project has declared and pinned the dependencies of its build process.

The alerts

• alert Accessibility as a gate #36, severity medium, at .github/workflows/release.yml:76: https://github.com/Flowfin/site/security/code-scanning/36
• alert The rendered timing budget as a gate #35, severity medium, at .github/workflows/package-caller.yml:32: https://github.com/Flowfin/site/security/code-scanning/35

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.

[iderex]

Both alerts of this class are one false positive with one cause, and I could not
carry out the dismissal that clears them. What follows is the reading, and the
call left to make.

The line the analysis reads names no third party

git grep -n 'uses: [$]/' origin/main -- .github/workflows/
origin/main:.github/workflows/package-caller.yml:32:    uses: $/.github/workflows/package.yml
origin/main:.github/workflows/release.yml:76:    uses: $/.github/workflows/package.yml

gh api repos/Flowfin/site/code-scanning/alerts --paginate \
  --jq '.[] | select(.state=="open") | "\(.number)\t\(.rule.id)\t\(.most_recent_instance.location.path):\(.most_recent_instance.location.start_line)\t\(.most_recent_instance.message.text|split("\n")[0])"'
36	PinnedDependenciesID	.github/workflows/release.yml:76	score is 8: third-party GitHubAction not pinned by hash
35	PinnedDependenciesID	.github/workflows/package-caller.yml:32	score is 8: third-party GitHubAction not pinned by hash

Run 2026-09-07 at origin/main 9e2149a532f9004768581889ae7bb7e25b3841f5.

$/ is the self-repository syntax. It resolves to this repository at the commit
that called, so the subject the predicate names - a third-party action - is not
what is on either line, and there is no hash to pin because there is no other
repository to pin to.

Every third-party action here is already pinned by hash

git grep -h 'uses:' origin/main -- .github/workflows/ | sed 's/^ *//' | sort | uniq -c | sort -rn
     20 uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
     14 uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7.0.0
      3 uses: github/codeql-action/upload-sarif@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4.37.9
      3 uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
      2 uses: astral-sh/setup-uv@20cfd1bf945f4377ade1205e4dbc17946fc9a30d # v10.0.1
      2 uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
      2 uses: $/.github/workflows/package.yml
      2 - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      1 uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
      1 uses: github/codeql-action/init@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4.37.9
      1 uses: github/codeql-action/analyze@cdf488f595d80d6e07e03d4674febd5ab45fa938 # v4.37.9
      1 uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0

Run 2026-09-07 at the same commit. The two self-repository calls are the only
values in that set that are not a hash, and they are the two the alerts sit on.

When the class arrived, to the minute

It did not exist in the first analysis of this repository, and it has never
carried a third alert:

gh api repos/Flowfin/site/code-scanning/alerts --paginate \
  --jq '.[] | {n:.number, rule:.rule.id, state, created:.created_at}'
{"created":"2026-09-02T06:42:07Z","n":36,"rule":"PinnedDependenciesID","state":"open"}
{"created":"2026-09-02T06:42:07Z","n":35,"rule":"PinnedDependenciesID","state":"open"}
{"created":"2026-08-07T22:08:54Z","n":9,"rule":"CIIBestPracticesID","state":"dismissed"}
{"created":"2026-08-07T22:08:54Z","n":8,"rule":"MaintainedID","state":"dismissed"}
{"created":"2026-08-07T22:08:54Z","n":7,"rule":"CodeReviewID","state":"dismissed"}
{"created":"2026-08-07T22:08:54Z","n":6,"rule":"FuzzingID","state":"fixed"}
{"created":"2026-08-07T22:08:54Z","n":5,"rule":"SecurityPolicyID","state":"fixed"}
{"created":"2026-08-07T22:08:54Z","n":4,"rule":"DependencyUpdateToolID","state":"fixed"}
{"created":"2026-08-07T22:08:54Z","n":3,"rule":"LicenseID","state":"fixed"}
{"created":"2026-08-07T22:08:54Z","n":2,"rule":"SASTID","state":"fixed"}
{"created":"2026-08-07T22:08:54Z","n":1,"rule":"BranchProtectionID","state":"dismissed"}

The spelling changed at 08:41:31+02:00, which is 06:41:31Z, and the analysis that
raised the class started four seconds later:

git log -1 --format='%h %cI %s' f51005f
f51005f 2026-09-02T08:41:31+02:00 Merge pull request #228 from Flowfin/ci/the-pins-follow-the-index-with-a-sign-off

gh run view 33599989163 --repo Flowfin/site \
  --json databaseId,workflowName,createdAt,updatedAt,conclusion \
  --jq '"\(.databaseId) \(.workflowName) \(.createdAt)..\(.updatedAt) \(.conclusion)"'
33599989163 Scorecard supply-chain security 2026-09-02T06:41:35Z..2026-09-02T06:42:14Z success

The change inside that merge is #224's, and its own message says why the older
spelling was left behind:

git show 38e2f71 --stat --format='%s'
Call the packing workflow by the syntax that cannot be redirected [#224]

 .github/workflows/package-caller.yml | 2 +-
 .github/workflows/release.yml        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Why no change that lands here repairs it

Three spellings call a workflow in this repository, and none of them clears the
predicate without giving something up.

$/.github/workflows/package.yml is what is in the tree. It cannot be made to
carry a hash, because the form forbids the suffix that would hold one:

A $/ reference must not include an @{ref} suffix, and $/ is not available
in GitHub Enterprise Server.

Read 2026-09-07 from the reusable-workflows page of the GitHub Actions
documentation.

./.github/workflows/package.yml is what #224 removed. It is workspace-relative,
so a step that writes into the workspace ahead of the call decides what runs, and
the gate refuses it at the severity it is run at:

git grep -n 'min-severity' origin/main -- .github/workflows/zizmor.yml
origin/main:.github/workflows/zizmor.yml:74:        run: uvx --no-build "zizmor@${ZIZMOR_VERSION}" --strict-collection --min-severity=low --format=sarif . > results.sarif
origin/main:.github/workflows/zizmor.yml:93:        run: uvx --no-build "zizmor@${ZIZMOR_VERSION}" --strict-collection --min-severity=low --format=plain .

git show origin/main:pins.json | jq -r '.[] | select(.id=="zizmor") | .version'
1.30.0

I DID NOT RE-RUN THAT AUDIT TONIGHT and I am not offering its verdict as a fresh
measurement. The tool it calls is not present on the machine I ran from:

command -v uvx || echo "not on PATH"
not on PATH

What stands instead is the refusal recorded in #224's own commit message, at
zizmor@1.30.0, which is the version pinned above. That is a past reading, and a
change proposing to go back to ./ owes a fresh one.

Flowfin/site/.github/workflows/package.yml@<sha> is the third spelling and the
only one that would clear the predicate. It is a regression rather than a repair:
a fixed hash there is a commit that is not the calling one, so a release would
pack with whatever package.yml said at that hash until somebody noticed and
bumped it, and nothing in this tree would notice for them. A silent version skew
in the packing route is a worse tree than a wrong alert.

So the first of this issue's two routes is unavailable, and the second is the one
that applies.

The dismissal, and why it is not done

Making it is refused on the machine I ran from, before the request reaches
GitHub, so both alerts are still open and the class does not stand at zero. I did
not route around that refusal. The call is exactly this, once for 35 and once for
36:

gh api -X PATCH repos/Flowfin/site/code-scanning/alerts/35 \
  -f state=dismissed \
  -f dismissed_reason='false positive' \
  -f dismissed_comment='<the text below>'

and the comment I prepared for it, at 276 of the 280 bytes that field accepts:

$/ is GitHub's self-repository syntax: it names this repository at the calling commit rather than a third-party action, so there is no hash to pin. It replaced ./ in 38e2f71 because zizmor 1.30.0 refuses that spelling. The reasoning is in Flowfin/site#240 and operations#2175.

false positive is the right one of the three reasons the API accepts here, and
it is not the hedge won't fix was on #239: the predicate reads a third-party
action on a line that names this repository, which is wrong about its subject
rather than merely inconvenient.

What the dismissal would cost is the cost #239 named, and it is smaller here: the
class stops reporting on this board, so a genuinely unpinned third-party action
added tomorrow raises no fresh alert of this rule. Whether a later upload of the
analysis reopens a dismissed alert is not measured and I claim it in neither
direction. That cost is an argument for the floor rather than against the
dismissal.

The planning issue

operations#2175 asks how this class is kept from arriving again. It names this
issue among the nineteen board issues it covers, and what it proposes for
PinnedDependenciesID is a declared floor requiring every action and image
pinned by hash with the version beside it, read per board by a leg. Nothing here
waits on it.

What is left

The two API calls above, and nothing else.

gh api repos/Flowfin/site/code-scanning/alerts --paginate \
  --jq '[.[] | select(.state=="open") | .rule.id] | group_by(.) | map({(.[0]): length}) | add'
{"PinnedDependenciesID":2}

Run 2026-09-07. The class stands at two, and this issue closes when it stands at
zero.