build(compliance): add vulnerability scanning at release time and vulnerabilities verification

[kaysavps]

• Run Grype on each release container image inside the existing "Generate SBOMs, upload to release and attest" step.
• Attest SARIF results as {image}-{arch}-vulnerability-report to the release attestation.
• Add vulnerability-management policy group (severity HIGH) to the release contract so scan results are evaluated at release time.

VEX is not used; the existing .vex files are empty and support can be added later if we add exception statements.

Please note that the github action itself have not been tested.

refs #2785

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/release.yaml">

<violation number="1" location=".github/workflows/release.yaml:158">
P1: Missing `--kind SARIF` on `chainloop attestation add` for the vulnerability report. Every other attestation-add in this workflow specifies `--kind`, and since Grype outputs SARIF format, the kind should be explicitly set to ensure proper material categorization and policy evaluation.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/release.yaml">

<violation number="1" location=".github/workflows/release.yaml:97">
P1: Security: Grype install script is fetched via a mutable tag (`v0.109.0`) instead of a pinned commit hash. Tags can be force-pushed, allowing the script content to change silently. This breaks the convention used by every other external reference in this workflow (Syft, actions/checkout, cosign-installer, goreleaser) which all pin to immutable commit SHAs. Pin the install script URL to the commit hash corresponding to `v0.109.0` to maintain supply chain integrity.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/release.yaml">

<violation number="1" location=".github/workflows/release.yaml:97">
P2: The version argument for the Grype binary was dropped. The Anchore install script defaults to `latest` when no version is specified, so the installed Grype version will float on every release run. Consider pinning a specific version (e.g., `sh -s -- -b /usr/local/bin v0.109.0`) to ensure reproducible vulnerability scans across releases.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}