Feature: Optionally resolve tags to hash when building an ABOM

[funnelfiasco]

Since git tags are mutable (and GitHub does not require Actions to use the new Immutable Releases feature), an action that pins to a tag may not use the same code in two different times even if the tag is unchanged. In other words, the ABOM is only a semi-reliable record of the dependency graph when tags are used.

For users who want to have a more robust record of the tags used (especially if generating the ABOM in a CI run), an option to resolve and record the value of the hash associated with a tag would be helpful. I'm thinking something like --resolve-tags. If used, an entry like "slsa-framework/slsa-github-generator@v2.1.0" would turn into "slsa-framework/slsa-github-generator@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a".

The slsa-github-generator action is a good example case, since the project instructs users to pin by tag instead of hash for technical reasons.

[TooFastTooCurious]

Good idea. Mutable tags are a real weak point for BOMs meant as audit or compliance evidence, and some projects (slsa-github-generator being your example) explicitly tell people to pin by tag, so there's no other path to a stable record.

Heads up: ActionRef already has an empty resolved_sha field. Never got populated because I didn't have a clean trigger. --resolve-tags is the right trigger.

Fits with the verify-shas infra from #4 that just landed. The commits API endpoint we already call takes any ref name and returns the resolved SHA in the response body, so most of the plumbing is done.

Few design questions worth nailing down first:

1. Tags only, or branches too? Branches are even less stable, which argues for including them, but someone pinning to main is probably opting out of stability already.
2. If both flags get passed, my read is: resolve tags first, and verify-shas is a no-op on the resolved SHAs since they come from upstream refs by definition. Worth being explicit in the docs.
3. Output shape: resolved_sha alongside the original ref, not as a replacement. Keeps the original pinning visible for anyone reading the BOM later.

Happy to pick this up next unless you'd rather take it.

[funnelfiasco]

Tags only, or branches too? Branches are even less stable, which argues for including them, but someone pinning to main is probably opting out of stability already.

I think branches, too is good. Even if the user is opting out of stability, as you say, preserving the state at a given moment in time could still be valuable to them. And if not, they don't have to use the --resolve-tags flag (although maybe we should use a different name)

If both flags get passed, my read is: resolve tags first, and verify-shas is a no-op on the resolved SHAs since they come from upstream refs by definition. Worth being explicit in the docs.

Makes sense to me.

Output shape: resolved_sha alongside the original ref, not as a replacement. Keeps the original pinning visible for anyone reading the BOM later.

Yeah, that makes sense, too.

[TooFastTooCurious]

Agreed on branches. For the name, --resolve-refs mirrors the existing RefType in the code and reads cleanly for both tags and branches. Going with that unless you've got a better one.

Heads-down on the OSV migration over on advisories right now. --resolve-refs is next up after that.