package-url / package-url/packageurl-php
chore: Harden all GitHub Workflows using Zizmor
Open
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 13
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
Tool
zizmor — https://github.com/zizmorcore/zizmor
GitHub Action
zizmor-action — https://github.com/zizmorcore/zizmor-action
Goal
Harden all GitHub workflows using automated analysis and recommendations.
Implementation idea
- Add
zizmoras 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).
- on every pull request (only when files under
- 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).
- weekly cron (e.g.,
Behavior on findings
- If
zizmorfinds 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-minutesto avoid hanging runs.
Acceptance Criteria
- A
zizmorworkflow exists in.github/workflows/and runs on:pull_requestevents withpaths: [".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
zizmorfindings 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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