ci: Superagent's new Supply Chain Scan check false-positives on first-party GitHub actions

[JSONbored]

What happened

The Superagent app started posting a second check, "Superagent Supply Chain Scan", alongside the security scan it has always posted (first observed 2026-07-31). Its first finding here failed PR #8911:

actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 has 3 supply-chain risks. Top signal: Detects keylogging and input capture patterns. Location: cache-.../dist/restore-only/index.js. Rules: threat-runtime-keylogging

It is a false positive

Verified, not assumed:

• gh api repos/actions/cache/git/ref/tags/v6.1.0 returns exactly 55cc8345863c7cc4c66a329aec7e433d2d1c52a9. It is the official GitHub-owned actions/cache v6.1.0, correctly SHA-pinned.
• The identical pin already ships on main at .github/workflows/validate-indexer-rs.yml:46.
• This repo's Actions allowlist explicitly permits github_owned_allowed.
• The rule matched bundled @actions/core stdin/TTY handling inside the action's own dist bundle. GitHub's first-party cache action is not a keylogger.

The scan fails only because the diff introduces a new dependency edge; the pre-existing identical edge on main is not re-flagged.

There is no way to turn the check off from this repo

Also verified rather than assumed:

• The app's config loader — superagent-ai/superagent-github, src/services/config.ts — merges only prScan, contributorTrust, and comments, and silently drops every other key. A speculative supplyChain: { enabled: false } in .github/superagent.yml would be an inert no-op that merely looks like it worked — the worst possible outcome for a security control.
• That public source also defines only two check names (Security scan, Contributor trust) and was last pushed 2026-05-25, i.e. before this check existed.
• The checks actually come from a different, newer app: slug superagent-security, app id 3287076 — which has no published documentation for the new check. Checked docs.superagent.sh, github.com/apps/superagent-security, the marketplace listing, and brin.sh; none document a supply-chain toggle.

Fix

Ignore the check in .loopover.yml's gate.ignoredCheckRuns — the mechanism already documented for precisely this situation (.loopover.yml.example's note on the contributor-trust check: "keeps the scan's protection and drops the noise").

The check still runs and stays visible; it just cannot gate. The Security Scan is deliberately not listed and stays fully gating.

Acceptance

• Superagent Supply Chain Scan no longer blocks merges.
• Superagent Security Scan still gates.
• Rationale recorded in-file, including why a .github/superagent.yml key was not used.

Follow-up (outside this repo)

Turning the check off at source would need either a toggle in Superagent's own dashboard or a vendor change. Worth raising with them that the rule fires on first-party GitHub-owned actions.

[linear-code]

JSO-7110

[JSONbored]

The Fix section of this issue does not work, and should not be attempted as written.

.loopover.yml in this repo does not configure the LoopOver gate. Gate behaviour — ignoredCheckRuns included — lives entirely in the ORB server's private configs. The committed file is a scope manifest plus documentation of the schema; it is not the live control surface, despite .loopover.yml.example reading as authoritative config-as-code.

This is already settled empirically rather than assumed: #8914 made exactly this change — adding gate.ignoredCheckRuns to .loopover.yml to stop the Supply Chain Scan from gating — and was closed for this reason at 11:08 today, four minutes after this issue was filed at 11:04. main's .loopover.yml has no ignoredCheckRuns key today.

So the proposed fix lands in precisely the failure mode this issue's own analysis warns about for .github/superagent.yml: an inert no-op that merely looks like it worked — the worst possible outcome for a security control, and worse here because a reviewer seeing the key in-file would reasonably believe the check had been de-gated.

Everything above the Fix section still stands and is worth keeping: the finding is a verified false positive on a GitHub-owned, correctly SHA-pinned actions/cache@v6.1.0, and the identical pin already ships on main.

What actually has to happen: the ignore is applied server-side in the ORB config by the maintainer. There is no repo-side change that accomplishes this, so there is no PR to write for it.

Suggested rewrite of the acceptance criteria, since they currently describe a repo-side deliverable that cannot exist:

• Superagent Supply Chain Scan de-gated in the ORB server config (not in .loopover.yml).
• Superagent Security Scan still gates.
• Rationale recorded wherever the ORB config records it, including why neither .github/superagent.yml nor .loopover.yml can express it.

Relabelling as maintainer-action-only rather than a code change would also stop the next agent from re-deriving #8914.