chore: add zizmor pre-commit hook for GitHub Actions workflow compliance

[Copilot]

Adds zizmorcore/zizmor-pre-commit to .pre-commit-config.yaml to statically analyse GitHub Actions workflows for security issues locally, complementing the existing CI zizmor workflow.

• .pre-commit-config.yaml: appends the zizmor hook as a remote repo entry (installed via PyPI wheels — no Rust toolchain required)

- repo: https://github.com/zizmorcore/zizmor-pre-commit
  rev: v1.24.1
  hooks:
    - id: zizmor

No workflow files are modified; this is a dev-tooling-only change.

Original prompt

Create a new branch copilot/zizmor-pre-commit-hook from copilot/chore-harden-github-workflows in CycloneDX/cyclonedx-python-lib.

In that new branch, update .pre-commit-config.yaml to add the following pre-commit repo hook (no extra args, keep minimal config):

- repo: https://github.com/zizmorcore/zizmor-pre-commit
  rev: v1.24.1
  hooks:
    - id: zizmor

Integrate it into the existing file’s structure.

Then open a pull request targeting the base branch copilot/chore-harden-github-workflows.

The pull request description MUST follow the repository’s PR/ticket template. Locate the template file (commonly .github/pull_request_template.md, .github/PULL_REQUEST_TEMPLATE.md, or similar) and populate it appropriately for this change.

Notes/constraints:

• This change is only to add a pre-commit hook to check GitHub Actions workflows for compliance; it must not modify any workflow files.
• Keep the addition minimal and aligned with the repo’s current formatting.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: zizmor is a crate, right? how would this be installed?

Assistant: Yes—zizmor is a Rust crate / CLI, not a Python package. So deps = zizmor in tox will not work (tox “deps” are pip-installable Python packages).

You have a few workable installation patterns; the right one depends on what you want to require from contributors:

Option A (recommended): install via cargo (Rust toolchain)

• Install: cargo install zizmor
• Pre-commit/tox: just run zizmor ... (or verify it exists)

This is the most “native” for a Rust CLI, but it requires contributors to have Rust installed.

Option B: install a prebuilt binary in CI/dev (e.g., GitHub Releases)

• Download the correct zizmor binary for the OS/arch and put it on PATH.
• Then tox/pre-commit runs zizmor ....

Good for CI, but for local dev you need a helper script (curl/wget) and handling for macOS/Linux/Windows.

Option C: run via a container (Docker)

• docker run ... zizmor ...
• Works without Rust, but requires Docker and is slower/heavier for pre-commit.

How I’d wire this into tox (keeping “all logic in tox”)

Create a tox env that:

1. checks zizmor exists, and
2. runs it against .github/workflows.

Example shape:

[testenv:zizmor]
description = Scan GitHub Actions workflows with zizmor (requires zizmor on PATH)
skip_install = true
commands =
    python -c "import shutil,sys; sys.exit(0 if shutil.which('zizmor') else 1)"
    zizmor .github/workflows

Then your pre-commit hook remains:

  - repo: local
    hooks:
      - id: zizmor
        name: zizmor
        entry: poetry run -- tox r -e zizmor
        pass_filenames: false
        language: system

Key concern

Because zizmor isn’t pip-installable, tox cannot automatically provision it unless you add a custom “download/install zizmor” step (script) or require cargo install as a prerequisite.

If you want, I can suggest a concrete “bootstrap” approach (e.g., a small scripts/install-zizmor.sh that downloads a pinned release) so contributors don’t need Rust, and tox can call that script before running zizmor.

User: so there is no need for a python wrapper, right?

Assistant: Right—there’s no need for a Python wrapper just to use zizmor as a pre-commit check.

Because zizmor is a standalone CLI, the clean approach is:

• ensure the zizmor binary is available on PATH (installed via cargo install zizmor or downloaded as a pinned prebuilt binary), and
• have tox/pre-commit invoke zizmor directly.

A Python wrapper would only be useful if you specifically want extra behavior, like:

• auto-downloading the correct zizmor binary per OS/arch,
• enforcing a pinned zizmor version in a cross-platform way,
• post-processing output into a different format.

But for “just scan workflows for compliance (read-only)”, invoking the CLI directly is sufficient and simpler.

User: ```

• repo: https://github.com/zizmorcore/zizmor-pre-commit
  rev: v1.23.1
  hooks:
  • id: zizmor

how about this pre commit config? 

Assistant: That config is the simplest/cleanest way to add zizmor to pre-commit if zizmorcore/zizmor-pre-commit is a proper pre-commit hook repo (i.e., it contains a .pre-commit-hooks.yaml and handles installing/running zizmor). In that case, pre-commit will manage fetching the hook at rev: v1.23.1, and you don’t need tox or a local/system hook for it.

Concerns / things to verify before adopting it:

1. Style consistency

• Your repo currently uses only repo: local + language: system hooks.
• Introducing a remote hook repo is a style change (not necessarily bad), but it’s a difference.

2. Supply-chain / pinning

• Pinning to a tag v1.23.1 is good.
• Even better (if the project prefers maximum reproducibility) is pinning to an exact commit SHA.

3. **W...

This pull request was created from Copilot chat.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage · +0.00% coverage variation

Metric	Results
Coverage variation	✅ +0.00% coverage variation
Diff coverage	✅ ∅ diff coverage (80.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (8ad0fd2)	5950	5603	94.17%
Head commit (bfc42e7)	5950 (+0)	5603 (+0)	94.17% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#972)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}