githubnext / githubnext/gh-aw-cao
[aw-maintenance:compiler-security] gh-aw-actions: zizmor strict-mode failure with 0 reported findings (daily-runtime-threat-scan)
- Dominant language
- JavaScript
- Stars
- 3
- Forks
- 1
- Avg merge
- 49m
- Merged PRs (30d)
- 837
Description
Compilation of `github/gh-aw-actions` failed under strict validation. This appears to be a compiler/scanner anomaly (zizmor strict mode reports failure while stating 0 findings) rather than an actual vulnerability — recommend investigating the strict-mode gate logic and re-running scan after a `.lock.yml` refresh.
- **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 (strict mode) | `.github/workflows/daily-runtime-threat-scan.lock.yml` | unknown | Compiler reported: "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." Exit code 1 despite 0 findings, indicating the `.lock.yml` is stale/out of sync with its `.md` source (diff shows 399 insertions / 231 deletions) or a strict-mode gate defect. | Regenerate the lock file from the `.md` source with `gh aw compile` and re-run the full validation suite; if it still fails with 0 findings reported, treat as a compiler defect in the strict-mode gate and file upstream. |
Raw report.txt
```
✓ .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
```
Diff summary
```
.github/workflows/daily-runtime-threat-scan.lock.yml | 630 +++++++++++++--------
1 file changed, 399 insertions(+), 231 deletions(-)
```
git status:
```
M .github/workflows/daily-runtime-threat-scan.lock.yml
?? .github/aw/logs/
```
### 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.
### Control Plane
- Correlation ID: `33826939975-32`
- Central repository: `githubnext/gh-aw-cao`
- Control plane run URL: https://github.com/githubnext/gh-aw-cao/actions/runs/33826939975
> Generated by [:shield: AW Maintenance / Compiler Security](https://github.com/githubnext/gh-aw-cao/actions/runs/33827325647) · copilot · auto · 17.6 AIC · ⌖ 9.3 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 18, 2026, 1:56 AM UTC
Contributor guide
Research direction
Start with .github/workflows/daily-runtime-threat-scan.md and its generated .lock.yml, then run gh aw compile with strict validation and review the reported zizmor result. Compare the regenerated lock file with the current diff and rerun the full validation suite. Done means the lock file is synchronized and validation passes, or the zero-findings strict-mode failure is reproducibly documented as a compiler defect.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- build-system, ci-cd, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100