feat(ci): scan container image + SAST on PRs — weekly-only cadence let a HIGH CVE sit on main for 6 days

[theagenticguy]

Problem

The container-image and SAST scanners (trivy image, grype, semgrep) run only in the weekly security.yml workflow (schedule: cron "0 12 * * 1", Monday 12:00 UTC). PR builds in build.yml explicitly disable them:

# .github/workflows/build.yml:59
MISE_DISABLE_TOOLS: "aqua:aquasecurity/trivy,grype,semgrep"

So a HIGH/CRITICAL vulnerability introduced or newly-disclosed against the agent container is invisible to PR review and can sit on main for up to 7 days until the next scheduled scan.

This is not hypothetical — it just happened:

• CVE-2026-48501 (HIGH, GHSA-8xvp-7hj6-mcj9) was disclosed against github.com/cli/cli/v2; fix landed in gh v2.93.0 on 2026-05-27.
• The agent image pins ARG GH_VERSION=2.92.0 (agent/Dockerfile:2) and builds gh from source, so trivy flagged it.
• The weekly run on 2026-06-01 went red, auto-filed issue Security suite failed (main @ 4b77329) #226, and main's security suite stayed failing from 2026-05-26 through 2026-06-01 (3 consecutive failing scheduled runs).
• The CVE itself is being fixed by PR fix(security): fix gh issue #234 (bump to 2.93.0) — this issue is about the detection-latency gap, not the CVE.

The auto-filed #226 is a raw log dump with no triage, and security.yml has issues: write but no dedup, so every weekly failure opens a fresh near-duplicate issue.

Why it matters

• A reference sample for autonomous coding agents that builds and runs untrusted-ish workloads should detect image CVEs at PR time, not up to a week later.
• The fast PR scanners (gitleaks, osv-scanner) already run on PRs; the gap is specifically the heavier image/SAST scanners that were disabled for build-time/cost reasons.

Proposed approach

Add a dedicated, non-blocking-to-fast-feedback security job that runs the image + SAST scanners on PRs and on push-to-main, separate from the existing fast build job so it doesn't slow the inner loop. Options (pick one in discussion):

1. PR-triggered security job (preferred): a new job in security.yml (or a security-pr.yml) gated on pull_request + push: [main] that runs mise //agent:security:image, grype, and semgrep against the just-built image artifact. Reuse the image already built by build.yml via artifact handoff to avoid a second image build.
2. Re-enable selectively in build.yml: drop trivy/grype/semgrep from MISE_DISABLE_TOOLS but move them to a parallel matrix leg with continue-on-error: false and required status check, so fast lint/test feedback isn't blocked on DB downloads.
3. Keep weekly full scan, but add a lightweight PR-time trivy image --severity HIGH,CRITICAL --exit-code 1 on the built image as a required check.

Also (small, independent): make security.yml's "open issue on failure" step idempotent — search for an existing open Security suite failed issue and comment/update instead of opening a new one each week.

Acceptance criteria

• A HIGH/CRITICAL image CVE (e.g. an intentionally pinned old gh) causes a PR check to fail, not just the weekly scheduled run.
• PR-time security scanning does not add more than ~2–3 min to the critical path (run in parallel; reuse the built image artifact; cache trivy/grype DBs).
• Push-to-main runs the same image/SAST scan so regressions merged via admin override are caught immediately.
• security.yml failure-issue creation is deduplicated: at most one open Security suite failed issue at a time; subsequent failures comment on it.
• Docs (docs/guides/ security/CI section) note the PR-time vs. weekly scanning split and the rationale.

References

• agent/Dockerfile:2 — ARG GH_VERSION pin
• .github/workflows/build.yml:59 — MISE_DISABLE_TOOLS
• .github/workflows/security.yml — weekly schedule + auto-issue step
• agent/mise.toml — security:image (trivy), security aggregate task
• PR fix(security): fix gh issue #234 — fixes the specific CVE (2.92.0 → 2.93.0)
• Issue Security suite failed (main @ 4b77329) #226 — the auto-filed weekly failure this draft generalizes
• Related but distinct: RFC RFC: Automated toolchain version monitoring and upgrade workflow #104 (automated toolchain version monitoring/upgrade) — proactive version bumps; this issue is about detection cadence.

---

Filed by Laith Al-Saadoon, drafted by Bonk (ABCA nightly review, 2026-06-02). The root-cause analysis — tracing #226's red status to the weekly-only scan cadence and the build.yml scanner disable — was done by Bonk; Laith reviewed and is filing it.

— Laith + Bonk 🛰️

[theagenticguy]

Update (2026-06-02): PR #234 merged, fixing the specific CVE (gh 2.92.0 → 2.93.0) and closing the auto-filed #226. This issue is unaffected — its scope is the detection-latency gap (image/SAST scanners running weekly-only instead of at PR time and on push-to-main), not the CVE itself. All acceptance criteria remain open.

One note: #234 did touch the security.yml "open issue on failure" step, but only to add --label bug — it did not add the dedup logic in AC #4 (at most one open "Security suite failed" issue; comment on it thereafter). That criterion is still outstanding.

— Laith + Bonk 🛰️