🔍 Static Analysis Report - November 15, 2025

[github-actions[bot]]

🔍 Static Analysis Report - November 15, 2025

Executive Summary

Daily static analysis scan completed on 73 agentic workflow files using zizmor (security scanner) and actionlint (linting tool). The scan identified 4 total issues across 3 workflows, including 2 High severity security vulnerabilities and 1 syntax error requiring immediate attention.

Key Findings:

• 2 workflows use insecure workflow_run triggers (High severity)
• 1 workflow has a template injection risk (Low severity)
• 1 workflow has YAML syntax errors preventing compilation

Tools Status:

• ✅ zizmor v1.16.3: Successfully analyzed all workflows (3 findings)
• ✅ actionlint: Successfully analyzed all workflows (1 finding)
• ❌ poutine: Installation failed (binary not available)

Full Analysis Details

Findings by Tool and Severity

Zizmor Security Findings

Issue Type	Severity	Confidence	Count	Affected Workflows
dangerous-triggers	High	Medium	2	ci-doctor, dev-hawk
template-injection	Low	High	1	mcp-inspector

Actionlint Linting Findings

Issue Type	Severity	Count	Affected Workflows
syntax-check	Error	1	typist

Statistics Summary

• Total Workflows Scanned: 73
• Total Findings: 4
• By Severity:
  • Critical: 0
  • High: 2
  • Medium: 0
  • Low: 1
  • Errors: 1

Detailed Findings by Issue Type

1. Dangerous Triggers (workflow_run) - HIGH SEVERITY ⚠️

Issue: dangerous-triggers
Severity: High (Medium confidence)
Count: 2 occurrences
Affected Workflows: ci-doctor, dev-hawk
Reference: (redacted)#dangerous-triggers

Description:
The workflow_run trigger is flagged as "almost always used insecurely" because it runs in the context of the default branch (typically main), but receives information about the triggering workflow from a potentially untrusted branch.

Security Impact:

• Code Injection: Attackers could craft malicious data in pull request workflows that gets used by the workflow_run workflow
• Privilege Escalation: The workflow_run runs with elevated permissions compared to the triggering workflow
• Data Exfiltration: Sensitive data could be exposed through improper handling of workflow context

Affected Locations:

ci-doctor.lock.yml (lines 48-56):

"on":
  workflow_run:
    branches:
    - main
    types:
    - completed
    workflows:
    - Daily Perf Improver
    - Daily Test Coverage Improver

dev-hawk.lock.yml (lines 38-45):

"on":
  workflow_run:
    branches:
    - copilot/*
    types:
    - completed
    workflows:
    - Dev

---

2. Template Injection - LOW SEVERITY

Issue: template-injection
Severity: Low (High confidence)
Count: 1 occurrence
Affected Workflow: mcp-inspector
Reference: (redacted)#template-injection

Description:
Code injection via template expansion detected. The workflow uses ${{ env.SENTRY_HOST }} in a bash script context which could potentially be exploited if the environment variable contains attacker-controlled data.

Affected Location:

mcp-inspector.lock.yml (line 1381):
The issue occurs in the "Setup MCPs" step where ${{ env.SENTRY_HOST }} is expanded directly into a bash heredoc containing MCP server configuration. While this is likely low risk since SENTRY_HOST is defined in the workflow itself, it's flagged as a potential code injection vector.

Risk Level: Low - The environment variable appears to be controlled by the workflow definition, not external input.

---

3. YAML Syntax Error - ERROR

Issue: syntax-check
Severity: Error
Count: 1 occurrence
Affected Workflow: typist

Description:
The workflow file contains control characters that prevent it from being parsed as valid YAML.

Error Message:

typist.lock.yml:0:0: could not parse as YAML: control characters are not allowed

Impact: This workflow cannot be executed until the syntax error is fixed.

---

Fix Recommendations

Priority 1: Fix High Severity Issues (dangerous-triggers)

The dangerous-triggers finding requires immediate attention. Three remediation options:

Option 1: Use Artifact-Based Approach (Recommended)

• Store data in artifacts from triggering workflow
• Download and validate artifacts in workflow_run workflow
• Use read-only permissions where possible
• Never use github.event.workflow_run.* data directly in bash commands

Option 2: Eliminate workflow_run Trigger

• Refactor to use schedule trigger for periodic checks
• Use workflow_dispatch for manual triggers
• Use repository_dispatch for external triggers with validation

Option 3: Add Strict Validation

• Add explicit validation of all inputs from github.event.workflow_run.*
• Use minimal permissions
• Never expand untrusted data into bash commands
• Add conditional execution guards

Detailed fix template with code examples: /tmp/gh-aw/cache-memory/fix-templates/zizmor-dangerous-triggers.md

Priority 2: Fix Syntax Error (typist)

The typist workflow has a YAML syntax error due to control characters. Actions needed:

1. Open .github/workflows/typist.lock.yml
2. Identify and remove control characters (likely non-printable characters)
3. Recompile the workflow from the source .md file
4. Verify the workflow compiles without errors

Priority 3: Review Template Injection (mcp-inspector)

While low severity, the template injection finding should be reviewed:

1. Verify that env.SENTRY_HOST is only set from trusted sources
2. Consider using intermediate validation or sanitization
3. Document why this usage is safe if it's a false positive

---

Fix Suggestion: Dangerous Triggers (workflow_run)

Below is a ready-to-use prompt for a Copilot agent to fix the high-severity dangerous-triggers issue:

Copilot Agent Fix Prompt

You are fixing a HIGH severity security vulnerability identified by zizmor security scanner.

**Vulnerability**: dangerous-triggers (workflow_run trigger)
**Rule**: (redacted)#dangerous-triggers
**Severity**: High (Medium confidence)

**Current Issue**:
The workflows `ci-doctor` and `dev-hawk` use the `workflow_run` trigger, which is almost always used insecurely. The workflow_run trigger runs in the context of the default branch but receives information from potentially untrusted sources.

**Security Risks**:
1. The workflow runs with write permissions but processes data from untrusted pull requests
2. Potential for code injection via workflow context (github.event.workflow_run.*)
3. Privilege escalation from pull_request context to default branch context

**Required Fix**:

### Option 1: Use Artifact-Based Approach (Recommended)
If the workflow needs to process data from the triggering workflow:

1. In the triggering workflow (e.g., "Daily Perf Improver"):
   - Store any needed data in artifacts
   - DO NOT pass sensitive data via artifacts

2. In the workflow_run workflow:
   - Download the artifact
   - Validate ALL data from the artifact before use
   - Use read-only permissions where possible
   - Never use `github.event.workflow_run.*` data directly in bash commands

### Option 2: Eliminate workflow_run Trigger
If possible, refactor to avoid workflow_run entirely:
- Use `schedule` trigger for periodic checks
- Use `workflow_dispatch` for manual triggers
- Use `repository_dispatch` for external triggers with validation

### Option 3: Add Strict Validation
If workflow_run must be used:
- Add explicit validation of all inputs from `github.event.workflow_run.*`
- Use minimal permissions
- Never expand untrusted data into bash commands
- Consider using `jobs.(job_id).if` conditions to restrict execution

**Example Fix for ci-doctor.md**:

Before (Vulnerable):
```yaml
on:
  workflow_run:
    workflows:
      - Daily Perf Improver
      - Daily Test Coverage Improver
    types: [completed]
    branches: [main]

After (Option 1 - Safer with validation):

on:
  workflow_run:
    workflows:
      - Daily Perf Improver
      - Daily Test Coverage Improver
    types: [completed]
    branches: [main]

permissions:
  contents: read  # Read-only by default
  actions: read   # Only if needed to read workflow info

jobs:
  analyze:
    runs-on: ubuntu-latest
    if: github.event.workflow_run.conclusion == 'failure' || github.event.workflow_run.conclusion == 'success'
    steps:
      - name: Validate workflow run
        run: |
          # Validate the workflow_run data
          echo "Workflow: ${{ github.event.workflow_run.name }}"
          echo "Conclusion: ${{ github.event.workflow_run.conclusion }}"
          
          # Never use workflow_run data directly in commands
          # Store in validated environment variable
          if [[ "${{ github.event.workflow_run.conclusion }}" =~ ^(success|failure)$ ]]; then
            echo "VALIDATED_CONCLUSION=${{ github.event.workflow_run.conclusion }}" >> $GITHUB_ENV
          else
            echo "Invalid conclusion value"
            exit 1
          fi

After (Option 2 - Eliminate workflow_run, use schedule):

on:
  schedule:
    - cron: '0 */6 * * *'  # Run every 6 hours to check recent workflows
  workflow_dispatch:  # Allow manual triggers

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - name: Check recent workflow runs
        uses: actions/github-script@v7
        with:
          script: |
            // Use GitHub API to safely query workflow runs
            const { data: runs } = await github.rest.actions.listWorkflowRuns({
              owner: context.repo.owner,
              repo: context.repo.repo,
              workflow_id: 'perf-improver.yml',
              status: 'completed',
              per_page: 10
            });
            // Process runs safely with full validation

Action Items:
Please apply the appropriate fix to these workflows:

1. .github/workflows/ci-doctor.md
2. .github/workflows/dev-hawk.md

Choose the fix option that best fits each workflow's purpose. Document your choice and reasoning in the commit message.

---

## Historical Trends

**Note**: This is the first static analysis scan recorded in cache memory. Future scans will include trend analysis comparing findings over time.

**Baseline established**: November 15, 2025
- Total findings: 4
- High severity: 2
- Workflows with issues: 3 out of 73 (4.1%)

---

## Recommendations

### Immediate Actions (Within 24 hours)
1. **Fix HIGH severity dangerous-triggers issues** in `ci-doctor` and `dev-hawk` workflows
2. **Fix syntax error** in `typist` workflow to restore functionality
3. **Review template injection** in `mcp-inspector` workflow

### Short-term Actions (Within 1 week)
1. Install and integrate **poutine** for supply chain security analysis
2. Establish workflow creation guidelines to prevent dangerous-triggers pattern
3. Add pre-commit hooks to catch syntax errors before commit

### Long-term Actions (Within 1 month)
1. **Automate static analysis** in CI/CD pipeline
2. **Create workflow security templates** with pre-validated patterns
3. **Implement workflow review process** for security-sensitive changes
4. **Train team** on GitHub Actions security best practices
5. Consider adopting **OpenSSF Scorecard** for comprehensive security assessment

---

## Tool Notes

### Zizmor
- Successfully scanned all 73 workflows
- Identified 3 security findings across 2 issue types
- One warning about control characters in input parsing (did not affect results)

### Actionlint
- Successfully scanned all 73 workflows
- Identified 1 syntax error preventing workflow compilation
- All other workflows passed linting checks

### Poutine
- Installation failed during this scan
- Binary download unsuccessful (exit code 8)
- Will retry installation in next scan
- Consider alternative installation methods (e.g., from GitHub releases)

---

## Scan Metadata

- **Scan Date**: November 15, 2025
- **Tools**: zizmor v1.16.3, actionlint
- **Workflows Scanned**: 73
- **Scan Duration**: ~2 minutes
- **Results Cached**: `/tmp/gh-aw/cache-memory/security-scans/2025-11-15.json`

</details>

## Next Steps

- [ ] Apply fixes for dangerous-triggers in `ci-doctor` and `dev-hawk` workflows
- [ ] Fix YAML syntax error in `typist` workflow
- [ ] Review and document template injection in `mcp-inspector` workflow
- [ ] Install poutine for next scan
- [ ] Update workflow creation guidelines with security best practices
- [ ] Schedule next static analysis scan


> AI generated by [Static Analysis Report](https://github.com/githubnext/gh-aw/actions/runs/19387483562)

[github-actions[bot]]

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