feat: add zizmor static action checks

[gforsyth]

This is an experiment in using zizmor (https://docs.zizmor.sh/) to run static analysis on all of the shared workflow files. This seems like a nice tool to add, especially in this repository.

Some of the classes of errors/warnings that are fixed here (and any associated configuration):

unpinned-uses

https://docs.zizmor.sh/audits/#unpinned-uses

Any uses: mapping should pin to an exact hash to avoid things getting swapped out underneath.
Since we deliberately make use of some of the uses: to reference our own shared-workflows and nv-gha-runners -- these are allowed to point at refs. Those patterns are configured in .github/zizmor.yml

artipacked

https://docs.zizmor.sh/audits/#artipacked

We should always explicitly set persist-credentials, either to true or false. Everywhere that the checkout action has implicitly set it to true, I have made it an explicit true.

I suspect some of these need to be true, but probably not all of them. I'll have to do some testing downstream to see which actions break when those secrets are disabled.

overprovisioned-secrets

https://docs.zizmor.sh/audits/#overprovisioned-secrets

Looking up secrets like secrets[some_key] injects the entire secrets context into the runner, but I don't see a way around that for our current secret lookup patterns. I've just ignored these instances individually.

unpinned-images

https://docs.zizmor.sh/audits/#unpinned-images

The only unpinned images belong to us and those have been individually allowlisted.

template-injection

https://docs.zizmor.sh/audits/#template-injection

Generally speaking lines like run: ${{ inputs.script }} are susceptible to template injection. Also, that's the entire point of these lines, so they are individually allowlisted.

For other potentially injectable lines, like run: rapids-wheels-anaconda "${{ inputs.package-name }}" "${{ inputs.package-type }}" , I've unpacked the inputs in to the environment and passed through those env-vars instead.

[msarahan]

Moving from v4 to sha/hash is a good way to reduce surprises, but it makes it harder to judge at a glance whether a given image should be updated. How does it work with automatic image bump tools? Maybe it would be sufficient to include a comment about what human-readable version the hash represents.

[gforsyth]

Good points @msarahan - I think dependabot can be configured to update images to the latest hash instead of the latest tag, although finding the documentation for how to do that is proving a bit tricky.

[jameslamb]

I think dependabot can be configured to update images to the latest hash instead of the latest tag, although finding the documentation for how to do that is proving a bit tricky.

You might find the links and other info at https://github.com/rapidsai/build-infra/issues/204 useful (private issue because security, sorry). I also could not find docs on how to do that with dependabot, but there are some examples there of folks who are doing it.

[gforsyth]

Thanks, @jameslamb ! From what I've seen, I think dependabot updates actions based on how they're currently specified, so if we switch to using the full SHA, it will update that in-place.

[jameslamb]

Cool, cool, that makes sense.

it makes it harder to judge at a glance whether a given image should be updated

For this point, I believe dependabot will automatically update a trailing same-line comment pointing to a tag. See dependabot/dependabot-core#5951

so e.g. if you have:

- uses: actions/checkout@abc123 # v4.2.1

It'll propose an update like:

- uses: actions/checkout@def456 # v4.2.2

That'll help with readability, I think.