ci: add zizmor action

[tongpu]

Description

This PR introduces zizmor to scan the security of our GitHub Actions

Issues

n/a

Checklist

• This PR contains a description of the changes I'm making
• I updated the version in Chart.yaml
• I updated the changelog with an artifacthub.io/changes annotation in Chart.yaml, check the example in the documentation.
• I updated applicable README.md files using pre-commit run
• I documented any high-level concepts I'm introducing in docs/
• CI is currently green and this is ready for review
• I am ready to test changes after they are applied and released

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[hairmare]

Does this need some change to docs/?

[hairmare]

we might also want to consider adding this: https://github.com/zizmorcore/zizmor-pre-commit

[tongpu]

we might also want to consider adding this: https://github.com/zizmorcore/zizmor-pre-commit

Adding a pre-commit action would definitely make it more transparent, but then we would end up with both the zizmor pre-commit hook and the zizmor action in the pipeline.

Does this need some change to docs/?

We could use this as a starting point to improve the documentation of the actions we're using, because right now we don't explicitly documented any of them.

[hairmare]

We could use this as a starting point to improve the documentation of the actions we're using, because right now we don't explicitly documented any of them.

sounds like a plan, right now a lot of it is implicitly covered by us using pre-commit for linting and doxing the actions setup properly would for sure be beneficial

[tongpu]

I've opened #1424 with the obvious changes to improve the security of our actions. We can choose to implement the changes in #1424 and continue with the integration of the action and improvements to the pr-sizing action in here.

[hairmare]

I just noticed that this only seems to scan for issues in the changed code, and not across the board. Are we sure that this is what we want?

[tongpu]

I just noticed that this only seems to scan for issues in the changed code, and not across the board. Are we sure that this is what we want?

Are you sure? Since the default value for input is . I would assume that it always scans the complete checked out repository.

[hairmare]

This confused be, but now it has annotations and is looking like it does the right thing...

[hairmare]

I documented any high-level concepts I'm introducing in docs/

This change might count and we'd need to update the docs as well.

Also, we could also consider adding zizmor via zizmor-pre-commit. I'm not quite 100% sure what the best way to go is atm.

[hairmare]

Just to reiterate, i have zero plans to introduce any new actions before we haven't landed most of the proposed changes from here in separate atomic commits to main. Backporting changes like cooldown to this PR won't change my mind, we need to fix main before we introduce more audit capabilities.

[hairmare]

my hunch is somewhat confirmed, when i look at the (now green) build it looks like so:

which seems to be ok, because when i click the link i see that GitHUb ingested the generated SARIF:

according to the zizmor action docs, this is fine for public repos and for private repos that have GitHub Advanced Security. We are the first case, so we don't need to consider using annotations.

What i'm not sure is if zizmor will block merges when there are issue that it should let through. I'll give that a try in a test PR so we know how it behaves.

[hairmare]

seemingly warnings go straight to the security tab and errors also get an annotation from the tab:

[tongpu]

seemingly warnings go straight to the security tab and errors also get an annotation from the tab:

When I messed up the hash to the python-setup action I got both a warning and an error as an annotation.

And we should get a "secrets-outside-env" warning anyway.

[hairmare]

And we should get a "secrets-outside-env" warning anyway.

yupp, verified that one with the screenshot above... do we know how to action the "secrets-outside-env" warning yet?

btw, running zizmor --pedantic . locally surfaces more potential for improvement than the default (audit?) persona that is active in CI.

[tongpu]

yupp, verified that one with the screenshot above... do we know how to action the "secrets-outside-env" warning yet?

The warning is only present in the release workflow, so we should be able to fix it by moving the variable from a repo variable to a release environment and reference the release environment in the job.

[hairmare]

The warning is only present in the release workflow, so we should be able to fix it by moving the variable from a repo variable to a release environment and reference the release environment in the job.

wouldn't we end up using the environments feature if we follow through on this? IMO envs add quite a bit of complexity that goes beyond isolating a bunch of CI secrets. I think we need to understand the proposed envs solution better before we are sure it won't block anything in the long run

[hairmare]

I ended up doing radiorabe/actions#199 for myself, the included ASF reference apache/infrastructure-actions#608 makes me conclude our dd on introducing zizmor with a strong "do it asap in this repo" recommendation. I'd also like to create a new adfinis/actions that helps us bundle efforts, i implementing the the pattern is well worth the efforts.

We should also figure out how we can help sustain the zizmor in a meaningful way, sound obvious, but is also well worth stating here.