feat(zizmor): add Zizmor config validation

[mikefat]

This PR adds a step in the reusable zizmor action that will pre-validate the zizmor config file to be used in the run. If validation fails, the job stops and zizmor is not executed.

The validation will fail on any file that does any of the following:

• Defines any of these audit blocks under rules (no disable, ignore, or config is allowed): insecure-commands, template-injection, impostor-commit, known-vulnerable-actions, ref-confusion.
• Sets rules.unpinned-uses.disable
• Sets rules.unpinned-uses.config.policies with a universal "*": any entry (all uses: clauses may stay unpinned). Scoped policies such as actions/*: any or grafana/*: any remain valid.

Any other suggestions for things to be on the lookout/block are welcome

[mikefat]

Testing this changes in the private repo here and it seems to be working as expected 👍

[Copilot]

Pull request overview

Adds a policy gate to the reusable Zizmor workflow to pre-validate repo-local zizmor.yml / .github/zizmor.yml files before running zizmor, preventing configurations that weaken required security audits/pinning rules.

Changes:

• Emit a repo_local_zizmor_config step output when a repo-local zizmor config is discovered.
• Add a new validation step that parses the repo-local config and fails the job if forbidden rules/policies are present.
• Document the new repo-local config policy gate behavior and rejection rules.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/reusable-zizmor.yml	Adds repo-local config output plus a Python-based validation step gating zizmor execution.
.github/workflows/reusable-zizmor.md	Documents when the gate runs/skips and which config patterns are rejected.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zerok]

While the current implementation of the early returns appears to be correct, this is very fragile. Please at least create unittests here or move the whole step into a standalone action where you can have proper testing.

[ezebunandu]

It would be nice to add a testcase for catching multiple violations in one config, I think. Also nit, but could add tests for the other two forbidden audits.

Test cases to document that the silent pass for when there's no config file or no rules in the config file would be nice too, but that's a nittier nit -:)

[kleimkuhler]

Overall looking good. Just a doc comment right now

[ezebunandu]

LGTM.

[zerok]

I'm not 100% certain that this will work. The renovate config here currently uses the following pattern:

    {
      customType: "regex",
      managerFilePatterns: [
        "/(?:^|/)\\.github/(?:workflows|actions)/.+\\.ya?ml$/",
        "/(?:^|/)action\\.ya?ml$/",
      ],
      matchStrings: [
        "# renovate: datasource=(?<datasource>[a-z-.]+?) depName=(?<depName>[^\\s]+?)(?: (?:lookupName|packageName)=(?<packageName>[^\\s]+?))?(?: versioning=(?<versioning>[^\\s]+?))?(?: extractVersion=(?<extractVersion>[^\\s]+?))?\\s+[A-Za-z0-9_-]+[_-](?:VERSION|version)\\s*[:=]\\s*[\"']?(?<currentValue>[^\"'@\\n]+)(?:@(?<currentDigest>sha256:[a-f0-9]+))?[\"']?",
      ],
    },

Based on that the line including the version number would need to have a format like this:

SOMETHIGN_VERSION: "1.2.3"

Instead, you could set the input to be empty by default and then set the "default" version down below when you inject the PYYAML_VERSION into the process.

[mikefat]

Thanks for all your comments! Just pushed some more changes

[zerok]

Please also auto-update this version