Use Alpine-based grafana/mcp-grafana image to clear container scan findings

[Copilot]

The daily container scan reported 26 CVEs (7 Critical) and 90 license violations for grafana/mcp-grafana. All of them originate from the Debian bookworm-slim base layer of the untagged (latest) image — the pinned digest sha256:5efeafd0… is already the newest latest, so re-pinning cannot fix anything.

Upstream publishes an Alpine variant (Dockerfile.alpine: alpine:3.23 + apk upgrade) with an identical entrypoint. The shared component now uses it, pinned to a release tag.

• shared/mcp/grafana.md — container: grafana/mcp-grafana:1.0.0-alpine, with a comment recording why the Debian variant is avoided.
• Container pins — .github/aw/actions-lock.json refreshed to grafana/mcp-grafana:1.0.0-alpine@sha256:b04c198d…, synced into pkg/actionpins/data/action_pins.json and pkg/workflow/data/action_pins.json. The unrelated gh-aw-node bump that --force-refresh-container-pins picked up was reverted to keep the diff scoped.
• Lock files — recompiled the three workflows importing the component.

 mcp-servers:
   grafana:
-    container: "grafana/mcp-grafana"
+    container: "grafana/mcp-grafana:1.0.0-alpine"

Grant, run with the repo .grant.yaml, drops from 90 to 12 denied packages — all standard Alpine base packages (busybox, apk-tools, musl-utils, ca-certificates, zlib); the entire Debian OS package set and its CVEs are gone. Those 12 remaining denials are the same base-package class other Alpine images in this repo produce and are left for a separate policy decision rather than widening the license allowlist here.

Grype could not be run locally (its vulnerability DB host is blocked by the sandbox firewall), so CVE counts for the new image should be confirmed by the next scheduled scan.

• Fixes [container-image-scan] Container findings for grafana/mcp-grafana #51712

[pelikhan]

@copilot fix agentic workflow to fix Grype could not be run locally (its vulnerability DB host is blocked by the sandbox firewall), so CVE counts for the new image should be confirmed by the next scheduled scan.

[Copilot]

Pull request overview

Switches the shared Grafana MCP component to the pinned Alpine image to reduce Debian-derived scan findings.

Changes:

• Uses grafana/mcp-grafana:1.0.0-alpine.
• Refreshes container pins and generated workflows.
• Adds release notes explaining the migration.

Show a summary per file

File	Description
.changeset/grafana-mcp-alpine-image.md	Documents the image migration.
.github/aw/actions-lock.json	Updates the canonical container pin.
.github/workflows/daily-token-consumption-report.lock.yml	Refreshes generated metadata.
.github/workflows/portfolio-analyst.lock.yml	Uses the pinned Alpine image.
.github/workflows/shared/mcp/grafana.md	Selects and documents the Alpine variant.
.github/workflows/smoke-otel-backends.lock.yml	Uses the pinned Alpine image.
pkg/actionpins/data/action_pins.json	Synchronizes embedded action-pin data.
pkg/workflow/data/action_pins.json	Synchronizes workflow pin data.

Review details

Tip

Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 8/8 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

@copilot fix agentic workflow to fix Grype could not be run locally (its vulnerability DB host is blocked by the sandbox firewall), so CVE counts for the new image should be confirmed by the next sche...

Looked into this and the blocked Grype run turned out to be hiding a real bug rather than just a sandbox limitation.

grype exits with code 1 both when it finds vulnerabilities and when it can't load its vulnerability DB — and the failure case emits no JSON on stdout. grypeRunOnImage only treated exit 1 as a failure if a parse error had occurred, so empty stdout + exit 1 was cached as a valid, empty result. Reproduced locally: gh aw compile --grype reported 1 succeeded, 0 warnings for 9 images whose scans had all failed.

Fixed in f10ff0f:

• pkg/cli/grype.go — a scan now only counts when grype actually produced a report; failures surface grype's last stderr line (e.g. ERROR failed to load vulnerability db: database does not exist).
• .github/workflows/daily-squid-image-scan.md — the post-step gate now fails the run on (syft|grype|grant) scan failed for N image(s), and the agent prompt raises a Container scan operational failure issue instead of treating unscanned images as clean.
• Regression tests in pkg/cli/grype_test.go.

The scanners run on the bare runner before the AWF firewall is installed, so the workflow's network: allowlist doesn't apply to them — no allowlist widening was needed. I still can't run grype in this sandbox (the DB host is firewalled at the environment level), but the next scheduled scan will now fail loudly instead of silently reporting the Alpine image as clean.

[github-actions]

🎉 This pull request is included in a new release.

Release: v0.86.2