Generate and sign SBOM

[divolgin]

Description, Motivation and Context

Please include a summary of the change or what problem it solves. Please also include relevant motivation and context.

This adds SBOM generation and signing. Verification steps have been documented, but actual SBOM assets are not actually created during the release process.

Checklist

• New and existing tests pass locally with introduced changes.
• Tests for the changes have been added (for bug fixes / features)
• The commit message(s) are informative and highlight any breaking changes
• Any documentation required has been added/updated. For changes to https://troubleshoot.sh/ create a PR here

Does this PR introduce a breaking change?

• Yes
• No

[greptile-apps]

Security Review

The new Cosign installer action is referenced through a mutable tag. Pinning it to a reviewed full commit SHA would prevent upstream tag movement from silently changing code executed in the release workflow.

_{Reviews (1): Last reviewed commit: "Generate and sign SBOM" | Re-trigger Greptile}

[greptile-apps]

Mutable Cosign installer reference

The new sigstore/cosign-installer@v4.1.2 reference uses a movable tag, allowing upstream tag movement to silently change the code executed in the credentialed release job and potentially alter its workspace or release output. Pin the action to a reviewed full commit SHA.

How this was verified: The tag-triggered release workflow executes this mutable third-party action before SBOM generation and GoReleaser.

[divolgin]

I don't see any other action being pinned to a SHA. Pinning to a patch version is perfectly fine.

[greptile-apps]

You're right — the existing actions (actions/checkout@v7, actions/setup-go@v7, goreleaser/goreleaser-action@v7, rajatjindal/krew-release-bot@v0.0.51) are all pinned to version tags, not commit SHAs. The new sigstore/cosign-installer@v4.1.2 follows the same convention already established in this repo. My comment was inconsistent with the project's existing standards. Fair point, withdrawing this.

Shall I remember this as a rule: "Do not flag GitHub Actions version tags as requiring SHA pinning if the rest of the workflow uses version tags consistently"?

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.