Clarify on behavior when using pinned SHA1s from forks

[sschuberth]

I'm curious, does this tool also correctly reflect the "misbehavior" that "GitHub resolves the commit SHA, finds a matching object, and executes it, regardless of which fork it originated from"? I.e. are those forks listed as part of the output?

[TooFastTooCurious]

Great question, and thanks for linking that blog post — it's an excellent writeup of the problem.

Short answer: no, ABOM does not currently detect or flag this. It resolves action content the same way GitHub does — fetches from raw.githubusercontent.com/{owner}/{repo}/{sha}/ and trusts that the SHA belongs to the claimed repo. So the output accurately reflects what GitHub Actions will execute, but won't reveal that a SHA originated from a fork rather than the upstream repo.

Detecting this would require verifying via the GitHub API that the SHA actually exists in the upstream repo's commit history (not just in the shared fork-network object store). That's a meaningful addition — it would catch a real class of supply chain risk that SHA pinning is supposed to protect against but currently doesn't.

I'm open to ideas on how this should surface in the output. Some options:

• A warning flag on SHA-pinned actions that can't be verified against the upstream repo
• A dedicated --verify-shas mode that does the extra API calls (since it would add latency and require a token)
• Something else?

If you have thoughts on the right UX here, or want to contribute, I'd welcome it.

[sschuberth]

It resolves action content the same way GitHub does

That's mostly what I was after, and that's good to hear. It would actually be bad if ABOM would not "misbehave" like GitHub does, and fail to include actions from forks for those edge cases.

That's a meaningful addition

👍🏻

I'm open to ideas on how this should surface in the output.

Due to the extra API calls, which impact performance, I agree that those sanity checks should not be enabled by default. Calling such an option --verify-shas sounds sensible to me, and using that option should emit warnings if SHA1 do not come from the original repo.

Additionally, I think it would be nice if there was a way to fail in such cases. Then ABOM could be used in GitHub workflows to catch these an block execution of any other workflow. Maybe two options, --warn-on-sha-from-fork and --fail-on-sha-from-fork? Or in addition to the above, which creates warnings, a --fail-on-warnings option?

[TooFastTooCurious]

Going with your second option — generic --fail-on-warnings rather than flags per warning category. Once we have more than one category (deprecated refs, suspicious renames, missing metadata, etc.) a generic fail flag covers all of them without growing the CLI surface every time we add a check.

Design:

• --verify-shas — opt-in, does the extra API calls, emits warnings when a pinned SHA isn't in the upstream repo's commit history
• --fail-on-warnings — exits non-zero if any warnings were emitted

CI use case becomes --verify-shas --fail-on-warnings to block workflow execution on fork SHAs.

Happy to merge a PR if you or anyone else wants to pick it up. The advisory check already handles GitHub API auth so the token plumbing is there — this slots alongside it.

[sschuberth]

Sounds good! Not sure if I find the chance to contribute this any time soon, though, as I'm not a Go guy. And I'm not sure whether you'd be happy about some AI-coded stuff 😸

[TooFastTooCurious]

All good — we can pick this up ourselves. You've done the useful part by scoping the problem and the UX.

For future reference, AI-coded PRs are welcome here. Only ask is that contributors understand what they're submitting and can talk it through in review — same bar as any other PR.

[TooFastTooCurious]

@sschuberth #4