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)
- Dominant language
- TypeScript
- Stars
- 143
- Forks
- 46
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 20
Description
## 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).
Contributor guide
Research direction
Start with mise.toml, then inspect the jdx/mise-action references in security.yml, security-pr.yml, build.yml, and the other workflows, plus .github/dependabot.yml. Check the existing version pins and release-age reasoning, reconcile scope with issue #329, and establish a green mise run security baseline. Done means exact scanner and action versions are consistent, Dependabot coverage is understood or fixed, and consecutive security runs match.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, devops, tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100