release_charts: Trivy CVE diff + send fixed_cves payload to changelog bot

[ashwinamardeep-ashwin]

Requested by: ashwinamardeep-ashwin

Companion PR: helm-changelog-bot#28. Both should land together; the bot side is backwards-compatible so order does not matter for safety.

Summary

At release time, scan `docker.io/langchain/langsmith-backend` at the previous and new `appVersion` tags, compute the set difference of HIGH+CRITICAL CVEs (before − after), and post that delta as JSON to the changelog bot's `/trigger`. The bot renders a per-version `## Security` block from the payload (or falls back to regex over release notes if no payload).

New steps inserted after `Run chart-releaser`, before `Trigger self-hosted changelog bot`:

1. Determine appVersions — `awk` on `charts/langsmith/Chart.yaml` (current + `HEAD~1`); skips the diff when prev == new or either is missing. `fetch-depth: 0` is already set on checkout.
2. Scan previous image — `aquasecurity/trivy-action@0.28.0`, `severity: HIGH,CRITICAL`, `continue-on-error: true`. No docker login needed (image is public on Docker Hub).
3. Scan new image — same.
4. Compute fixed CVEs — inline `python3` parses Trivy JSON, set-diffs by `VulnerabilityID`, writes `fixed_cves.json` as `[{id, severity, package}]`.
5. Trigger — builds payload via `jq -n --slurpfile`, posts with `--data-binary @file`. Existing curl, headers, and `X-Api-Key` auth are unchanged.

Workflow_dispatch

Adds `dry_run_cve_diff: boolean` input. When `true`, the diff still runs and is logged, but the payload sent to the bot is `{}` — useful for end-to-end testing on a stable branch without affecting customer-facing changelog output.

Why scoped to one image for v1

The chart references 7+ service images (`langsmith-backend`, `langsmith-go-backend`, `langsmith-frontend`, `langsmith-playground`, `langsmith-ace-backend`, `langsmith-clio`, `hosted-langserve-backend`). Scanning all of them is straightforward to add as a matrix once this lands and we have signal that the rendered output looks right. Starting with backend keeps the failure surface small and the diff easy to validate.

Failure modes handled

• Image tag missing in registry → Trivy errors, `continue-on-error` keeps pipeline alive, diff produces `[]`, bot receives `{}`, falls back to regex.
• `Chart.yaml` unchanged this push → `prev == new`, all four scan/diff steps are skipped, bot receives `{}` (today's behaviour).
• Bot URL/secret unchanged. No new secrets introduced.

Test plan

• Run via `workflow_dispatch` with `dry_run_cve_diff=true` on a `*-stable` branch (or a throwaway branch); confirm Trivy scans run, diff is logged, bot receives `{}`.
• Run via `workflow_dispatch` with `dry_run_cve_diff=false` on a branch where the previous appVersion has known fixed CVEs vs the new one; confirm bot receives a non-empty `fixed_cves_by_app_version` and renders `## Security` with severity + package.
• Confirm a normal push that does not bump `appVersion` skips the scans and triggers the bot identically to today.
• Confirm a push with a non-existent image tag (e.g. `appVersion` typo) does not fail the workflow — Trivy errors, payload becomes `{}`, bot falls back to regex.