💡 Workflow Security Linting with zizmor CI Integration

[github-actions[bot]]

Summary

Add zizmor (the GitHub Actions static security analyzer maintained with Trail of Bits support) as a required CI check alongside the existing AgentShield scan. While AgentShield scans agent configuration files (CLAUDE.md, hooks, MCP configs), zizmor analyzes workflow YAML for injection vulnerabilities, mutable tag references, permission issues, and supply chain risks — a complementary security layer that catches the exact vulnerability patterns behind the Clinejection attack.

Market Signal

Trail of Bits hardened zizmor in May 2026 with full YAML anchor support, validated against 41,253 workflows from 6,612 repositories. Zizmor integrates with GitHub Advanced Security via SARIF output to the Security tab. The Wiz blog's 2026 GitHub Actions hardening guide recommends zizmor as the first line of defense for workflow security. The tool has ~24 audit rules covering:

• Template injection vulnerabilities (the exact pattern exploited in Clinejection)
• Unpinned action references
• Excessive workflow permissions
• Actions with known security advisories
• Dangerous pull_request_target usage

CodeRabbit's 2026 multi-repo analysis and the academic paper "Unpacking Security Scanners for GitHub Actions Workflows" both position workflow security linting as an essential layer that complements code-level review.

User Signal

• The org's compliance-audit.sh checks for SHA pinning and workflow structure, but does NOT perform static analysis of workflow YAML for injection patterns
• The pr-auto-review workflow has a TODO comment about pagination (line 184) — a known gap in a security-sensitive workflow
• Multiple compliance findings (check-suite-auto-trigger Compliance: check-suite-auto-trigger-347564 #374/Compliance: check-suite-auto-trigger-1236702 #373, copilot-setup-steps-invalid-job-name Compliance: copilot-setup-steps-invalid-job-name #372) suggest workflow YAML quality issues that zizmor would catch earlier in the development cycle
• The org has 7+ required workflows across all repos, creating a wide surface area for workflow-level vulnerabilities

Technical Opportunity

The org already has a Tier 1 stub pattern for security workflows (agent-shield.yml). Adding a zizmor step follows the established pattern:

# Option A: Add to existing CI pipeline
- name: Workflow Security Lint
  uses: zizmorcore/zizmor-action@v1
  with:
    sarif-upload: true

# Option B: New Tier 1 stub (preferred for separation of concerns)
jobs:
  zizmor:
    uses: petry-projects/.github/.github/workflows/zizmor-reusable.yml@v1

Zizmor's SARIF output integrates with the Security tab (which the org already requires via CodeQL). The zizmor-action GitHub Action makes integration a single uses: line. Run time is typically under 10 seconds (pure static analysis, no network calls).

Assessment

Dimension	Score	Rationale
Feasibility	high	Mature, well-maintained tool with a GitHub Action available; follows existing Tier 1 stub pattern
Impact	high	Catches an entire class of vulnerabilities (workflow injection) that no other org tool covers
Urgency	high	The Clinejection attack pattern is actively exploited; the org's 7+ workflows are unscanned for these patterns today

Adversarial Review

Strongest objection: Adding another CI check increases build time and could create redundant findings with the existing AgentShield scan. The org is already check-heavy with CodeQL, SonarCloud, CodeRabbit, Copilot, and AgentShield.

Rebuttal: AgentShield and zizmor scan fundamentally different targets — AgentShield scans agent configs (CLAUDE.md, hooks, MCP server definitions with 102 rules across 5 categories), while zizmor scans workflow YAML files (injection patterns, permissions, pinning with 24 rules). There is zero overlap in what they analyze. Zizmor runs in under 10 seconds (pure static analysis with no network calls) so build time impact is negligible. The Clinejection attack would have been caught by zizmor's template injection rules but NOT by AgentShield, since the vulnerability was in the workflow YAML itself, not in agent configuration.

Suggested Next Step

Add standards/workflows/zizmor.yml as a Tier 1 stub calling a new zizmor-reusable.yml, configure SARIF upload to GitHub Advanced Security, and add a compliance-audit check for zizmor workflow presence across all repos.

---

Proposed by BMAD Analyst (Mary) — 2026-06-05T10:43:42Z

[github-actions[bot]]

Weekly Update

What Changed

Significant new evidence supporting zizmor adoption since the original proposal on June 5:

1. Trail of Bits published a hardening update (May 22, 2026) — zizmor's code has been reviewed and hardened by one of the most respected security firms in the industry (blog post)
2. Rule set expanded to 38 audit rules — up from the initial set, covering template injection, unpinned actions, dangerous triggers, credential exposure, and more
3. VS Code extension updated (June 16, 2026) — enables developers to catch workflow security issues during authoring, before they reach CI
4. Trophy case now includes CPython, cURL, and Rust — demonstrating the tool finds real issues in production-grade projects
5. Adoption metrics: 5,600+ GitHub stars, 3.2M+ PyPI downloads — rapidly becoming the de facto standard
6. Datadog 2026 research: 71% of organizations never pin actions to SHA — confirming the gap this tool addresses

Additional context

The GitHub 2026 security roadmap (announced March 26) lists workflow dependency locking as a headline feature, validating that GitHub itself sees workflow security as a first-class concern. Zizmor provides immediate protection while GitHub's native locking is still in preview.

The org's compliance-audit.sh currently checks SHA pinning but cannot detect deeper issues like template injection patterns. Zizmor would close this gap with under 5 seconds of pipeline overhead.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	high	high	→
Impact	med	med	→
Urgency	med	high	↑

Urgency upgraded: Trail of Bits endorsement plus expanded rule set make this adoption-ready now. The org can start with high-confidence rules only and expand over time.

Recommendation

Advance. The evidence base is now strong enough for a concrete implementation plan:

1. Add zizmor-action to the CI workflow template in standards/workflows/
2. Configure initial rule set: start with unpinned-uses, template-injection, dangerous-triggers (highest confidence)
3. Add a compliance-audit check verifying zizmor is present in each repo's CI workflow
4. Roll out to this repo first as a pilot, then to downstream repos (Broodly, TalkTerm, markets)

[github-actions[bot]]

Weekly Update

What Changed

zizmor v1.26.0–v1.26.1 released June 21, 2026 with three significant new audits:

• typosquat-uses — detects misspelled action names that could be supply-chain attack vectors (e.g., actions/chekout instead of actions/checkout)
• unsound-ternary — flags unsafe pseudo-ternary expressions in workflow YAML that can produce unexpected behavior
• adhoc-packages — identifies unversioned package installations in run: steps that are non-reproducible and vulnerable to supply-chain compromise

Additional improvements: cache-poisoning audit enhancements, configurable known-vulnerable-actions database, and unpinned-uses auto-fix now generates fully qualified tags instead of partial references.

Separately: GitHub released actions/checkout v7 (Jun 18) with built-in pwn-request defense — complementary to zizmor's workflow-level linting. See new Discussion #533 for details.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	high	high	→
Impact	high	high	→
Urgency	med	med	→

Recommendation

Advance. The three new audits in v1.26 directly address supply-chain risks (typosquatting, unversioned packages) that the org is already tracking via SHA pinning and compliance audit. Integrating zizmor as a CI step would catch these patterns automatically. The typosquat-uses audit is particularly valuable given the org's heavy use of third-party actions and the recent CVE-2025-66032 on Claude Code Action.