🔒 Zizmor Security Analysis Report - November 2, 2025

[github-actions[bot]]

🔒 Zizmor Security Analysis Report - November 2, 2025

This report presents the findings from a comprehensive security scan of all 67 agentic workflows in the repository using the zizmor security scanner.

Executive Summary

The security scan identified 18 findings across 3 issue types, with 3 High severity vulnerabilities that require immediate attention. All workflows compiled successfully, and the findings are concentrated in specific patterns that can be systematically addressed.

Key Highlights:

• High Priority: 3 workflows using insecure workflow_run triggers
• Low Risk: 12 template injection warnings in auto-generated code (low exploitability)
• Configuration: 3 workflows with missing permission declarations

Full Security Report

Security Scan Statistics

Metric	Count
Total Workflows Scanned	67
Workflows Compiled Successfully	67
Total Security Findings	18
Critical Severity	0
High Severity	3
Medium Severity	0
Low Severity	12
Info/Warning	3
Workflows Affected	9
Clean Workflows	58

Findings Clustered by Issue Type

1. ⚠️ dangerous-triggers (High Severity)

Count: 3 occurrences
Severity: High
Description: Use of fundamentally insecure workflow trigger
Reference: (redacted)#dangerous-triggers

Affected Workflows:

Workflow	File	Location	Trigger Type
ci-doctor	.github/workflows/ci-doctor.lock.yml	43:1	workflow_run
dev-hawk	.github/workflows/dev-hawk.lock.yml	35:1	workflow_run
smoke-detector	.github/workflows/smoke-detector.lock.yml	53:1	workflow_run

Security Impact:

• Workflows inherit elevated GITHUB_TOKEN permissions
• Can be exploited by attackers to execute malicious code
• Runs in context of default branch with write access
• Third-party PRs can trigger workflows with excessive permissions

Why This Matters:
The workflow_run trigger is a known security risk in GitHub Actions. When workflows are triggered via workflow_run, they execute with the permissions of the default branch's GITHUB_TOKEN, not the permissions of the triggering event. This creates an attack vector where malicious actors could craft pull requests that trigger these workflows with elevated privileges.

---

2. template-injection (Low Severity)

Count: 12 occurrences
Severity: Low
Description: Code injection via template expansion
Reference: (redacted)#template-injection

Affected Workflows:

Workflow	File	Location	Instances	Step Name
duplicate-code-detector	.github/workflows/duplicate-code-detector.lock.yml	1033:9	5	Setup MCPs
mcp-inspector	.github/workflows/mcp-inspector.lock.yml	1104:9	1	Setup MCPs
smoke-codex	.github/workflows/smoke-codex.lock.yml	1015:9	5	Setup MCPs
smoke-opencode	.github/workflows/smoke-opencode.lock.yml	(auto-generated)	1	Setup MCPs

Security Impact:
All instances occur in the auto-generated "Setup MCPs" step name. This is likely a false positive or low-risk finding because:

• The template expansion is in the step name, not in executable code
• The content is auto-generated by the gh-aw compiler
• No user-controlled input flows into these expressions

Risk Assessment: Low risk due to limited exploitability in current context.

---

3. missing-permissions (Info)

Count: 3 occurrences
Severity: Info/Warning
Description: Missing required permissions for GitHub toolsets

Affected Workflows:

Workflow	Missing Permissions
example-permissions-warning	contents: write, issues: write, pull-requests: write
python-data-charts	issues: read, pull-requests: read
test-secret-masking	issues: read, pull-requests: read

Impact:
While not a direct security vulnerability, missing permissions can lead to:

• Workflow runtime failures
• Unnecessary use of elevated default permissions
• Violation of least privilege principle

Note: The example-permissions-warning workflow appears to be an intentional example demonstrating this warning.

---

Detailed Findings by Workflow

ci-doctor.lock.yml

• Finding: dangerous-triggers at line 43:1
• Trigger: workflow_run monitoring "Daily Perf Improver" and "Daily Test Coverage Improver"
• Purpose: Diagnoses CI failures after completion of monitored workflows
• Risk: High - Can be exploited via malicious workflow triggers

dev-hawk.lock.yml

• Finding: dangerous-triggers at line 35:1
• Trigger: workflow_run monitoring "Dev" workflow on copilot/* branches
• Purpose: Monitors development workflow outcomes
• Risk: High - Elevated permissions on non-main branches

smoke-detector.lock.yml

• Finding: dangerous-triggers at line 53:1
• Trigger: workflow_run monitoring multiple smoke test workflows
• Purpose: Investigates smoke test failures
• Risk: High - Multiple trigger sources increase attack surface

duplicate-code-detector.lock.yml

• Finding: 5x template-injection warnings at line 1033:9
• Location: "Setup MCPs" step name
• Risk: Low - Auto-generated code, limited exploitability

mcp-inspector.lock.yml

• Finding: template-injection warning at line 1104:9
• Location: "Setup MCPs" step name
• Risk: Low - Auto-generated code, limited exploitability

smoke-codex.lock.yml

• Finding: 5x template-injection warnings at line 1015:9
• Location: "Setup MCPs" step name
• Risk: Low - Auto-generated code, limited exploitability

smoke-opencode.lock.yml

• Finding: template-injection warning in auto-generated section
• Location: "Setup MCPs" step name
• Risk: Low - Auto-generated code, limited exploitability

example-permissions-warning.md

• Finding: Missing permissions warning
• Status: Likely intentional (example workflow)

python-data-charts.md, test-secret-masking.md

• Finding: Missing read permissions for issues and pull requests
• Impact: Workflows may fail if they access these resources

---

🔧 Fix Suggestion: dangerous-triggers (High Priority)

I've generated a comprehensive fix template for the dangerous-triggers vulnerability, our highest priority security issue.

Issue: 3 workflows using insecure workflow_run triggers
Severity: High
Affected Workflows: ci-doctor, dev-hawk, smoke-detector

Recommended Fix Approach

Replace workflow_run triggers with secure alternatives:

Option 1: Use Post Steps (Recommended)

Modify parent workflows to trigger dependent workflows using post steps:

# In parent workflow (e.g., daily-perf-improver.md)
post:
  - name: Trigger CI Doctor
    if: failure()  # Or always() for unconditional triggering
    run: gh workflow run ci-doctor.yml --ref main
    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# In dependent workflow (e.g., ci-doctor.md)
on:
  workflow_dispatch:  # Change from workflow_run to workflow_dispatch

Option 2: Use Schedule Trigger

For monitoring workflows, use scheduled checks:

# In smoke-detector.md
on:
  schedule:
    - cron: '0 */6 * * *'  # Check every 6 hours
  workflow_dispatch:

# Then query recent runs via GitHub CLI

Detailed Fix Instructions

Full implementation guidance has been saved to cache memory at:
/tmp/gh-aw/cache-memory/fix-templates/dangerous-triggers.md

This includes:

• ✅ Detailed security impact analysis
• ✅ Step-by-step fix instructions for each workflow
• ✅ Before/after code examples
• ✅ Testing procedures
• ✅ Copilot agent prompt template

Copilot Agent Prompt

Use this prompt with a Copilot agent to automatically fix the vulnerabilities:

You are fixing a HIGH severity security vulnerability in GitHub Actions workflows.

**Vulnerability**: dangerous-triggers
**Issue**: Use of insecure workflow_run trigger
**Reference**: (redacted)#dangerous-triggers

**Affected Workflows**:
- ci-doctor (.github/workflows/ci-doctor.md)
- dev-hawk (.github/workflows/dev-hawk.md)
- smoke-detector (.github/workflows/smoke-detector.md)

**Security Impact**:
The workflow_run trigger is fundamentally insecure because:
- Workflows inherit elevated GITHUB_TOKEN permissions
- Can be exploited by attackers to execute malicious code
- Runs in the context of the default branch with write access

**Required Fix**:

For each affected workflow, replace the insecure workflow_run trigger with a secure alternative:

1. **CI Doctor**: 
   - Modify daily-perf-improver.md and daily-test-improver.md to add post steps that trigger ci-doctor
   - Change ci-doctor.md trigger from workflow_run to workflow_dispatch

2. **Dev Hawk**:
   - Modify dev.md to add post step that triggers dev-hawk when on copilot/* branches
   - Change dev-hawk.md trigger from workflow_run to workflow_dispatch

3. **Smoke Detector**:
   - Change to schedule-based checking (cron: '0 */6 * * *')
   - Use GitHub CLI to query recent smoke test workflow runs

**Implementation Steps**:

Step 1: Read all affected workflow files
Step 2: For each workflow, identify the parent workflows it monitors
Step 3: Implement the fix using either post steps or scheduled checks
Step 4: Test changes by compiling with: gh aw compile --zizmor
Step 5: Verify no dangerous-triggers findings remain

**Expected Outcome**:
- Zero dangerous-triggers findings in zizmor scan
- All dependent workflows still function correctly
- Improved security posture with reduced attack surface

---

Historical Context

This is the first comprehensive zizmor security scan of the repository. Scan data has been stored in cache memory for future trend analysis:

• Scan Data: /tmp/gh-aw/cache-memory/security-scans/2025-11-02.json
• Vulnerability Database: /tmp/gh-aw/cache-memory/vulnerabilities/by-type.json
• Trends: /tmp/gh-aw/cache-memory/vulnerabilities/trends.json
• Fix Templates: /tmp/gh-aw/cache-memory/fix-templates/dangerous-triggers.md

Future scans will compare against this baseline to track:

• New vulnerabilities introduced
• Issues resolved
• Overall security posture trends

---

Recommendations

Immediate Actions (Priority 1)

1. Fix dangerous-triggers vulnerabilities in ci-doctor, dev-hawk, and smoke-detector workflows
   • Use the provided Copilot agent prompt or fix template
   • Test fixes with gh aw compile --zizmor
   • Verify workflows still function as intended

Short-term Actions (Priority 2)

2. Review template-injection warnings in auto-generated code

   • Verify the step names don't contain user-controlled input
   • Consider if compiler can be updated to avoid these warnings

3. Add missing permissions to workflows that need them

   • python-data-charts.md
   • test-secret-masking.md
   • Follow principle of least privilege

Long-term Actions (Priority 3)

4. Establish automated security scanning

   • Continue running zizmor-security-analyzer daily
   • Set up alerts for new High/Critical findings
   • Track security metrics over time

5. Update workflow templates and guidelines

   • Document secure trigger patterns
   • Avoid workflow_run in new workflows
   • Include security review in workflow creation process

6. Consider adding zizmor to CI/CD

   • Run zizmor check on pull requests that modify workflows
   • Prevent merge if High/Critical issues are introduced

---

Success Metrics

Track these metrics to measure security improvement:

Metric	Current	Target
High Severity Issues	3	0
Total Security Findings	18	< 5
Workflows with Issues	9	< 3
Clean Workflow Rate	86.6%	> 95%

---

Next Steps

• Review this security report with the team
• Prioritize fixing the 3 dangerous-triggers vulnerabilities
• Apply suggested fixes using the provided prompt template
• Re-run zizmor scan to verify fixes
• Update workflow creation guidelines
• Schedule next security scan

---

Scan Metadata:

• Date: November 2, 2025
• Scanner: zizmor (via gh-aw compile --zizmor)
• Repository: githubnext/gh-aw
• Total Workflows: 67
• Analysis Tool: Claude (Zizmor Security Analyzer Agent)

AI generated by Zizmor Workflow Security Analyzer

[pelikhan]

/q update the 3 agentic workflows with missing permissions (only add read permissions). See discussion.

[github-actions[bot]]

Agentic Q triggered by this discussion comment.

[github-actions[bot]]

This discussion was automatically closed because it was created by an agentic workflow more than 1 week ago.