package-url / package-url/packageurl-php

chore: Harden all GitHub Workflows using Zizmor

Open
#264 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
13
Forks
6
PR merge metrics
No merged PRs in 30d

Description

Tool

zizmorhttps://github.com/zizmorcore/zizmor

GitHub Action

zizmor-actionhttps://github.com/zizmorcore/zizmor-action

Goal

Harden all GitHub workflows using automated analysis and recommendations.

Implementation idea

  • Add zizmor as a dedicated GitHub Actions workflow that analyzes all workflows in .github/workflows/**.
  • Run it:
    • on every pull request (only when files under .github/workflows/** changed), and
    • on a weekly schedule (scan the full .github/workflows/** set).
  • Triage findings and apply recommended changes to workflows to improve security/compliance.

Triggers (detailed)

  • pull_request:
    • paths: [".github/workflows/**"]
    • Runs for PRs targeting the default branch (and/or the repo’s main development branches as applicable).
  • schedule:
    • weekly cron (e.g., "0 0 * * 6" # Every Saturday 00:00 UTC)
    • Always scans all workflows under .github/workflows/** (not change-filtered).

Behavior on findings

  • If zizmor finds issues in a pull request run, the workflow check must fail (block merge) until findings are addressed.
  • Reporting should use GitHub annotations if possible; otherwise fall back to clear text output in logs/job summary.

Output / Reporting

  • Preferred: GitHub annotations surfaced directly in the PR checks UI.
  • Fallback: simple text output (logs and/or job summary) that clearly lists findings.

Implementation details / constraints

  • Workflow file: .github/workflows/zizmor.yml
  • Runner: ubuntu-latest
  • Permissions: least privilege (default to contents: read, add only what is required)
  • Add reasonable timeout-minutes to avoid hanging runs.

Acceptance Criteria

  • A zizmor workflow exists in .github/workflows/ and runs on:
    • pull_request events with paths: [".github/workflows/**"], and
    • a weekly schedule.
  • PR runs are blocking: the check fails if findings are detected.
  • Findings are surfaced via annotations where possible; otherwise via simple text output.

Exit Criteria

  • All zizmor findings are addressed by either:
    • fixing them in the same pull request that introduced them, or
    • creating individual follow-up ticket(s)/issue(s) to track and complete the remediation.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing files under .github/workflows/** and the requirements for .github/workflows/zizmor.yml. Configure zizmor-action for workflow-change pull requests and a weekly full scan, then check that findings fail PR runs and appear as annotations or clear logs. Done means all findings are fixed or tracked in follow-up issues.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, devops, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.