The `version` input defaults to `latest` and can't be "locked"

[nafarlee]

Currently, the default for the version input is the special value latest which, as noted in the README, causes the latest released version of the zizmor image to be pulled/run:

zizmor-action/action.yml

Lines 41 to 44 in da5ac40

	version:
	description: The version of zizmor to use
	required: false
	default: latest

Further, the version input is checked to ensure it is either this special value or a three-part version string that could correspond to a particular zizmor image:

zizmor-action/action.sh

Lines 38 to 41 in da5ac40

	version_regex='^v?[0-9]+\.[0-9]+\.[0-9]+$'
	[[ "${GHA_ZIZMOR_VERSION}" == "latest" || "${GHA_ZIZMOR_VERSION}" =~ $version_regex ]] \
	|| die "'version' must be 'latest' or an exact X.Y.Z version"

zizmor-action/action.sh

Lines 63 to 82 in da5ac40

	image="ghcr.io/zizmorcore/zizmor:${GHA_ZIZMOR_VERSION#v}"
	# Notes:
	# - We run the container with ${GITHUB_WORKSPACE} mounted as /workspace
	# and with /workspace as the working directory, so that user inputs
	# like '.' resolve correctly.
	# - We pass the GitHub token as an environment variable so that zizmor
	# can run online audits/perform online collection if requested.
	# - ${GHA_ZIZMOR_INPUTS} is intentionally not quoted, so that
	# it can expand according to the shell's word-splitting rules.
	# However, we put it after `--` so that it can't be interpreted
	# as one or more flags.
	#
	# shellcheck disable=SC2086
	docker run \
	--rm \
	--volume "${GITHUB_WORKSPACE}:/workspace:ro" \
	--workdir "/workspace" \
	--env "GH_TOKEN=${GHA_ZIZMOR_TOKEN}" \
	"${image}" \

Considering this action is intended to help detect (among other things) insecure "mutable" references to external GitHub Actions plugins, I find this behavior concerning. In the event that zizmor's supply-chain is compromised and a malicious version of the image is published as latest, any users of zizmor-action that have kept the defaults would be impacted

Users can choose to target an exact version, but as before, if the zizmor supply-chain is compromised I think GitHub Packages would allow an attacker to delete published tags and republish malicious versions under the same tags

Would it be possible to:

1. Modify the version input to allow exact image digests
2. If so, change the default version to specify a particular image digest. If not, change the default version to specify an exact three-part version string

I am willing to put in PRs for one/both of these if there is an appetite for these changes

[woodruffw]

Hey @nafarlee, thanks for the issue (and for the detailed report, I greatly appreciate that).

Yeah, this was intended to be a usability tradeoff: IME users don't do a a great job of upgrading tools in their CI/CD unless it's already an explicit policy, so zizmor-action defaults to using the latest version unless the user explicitly specifies one. The thinking here is that it's difficult (in the abstract) to qualify the risk of a novel supply chain risk in zizmor versus an existing problem (a compromised dep, or a vulnerability, or whatever), so the action currently errs on the side of assuming that most users will want the newest version by default.

(This is similar to what other prominent actions do, including the official actions for Python, etc., which is why zizmor mostly focuses on action-level mutability, not images and binary assets. But there are indeed legitimate supply chain risks/concerns 🙂)

Users can choose to target an exact version, but as before, if the zizmor supply-chain is compromised I think GitHub Packages would allow an attacker to delete published tags and republish malicious versions under the same tags

Yep -- I think GitHub has looked into container tag immutability, but AFAIK all current image tags are mutable. The :latest tag itself is explicitly mutable in zizmor's case, at the minimum.

Would it be possible to:

1. Modify the version input to allow exact image digests
2. If so, change the default version to specify a particular image digest. If not, change the default version to specify an exact three-part version string

I am willing to put in PRs for one/both of these if there is an appetite for these changes

I think I'm open to either/both of these, but I have some desiderata:

• I'd prefer it if the Docker image syntax for hashes didn't leak into the inputs here, since technically this action's use of a Docker image is an implementation detail (it might be replaced with uvx or a direct binary or something else in the future).
• It would ideally be possible/easy for me to keep making zizmor releases without having to cut a new tag/release every time here -- that both increases churn for users and keeps me (a fallible human) in an otherwise automated release cycle.

Given those, I think it might be best to start with (1), and keep (2) as a larger design topic. On (1), something like this would be nice IMO:

- uses: zizmorcore/zizmor-action@e673c3917a1aef3c65c972347ed84ccd013ecda4 # v0.2.0
  with:
    version: v1.2.3@abcd...

...which the action would then translate into the appropriate @sha256:abcd... hash tag. Thoughts on that?

[nafarlee]

Thanks for the quick response, @woodruffw! Sorry in advance for the wall of text 🙏🏻

Yeah, this was intended to be a usability tradeoff: IME users don't do a a great job of upgrading tools in their CI/CD unless it's already an explicit policy, so zizmor-action defaults to using the latest version unless the user explicitly specifies one. The thinking here is that it's difficult (in the abstract) to qualify the risk of a novel supply chain risk in zizmor versus an existing problem (a compromised dep, or a vulnerability, or whatever), so the action currently errs on the side of assuming that most users will want the newest version by default.

I think I follow the thinking here: on average you expect there is greater risk in having an outdated version of zizmor (and so having incomplete/inaccurate findings) than of zizmor's own supply-chain being gravely compromised. I think I agree, and it is indeed hard to qualify.

Feel free to disregard this as the ramblings of a madman, but couldn't zizmor itself offer a novel solution here? If we were to default to a locked SHA/digest in the future, could zizmor itself alert users through the same "findings" interface that they are using an outdated version of either the zizmor-action or the zizmor image/binary? If they ever see a report that also includes that particular finding, they would know they might not be getting the "full picture" without an upgrade.

I'd prefer it if the Docker image syntax for hashes didn't leak into the inputs here, since technically this action's use of a Docker image is an implementation detail (it might be replaced with uvx or a direct binary or something else in the future).

Totally understandable

It would ideally be possible/easy for me to keep making zizmor releases without having to cut a new tag/release every time here -- that both increases churn for users and keeps me (a fallible human) in an otherwise automated release cycle.

Also understandable given the velocity of zizmor's releases. Attentive users would be able to bump their own pinned versions in theory, but it might be frequent/tedious across many repositories. Non-attentive users would be...in trouble 😅

Given those, I think it might be best to start with (1), and keep (2) as a larger design topic

Sounds good to me

On (1), something like this would be nice IMO:

- uses: zizmorcore/zizmor-action@e673c3917a1aef3c65c972347ed84ccd013ecda4 # v0.2.0
  with:
   version: v1.2.3@abcd...

...which the action would then translate into the appropriate @sha256:abcd... hash tag. Thoughts on that?

To make sure I am on the same page: if @abcd... exists, it will be transformed into the @sha256:abcd... digest syntax and included the qualifier passed to docker run. If that is correct, I have two questions:

• You mentioned not wanting to leak the implementation detail of docker. Is the idea that @abcd... is generic enough that we could/would use the same formatting were we to move to a different distribution mechanism?
• Would we want to do any additional checks to ensure v1.2.3 and @sha256:abcd... point to the same image? I think docker ignores the tag entirely if a digest is provided today. This kind of check would mostly be to improve the UX a bit (rather than seeing a docker run error if they mess up the digest), and ensure that a user won't accidentally bump the version without also updating the digest

[woodruffw]

Thanks for the quick response, @woodruffw! Sorry in advance for the wall of text 🙏🏻

No problem at all, sorry for my delayed response.

Feel free to disregard this as the ramblings of a madman, but couldn't zizmor itself offer a novel solution here? If we were to default to a locked SHA/digest in the future, could zizmor itself alert users through the same "findings" interface that they are using an outdated version of either the zizmor-action or the zizmor image/binary? If they ever see a report that also includes that particular finding, they would know they might not be getting the "full picture" without an upgrade.

Yes, definitely -- I've thought before that zizmor could have a whole "self" category of audits that would be responsible for ensuring that users write "responsible" zizmor.yml configuration files and use zizmor-action correctly. Checking for stale pins in the action would definitely fall under that category 🙂

To make sure I am on the same page: if @abcd... exists, it will be transformed into the @sha256:abcd... digest syntax and included the qualifier passed to docker run. If that is correct, I have two questions:

Yeah, that's what I was thinking!

• You mentioned not wanting to leak the implementation detail of docker. Is the idea that @abcd... is generic enough that we could/would use the same formatting were we to move to a different distribution mechanism?

Yeah, that was the initial thought. However, as I think about it more, it's kind of moot -- the hashes themselves will change if the distribution mechanism changes (since the current hashed thing is an entire container, not just a zizmor binary).

So, maybe it's okay after all to have some Docker-specific hash syntax? I'm not sure/confident here.

• Would we want to do any additional checks to ensure v1.2.3 and @sha256:abcd... point to the same image? I think docker ignores the tag entirely if a digest is provided today. This kind of check would mostly be to improve the UX a bit (rather than seeing a docker run error if they mess up the digest), and ensure that a user won't accidentally bump the version without also updating the digest

Ah yeah, this is a great point...I really wish Docker was more strict about enforcing that the tag actually matches the pinned hash. The fact that the two can deviate is itself a confusion risk (conceptually similar to the one that zizmor detects with ref-version-mismatch).

---

To take a step back: what if the hashing was "intrinsic" to the action, instead of part of the external interface?

In other words, the interface would remain:

version: vA.B.C # or default

...but the action would consult a manifest (either in the repo, or hosted somewhere like zizmor.sh) that would provide a mapping of version | 'latest' -> hashes. That manifest would then need to be signed, but that's not a huge lift with Sigstore/GH's built-in artifact signing.

The nice thing about this approach is that I could automate it to be ~similar to the current auto-updating flow, while also providing the content integrity guarantees that you (very reasonably!) want. It's also forwards-compatible, since the hash set for each version could include Docker hashes, binary hashes, etc.

The downside would be that I (or someone else) would need to design and implement that manifest, but it's probably something that needs doing in the medium term anyways 😅. I'm also not 100% sure how it interacts with multi-arch Docker images, i.e. how one hash-pins a Docker image that needs to resolve to a different underlying image based on the host arch.

I'm curious what you think about the above!

[samcrang]

I stumbled across this issue because my builds starting failing when a newer version of the zizmor Docker image was picked up and found new complaints with my GitHub Actions workflows.

For me the most important thing is that my builds don't unexpectedly break and that Dependabot picks up new versions of zizmor and raises PRs for me. With that in mind, I've got this pattern which is working for me so I thought I'd share:

It's a bit clunky but I have simple Dockerfile that references the upstream image:

FROM ghcr.io/zizmorcore/zizmor:1.15.2@sha256:a8fcfb013f9074e7569c904a38d070009ee40d61cf14bfa70de3bd36d6acaab2

I modify my workflows to parse the version out and consume it in the zizmor-action:

jobs:
  zizmor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
        with:
          persist-credentials: false
      - id: zizmor-version
        run: echo "zizmor-version=$(grep -oP 'FROM ghcr.io/zizmorcore/zizmor:\K(.*?)(?=@)' Dockerfile)" >> ${GITHUB_OUTPUT}
        working-directory: tools/zizmor
      - uses: zizmorcore/zizmor-action@e673c3917a1aef3c65c972347ed84ccd013ecda4 # v0.2.0
        with:
          version: "v${{ steps.zizmor-version.outputs.zizmor-version }}"
          advanced-security: false
          persona: pedantic

And I modify my dependabot.yml so we get PRs raised for updates:

  - package-ecosystem: docker
    directory: /tools/zizmor
    schedule:
      interval: daily
      time: "04:03"
      timezone: Europe/London

It doesn't solve all the ountstanding issues, particularly the ones around the mutable images, but at least for me it feels like a sensible middle-ground that fits my risk profile. If the version argument was optionally able to contain the Docker image reference that includes the hash, like is being discussed, then I think we'd have even tighter controls over the supply chain.