Actions must be pinned to a full-length commit SHA

[amilcarlucas]

Describe the bug
Security best practices dictate that githuib repositories should activate the feature:
"Require actions to be pinned to a full-length commit SHA "

All the actions I use continue to run after activating that setting except:
4876e96

To Reproduce
Use
4876e96

Activate Settings > Actions > General > Action permissions > "Require actions to be pinned to a full-length commit SHA "

Github will refuse to run the action because it does not pin it's internal dependencies.

Expected behavior
It should just work

Have you ever heard of dependabot? or renovate?

[zvonkok]

Failing for me as well, @amilcarlucas can you add a title so other people can find it easier, I almost created the very same issue.

To Reproduce

uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a

Additional context

Run ./BUILDER_CHECKOUT_DIR/.github/actions/generate-builder/generate-builder.sh
Fetching the builder with ref: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a
Invalid ref: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a. Expected ref of the form refs/tags/vX.Y.Z

[ianlewis]

Hi, This is addressed in the documentation here: https://github.com/slsa-framework/slsa-github-generator/blob/main/README.md#referencing-slsa-builders-and-generators

We are required to do this to ensure that our workflow is being called from the main branch and not some hash that is from a PR for example. This is an issue because GitHub repos share hashes with forks. slsa-verifier needs to ensure that the workflow that generated the attestation was from a good branch/version. See slsa-framework/slsa-verifier#12

[amilcarlucas]

Without pinning by hash, OpenSSF Scorecard's Pinned-Dependency for GitHub actions will give warnings.
And github itself refuses to execute the action because it's dependencies are not pinned by hash.

Why don't you pin your external dependencies by hash and do not pin the main code by hash?

[ianlewis]

I realize it gives warnings. Unfortunately our case is an edge case that GitHub's controls and OpenSSF Scorecard doesn't account for.

It's a bit difficult to explain without going into the weeds about how GitHub Actions works. We need to be able to make sure that provenance created by slsa-github-generator are built using a release on our (slsa-framework/slsa-github-generator) main branch. It is possible for someone to call the workflow like so, using our repository owner and name but with a hash from a PR (created by a third party) against the repository:

 uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@<some long hash> # This hash is a commit from a PR
  with:
    base64-subjects-as-file: "${{ needs.build.outputs.subjects-as-file }}"

This would run using the workflow on a commit that we don't control and would be indistinguishable from a one we do control without extensive, complicated, and error-prone use of the GitHub API to verify the commit. This is due to limits in how GitHub Actions works. If calling a workflow by pinned hash, the workflow doesn't get any information about any associated branch or tag it's being run on (and indeed if it's a fork or not) so we can't distinguish between main commits that we trust, and PR commits that we don't.

slsa-verifier has logic to make sure that the version of the slsa-github-generator workflow is trustworthy (and thus that the provenance itself is trustworthy) by verifying the tag. This information is only available if our workflow is called with a tag.

[amilcarlucas]

It is possible for someone to call the workflow like so, using our repository owner and name but with a hash from a PR (created by a third party) against the repository

If someone does that, It's their error, and their responsibility!

I will not disable github security:

Activate Settings > Actions > General > Action permissions > "Require actions to be pinned to a full-length commit SHA"

On my repository and compromise the security of 60+ github actions that I use to workaround a bug in your github action.
It's the single one of the 60+ that does not play nice.

So what you are saying is that to prevent an edge case of:

1. someone putting and incorrect hash, and
2. doing a PR with malicious code.

You are forcing your users to bypass github's recommended security mechanisms.
So to use your action users have to expose all their other actions?

Isn't the conclusion here that to improve security I will need to stop using your action?

[ianlewis]

If someone does that, It's their error, and their responsibility!

The "someone" I was referring to there is the bad actor not the victim. I agree it's the responsibility of the one that generates the provenance and artifact but they're the bad actor in this case so they're doing it by choice. The owner of the repo doesn't have to make any errors for this to be a security issue.

The problem is not necessarily in the generation, but the verification. Without this protection, a bad actor could create a fork of your repo, create a PR, and generate provenance with their own workflow. The provenance would say that it was created using our workflow on the source code of your repo. It would look like valid provenance and consumers of the artifact would be none the wiser. For that reason, slsa-verifier would not be able to trust the provenance.

Isn't the conclusion here that to improve security I will need to stop using your action?

I share your frustration. Given how GitHub Actions works we just don't have a lot of wiggle room here.

Since this problem with GitHub Actions isn't likely to be fixed soon, the choice is a tradeoff. If you think that maintaining your settings gives you more with regard to security than the protections we are providing on the verification side (and it sounds like you do), then you are free to do that.

For us, the tradeoff between allowing pinning the action vs. allowing a bad actor to generate provenance this way means we have to chose to protect against the later.

[amilcarlucas]

It would be perfect if github would allow one to disable SHA pining for just a set of defined actions, but alas, it does not :(