[aw-maintenance:compiler-security] Compiler Security Scan: github/gh-aw-actions — zizmor strict-mode failure with 0 findings

Target `github/gh-aw-actions` compilation exited with code 1 due to a strict-mode zizmor check failure, but zizmor itself reported 0 security warnings/errors — this looks like a compiler/tooling anomaly rather than an actual vulnerability. Highest-severity supported finding: unknown/none (no concrete zizmor finding was emitted). Recommended next action: investigate the strict-mode gating logic and rerun zizmor directly to confirm no findings before treating this as a real security issue.

- **Target repository**: `github/gh-aw-actions`
- **Compiler exit code**: `1`
- **Workflow sources checked**: `1`
- **Generated lock files checked**: `1`
- **Result**: `findings`

### Findings

| Tool | Workflow/Image | Severity | Finding | Remediation |
|------|----------------|----------|---------|--------------|
| zizmor | `daily-runtime-threat-scan.lock.yml` | unknown | Compiler reported "zizmor failed" in strict mode with the message "zizmor found 0 security warnings/errors ... - workflows must have no zizmor findings in strict mode" — i.e. the gate tripped despite zero actual findings being listed. No concrete vulnerability detail was provided in `report.txt`. | Rerun `zizmor` directly against the lock file to confirm whether any findings exist; if none, investigate the gh-aw compiler's strict-mode pass/fail logic for a possible false-positive bug in how it interprets a zero-finding zizmor exit status. Do not assume a real vulnerability without corroborating output. |

Only actionlint/shellcheck/pyflakes ran to completion cleanly; no license, container-image, poutine, runner-guard, grant, grype, or syft findings were reported in the available evidence (`report.txt` ends after the zizmor step).

### Local fixing loop

1. Install or update the gh-aw extension, then configure the coding agent's MCP client to launch `gh aw mcp-server` over stdio from the target repository.
2. Give the agent the prompt below and require it to use the `fix` and `compile` MCP tools rather than editing generated `.lock.yml` files.
3. Require the agent to repeat the same full compiler validation and security scan until it passes, or stop and explain any finding that needs human action.

Agent prompt

Fix the reported gh-aw compiler and security findings in this repository. Change only `.github/workflows/*.md` sources and directly related files; never edit generated `.lock.yml` files. Use the gh-aw MCP server's `fix` and `compile` tools, rerunning compilation with strict validation, model checks, actionlint, shellcheck, yamllint, zizmor, poutine, runner-guard, grant, grype, and syft until clean. Review generated lock-file diffs, preserve existing behavior, and stop with a concise explanation if a finding cannot be fixed safely.

Raw compiler output

```
✓ .github/workflows/daily-runtime-threat-scan.md (99.2 KB)
i Using actionlint 1.7.12
i Running actionlint (with shellcheck/pyflakes) on .github/workflows/daily-runtime-threat-scan.lock.yml
i Running zizmor security scanner on .github/workflows/daily-runtime-threat-scan.lock.yml
✗ zizmor failed
strict mode: zizmor found 0 security warnings/errors in daily-runtime-threat-scan.lock.yml - workflows must have no zizmor findings in strict mode
```

Git status / diff stat (from local recompile)

```
M .github/workflows/daily-runtime-threat-scan.lock.yml
?? .github/aw/logs/

.github/workflows/daily-runtime-threat-scan.lock.yml | 630 +++++++++++++--------
1 file changed, 399 insertions(+), 231 deletions(-)
```

### Control Plane

- Correlation ID: `33803302299-27`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run URL: `https://github.com/githubnext/gh-aw-cao/actions/runs/33803302299`

> Generated by [:shield: AW Maintenance / Compiler Security](https://github.com/githubnext/gh-aw-cao/actions/runs/33803834259) · copilot · auto · 14.4 AIC · ⌖ 17.8 AIC · ⊞ 13.9K · [◷](https://github.com/search?q=repo%3Agithubnext%2Fgh-aw-cao+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fgh-aw-cao%2Faw-maintenance-compiler-security%22&type=issues)
> - [x] expires on Sep 17, 2026, 8:51 PM UTC

Start by rerunning zizmor directly against .github/workflows/daily-runtime-threat-scan.lock.yml to verify the reported zero findings. Then trace the compiler's strict-mode gating logic and confirm that a zero-finding scan passes without treating the generated lock file as the source; done means the same validation completes successfully without a false-positive failure.

Written by the indexing model from the issue text.