ci: Run zizmor for GHA security analysis

[sprt]

This runs the zizmor security lint [1] on our GH Actions.
The initial workflow uses [2] as a base.

[1] https://docs.zizmor.sh/
[2] https://docs.zizmor.sh/usage/#use-in-github-actions

[stevenhorsman]

I'm not sure if we need the job-level explicit permissions block as well as the top-level, but it doesn't do any harm

[stevenhorsman]

Interestingly this might be the reason that the report isn't showing up in fact given the copilot review which says it need more permissions to report?

[sprt]

IMO the workflow should still show up. I think Copilot is confused - per zizmor's docs, we only need security-events: write when Advanced Security is enabled. I had disabled it because I thought it'd would fail on our repo, but I just tried enabling it again - let's see.

https://docs.zizmor.sh/usage/#use-in-github-actions

[stevenhorsman]

Ah ok - thanks!

[stevenhorsman]

Note that since this is a new workflow, it won't appear in this initial PR (even with the pull_request event).

Do you know the reason for this as when I've added pull_request workflows before they have shown up e.g. #10631 and #10958 ? My understanding was that with the pull_request target the workflows are obtained from the source branch?

[sprt]

@stevenhorsman Hmm good point, I'm not exactly sure. Maybe because you had workflow_dispatch? Maybe you ran those manually before submitting the PRs? Some people are reporting the same behavior as here in [1], and [2] says "Some events also require the workflow file to be present on the default branch of the repository in order to run."

[1] https://github.com/orgs/community/discussions/25746
[2] https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#about-workflow-triggers

[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.

[Copilot]

Pull Request Overview

This PR adds a new GitHub Actions workflow to run Zizmor security analysis on pull requests that change workflow files.

• Introduces .github/workflows/zizmor.yaml to trigger on PR changes to workflow definitions
• Configures scoped permissions and concurrency for the Zizmor job
• Adds steps to check out the repo and invoke the zizmor-action

Comments suppressed due to low confidence (2)

.github/workflows/zizmor.yaml:1

• [nitpick] The workflow name is generic; consider renaming to something like Zizmor Security Analysis for clearer identification in the Actions UI.

name: GHA security analysis

.github/workflows/zizmor.yaml:23

• [nitpick] Pinning to a commit SHA is stable but hampers readability and upgrades. Consider using a semver tag such as actions/checkout@v4 or the specific v4.2.2 tag instead.

        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

[stevenhorsman]

Is there anyway we can flag this as failing if there is any issues, or even better if there are issues above a certain threshold, so we can spot issues in PRs before they are merged?

[sprt]

Is there anyway we can flag this as failing if there is any issues, or even better if there are issues above a certain threshold, so we can spot issues in PRs before they are merged?

Yes! That will be my next step - see the second Important block here: https://github.com/zizmorcore/zizmor-action?tab=readme-ov-file#usage-with-github-advanced-security-recommended

[stevenhorsman]

LGTM. Thanks! It will be good to see if we can get the ruleset to give us more value as we work to squash these problems and stop them coming back.

[gkurz]

/lgtm

Thanks @sprt !

[stevenhorsman]

I think my suggestion in the AC meeting was actually wrong - I thought that we using if: ${{ inputs.skip-test != 'yes' }} to check this and hence it was skipped, but that's not the case. Maybe it's related to the actions allowlist?

[stevenhorsman]

Maybe it's related to the actions allowlist?

That looks fine to me 😕

[stevenhorsman]

Ok, I'm confused now as I realized that this workflow is running: https://github.com/kata-containers/kata-containers/actions/runs/15898700799/job/44836322438?pr=11392. What was the problem you were facing @sprt as I guess I misunderstood?

[sprt]

@stevenhorsman No worries we but misunderstood each other, was early for me! My issue is there's a bunch of required tests that are just not running (and not pending on anything either):

[sprt]

So maybe indeed those aren't running because the gatekeeper is seeing a workflow-only change?

[stevenhorsman]

So maybe indeed those aren't running because the gatekeeper is seeing a workflow-only change?

Yeah, that's right. Gatekeeper is green: https://github.com/kata-containers/kata-containers/actions/runs/15898700802/job/44836322457?pr=11392, so I say use admin rights to merge it 😄

[sprt]

Force-merged as discussed above.