aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

chore(ci): pin scanner toolchain + mise + mise-action to exact versions across all surfaces (reproducible security suite)

Aperta
#722 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
ci-cd P2 security tooling
Lingua principale
TypeScript
Stelle
143
Fork
46
Merge medio
3g 10h
PR unite (30g)
24

Descrizione

## Problem

The security/lint scanner toolchain is pinned to floating `latest` in `mise.toml` `[tools]`, so a scanner release can silently change findings between runs. This makes the scheduled security suite **non-reproducible** and hard to triage — a run can go red with no repo change (e.g. #542's masking count and #593's failing subtask both shifted over time as tools moved).

Current unpinned tools (`mise.toml` `[tools]`):
```
prek = "latest"
gitleaks = "latest"
semgrep = "latest"
osv-scanner = "latest"
grype = "latest"
"aqua:zizmorcore/zizmor" = "latest"
```

## All surfaces are governed by `mise.toml` (good news)
CI installs these via `jdx/mise-action` (see `security.yml`, `security-pr.yml`, `build.yml`, etc.), so pinning in `mise.toml` propagates to **all three surfaces at once**: local dev, `mise run`, and CI. No per-workflow duplication to chase. (Exception: `build.yml` sets `MISE_DISABLE_TOOLS=aqua:aquasecurity/trivy,grype,semgrep` for that job — those simply aren't installed there; the pins still govern where they DO run.)

## Requirements

**1. Pin the 6 scanner tools to exact versions** in `mise.toml` `[tools]` (mirror how `knip` and the Cedar engines are already exact-pinned). Capture the currently-known-good versions, e.g. at time of writing: `semgrep 1.157.0`, `gitleaks 8.30.1`, `osv-scanner` (current), `grype` (current), `zizmor` (current), `prek` (current) — verify each against a green run before committing.

**2. Pin `mise` itself.** Today `mise.toml` only sets `min_version = "2026.2.6"` (a floor, not an exact version) — local and CI can drift to different mise releases. Decide and implement one of: (a) tighten to an exact `min_version` cadence, or (b) document the intended mise version and how it is bumped. Note the existing constraint context: `minimum_release_age` interplay called out in `mise.toml` (#320) and jdx/mise#10279 — preserve that reasoning.

**3. Bump `jdx/mise-action` — Dependabot appears to have MISSED this.** All workflows pin `jdx/mise-action@e6a8b39… # v4.2.0`, but **latest is v4.2.4** (2026-08-01). `.github/dependabot.yml` **does** cover `github-actions` (`package-ecosystem: "github-actions"`, `directory: "/"`), so this should have been flagged. As part of this issue: bump the action to v4.2.4 (by pinned SHA) across all workflows, AND investigate why Dependabot didn't open a PR (grouping? schedule? SHA-pin handling?) — fix the config gap so future action drift is caught automatically.

## Gotchas
- **Pin to versions from a KNOWN-GREEN run**, not just "current latest" — pinning to a version that itself surfaces new findings would trade non-reproducibility for a red pin. Coordinate with #542 (masking) and #721 (secrets scope): ideally pin *after* those land so the baseline is green, or pin to the exact versions that produced the last-green local run and let #542/#721 fix the findings.
- `semgrep` install ordering: `uv` must be on PATH before `semgrep` installs (see the existing comment in `mise.toml`). Preserve tool ordering/comments.
- Exact-pinning `prek` may interact with the `core.hooksPath` hook-manager conflict noted in CONTRIBUTING.md — verify `mise run hooks:install` still works after pinning.
- Bumping `mise-action` by SHA: update BOTH the SHA and the trailing `# v4.2.4` comment in every workflow (7 files); a mismatch is a lint/readability trap.

## Acceptance criteria
- No `= "latest"` remains for the 6 scanners in `mise.toml`; each is an exact version.
- `mise` version strategy is explicit (exact pin or documented bump path), preserving the `#320` release-age reasoning.
- All `jdx/mise-action` references are at the same pinned newer version (SHA + comment), and `.github/dependabot.yml` is confirmed/fixed to catch action updates going forward.
- `mise run security` reproduces the same findings on two consecutive runs (reproducibility check).
- Related toolchain-pinning issue **#329** ("single source of truth for prek↔CI — pin scanner toolchain") — reconcile scope: this issue may satisfy or fold into #329. Check and cross-link before implementing to avoid duplicate work.

## References
#329 (prek↔CI toolchain SoT — likely overlap, reconcile), #320 (mise release-age), #542/#721/#593 (the non-reproducibility symptoms), ADR-003 (governance).

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia da mise.toml, quindi esamina i riferimenti a jdx/mise-action in security.yml, security-pr.yml, build.yml e negli altri workflow, oltre a .github/dependabot.yml. Controlla i pin delle versioni esistenti e il ragionamento sull’anzianità delle release, riconcilia l’ambito con l’issue #329 e stabilisci una baseline verde per mise run security. Il lavoro è completato quando le versioni esatte dello scanner e dell’action sono coerenti, la copertura di Dependabot è compresa o corretta e le esecuzioni consecutive di security corrispondono.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
github-actions
Ambito
ci-cd, devops, tooling
Tipo di issue
Refactoring
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
48/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.