Feat/CVE report visibility

[bluvulture]

This pull request introduces a major redesign of the CVE report generation and rendering scripts for the release workflow. The changes replace the previous monolithic generate-cve-report.sh with a modular pipeline that aggregates, summarizes, and renders CVE data more efficiently and transparently. The redesign addresses scalability issues with large data sets, improves the usability and clarity of the generated reports, and introduces safeguards against exceeding GitHub's markdown size limits.

The most important changes are:

CVE Data Aggregation and Processing Pipeline

• Introduced .github/scripts/cve-aggregate.sh to stream-aggregate per-image Trivy scan results into a single, canonical JSON document keyed by CVE, package, and status, supporting large data sets without excessive memory use.
• Removed the old .github/scripts/generate-cve-report.sh script, which previously handled both aggregation and rendering in a single pass, in favor of the new modular pipeline.

Report Rendering and Presentation

• Added .github/scripts/cve-render-summary.sh to generate a concise, reader-focused markdown summary of the CVE findings, including hardening outcomes, severity breakdowns, variant/package impact, and image tables.
• Added .github/scripts/cve-render-table.sh to render detailed markdown tables for selected severity slices, excluding kernel-header CVEs and collapsing architectures for clarity and size efficiency.

Reliability and Transparency Improvements

• Added .github/scripts/cve-size-guard.sh to warn when a rendered report approaches GitHub's 512 KB markdown render limit, preventing silent failures and ensuring continued transparency.

Test Data

• Added fixture files for test coverage, including representative Trivy scan outputs and image metadata for the new pipeline. [1] [2] [3]

These changes collectively modernize the CVE reporting process, making it more maintainable, scalable, and user-friendly.

[Copilot]

Pull request overview

Redesigns CVE reporting into a scalable aggregation and rendering pipeline with split reports and size monitoring.

Changes:

• Adds canonical CVE aggregation and summary/detail renderers.
• Splits reports by severity and publishes machine-readable data.
• Expands regression fixtures and tests.

Reviewed changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
README.md	Documents the redesigned reports.
.github/workflows/release.yml	Integrates generation, publishing, and artifact handling.
.github/scripts/cve-aggregate.sh	Aggregates Trivy data.
.github/scripts/cve-render-summary.sh	Renders report summaries.
.github/scripts/cve-render-table.sh	Renders severity tables.
.github/scripts/cve-size-guard.sh	Warns near markdown limits.
.github/scripts/generate-cve-report.sh	Removes the legacy renderer.
.github/scripts/tests/run.sh	Tests the new pipeline.
v5.2-statusmix-a-amd64.*.json	Tests fixed-status aggregation.
v5.2-statusmix-b-amd64.*.json	Tests residual-status aggregation.
v5.2-kern-amd64.*.json	Tests kernel-header exclusion.
v5.2-arm64.*.json	Tests architecture collapsing.

Comments suppressed due to low confidence (1)

.github/scripts/cve-render-summary.sh:151

• The footnote repeats the incorrect CRITICAL/HIGH restriction. Copa's input report includes every severity and is restricted only to OS packages (scan-patch-gate.sh:43-56).

          + " measured across all severities and both OS and library packages, wider than the"
          + " CRITICAL/HIGH OS-package scope Copa patches._"

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (6)

.github/scripts/cve-aggregate.sh:130

• Grouping only by CVE/package/status merges findings from different releases even when their severity or installed/fixed versions differ, then publishes whichever .severity and .fix happened to sort first for every affected image. Preserve those fields in the key (or model them per affected image) so the canonical artifact and rendered status text do not misreport version-specific data.

    | ($r | group_by([.id, .pkg, .status])
          | map({ id: .[0].id, severity: .[0].severity, pkg: .[0].pkg,
                  status: .[0].status, fix: .[0].fix,
                  affects: (map(.i) | unique) })

.github/scripts/cve-render-summary.sh:151

• The footer repeats the incorrect CRITICAL/HIGH-only Copa scope. The pre-patch report passed to Copa includes fixable OS vulnerabilities at every severity; only library findings are outside that patch input.

          + " table is a kernel-header CVE -- see **Not tabulated** above. `Fixable` is also"
          + " measured across all severities and both OS and library packages, wider than the"
          + " CRITICAL/HIGH OS-package scope Copa patches._"

.github/scripts/cve-render-summary.sh:47

• This states that Copa patches only CRITICAL/HIGH packages, but the patch report in scan-patch-gate.sh:43-56 has no severity filter; GATE_SEVERITY is applied only by the post-patch scan at lines 67-98. Correcting this is important because the generated hardening report currently understates Copa's scope.

          "**\($fixable) fix-available findings** were seen across all images -- the `Fixable`"
          + " column of the Images table below, summed, so a CVE present in several images is"
          + " counted once per image. Copa patches only CRITICAL/HIGH OS packages, so this is an"
          + " upper bound on what could have been patched, not a count of `fixed` rows."

.github/scripts/cve-render-table.sh:36

• Trivy's VulnerabilityID can be a non-CVE identifier such as GHSA-*, especially because these scans include library packages. Sending every identifier to NVD therefore creates broken links; route known advisory namespaces appropriately and leave unknown identifiers as text.

                 | "| [\(.id)](https://nvd.nist.gov/vuln/detail/\(.id)) "

.github/scripts/cve-aggregate.sh:94

• The trailing || true suppresses every pipeline failure, including a failed append caused by a full disk, so aggregation can silently publish a partial CVE report. Filter blank rows without putting the write behind an unconditional success path.

    printf '%s\n' "$rows" | grep -v '^$' >> "${work}/rows.tsv" || true

.github/workflows/release.yml:611

• If aggregation fails, the shell redirection on line 552 still leaves an empty or partial cve-data.json; hashFiles only checks existence, and always() then uploads that invalid file as the canonical artifact. Validate it with jq/a success marker before upload, while still allowing a valid aggregate to be uploaded if only a later render or push operation fails.

                if: ${{ always() && hashFiles('cve-data.json') != '' }}

[Copilot]

Pull request overview

Copilot reviewed 27 out of 27 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

.github/scripts/cve-aggregate.sh:66

• unpublished means “not pushed,” not “not produced.” The workflow writes hardened_digest.txt only inside PUSH_HARDENED == true (release.yml:323-327), while scheduled/tag runs intentionally leave hardened publishing off but still create and scan the hardened image (release.yml:296-303, 364-367). Those normal runs therefore enter this branch despite having a hardened scan, discard its fixed/residual comparison, and report every plain finding as unpatched. Separate production from publication (use hardened-file presence for row processing, and track the unavailable registry digest independently), with a regression case where a hardened JSON exists and its digest is unpublished.

    if [ ! -f "$hardened" ] || [ "$hd" = "unpublished" ]; then
        state="not-produced"

.github/scripts/cve-aggregate.sh:106

• The || true suppresses every pipeline failure, not only grep's expected “no non-empty lines” status. If the temp filesystem fills or the append fails, aggregation continues with a truncated rows.tsv and silently under-reports findings. Check whether rows is empty before appending so genuine write failures remain fatal under set -e.

    printf '%s\n' "$rows" | grep -v '^$' >> "${work}/rows.tsv" || true

.github/workflows/release.yml:552

• Direct redirection creates cve-data.json before aggregation succeeds. On malformed input the script intentionally exits nonzero with no output, but the zero-byte file remains; the later always() && hashFiles('cve-data.json') step then uploads it as the canonical artifact. Write to a temporary file and rename only after successful aggregation so failures cannot publish invalid machine-readable data.

                    TS="$(date -u '+%Y-%m-%d %H:%M UTC')"
                    .github/scripts/cve-aggregate.sh _cvedata "$TS" > cve-data.json

.github/scripts/cve-render-summary.sh:46

• This zero-fix message attributes every finding to Debian even though the report explicitly includes library-package findings, whose fixes come from their own ecosystems. It can therefore make a false claim in the published security report. Describe the observed Trivy result instead, and limit the Copa conclusion to OS packages.

    , ( if $fixable == 0 then
          "**No fixable CVE was available upstream for any image in this run.** Debian ships no"
          + " fix for any of the \($tab | map(.id) | unique | length) distinct CVEs found, so Copa"
          + " had nothing to patch."

.github/scripts/cve-render-summary.sh:73

• The aggregate deliberately retains non-CVE identifiers such as Debian TEMP-* findings, and the table renderer explicitly supports them, so this calculation is a count of distinct finding IDs—not distinct CVEs. The same mislabel appears in the variant/package sections and can overstate the published CVE totals whenever Trivy emits an unassigned finding. Rename these counts consistently to “Distinct findings” (and adjust related prose/tests).

    , "| Severity | Distinct CVEs | Tabulated rows |"
    , "|----------|---------------|----------------|"
    , ( ["CRITICAL","HIGH","MEDIUM","LOW","UNKNOWN"]
        | map( . as $s
               | ($tab | map(select(.severity == $s))) as $rows
               | "| \($s) | \($rows | map(.id) | unique | length) | \($rows | length) |" )