[FEA]: Gate releases on vulnerability findings once the scan is quiet

[lockwobr]

Is this a new feature, an improvement, or a change to existing functionality?

Improvement, and the second half of #627.

Component

CI / release tooling

Problem description

#627 adds vulnerability scanning of the released images, but deliberately lands it report-only: the weekly workflow uploads findings and never fails, and no release is blocked.

That is the right starting state and the wrong end state. Report-only means nothing stops a release that carries an untriaged HIGH+ finding, so the scan informs without ever protecting. The reason it ships that way is empirical rather than philosophical: at the time #627 was written the released agent image carried 58 HIGH+ findings (#628) and the released operator image carried 2 (#629). Turning on a gate then would have blocked every release of both components on day one.

Feature description

Once #628 and #629 are resolved and the scan is quiet, turn on both gates agreed during #627's design:

1. Fresh scan at tag time. The same grype invocation with the same .grype.yaml and .openvex.json, but fail-build: true, on the refs/tags/operator/ and refs/tags/agent/ paths. Catches a CVE disclosed since the last weekly run.
2. Open-alert check at tag time. Fail the release if an open code scanning alert with tool_name of Grype exists. Catches a finding that was seen, could not be honestly suppressed, and has not been fixed, so that clearing it is an explicit human act rather than a side effect of scan timing.

They are deliberately separate. The first is about what is true right now; the second is about whether anybody dealt with what we already knew.

Describe your ideal solution

• Both gates land together, in one PR, after the scan has been quiet for at least one weekly cycle.
• docs/contributing/release-process.md gains a short section on what fails a release and how to clear it, since this is maintainer-visible behavior.
• The gate is a required check only on the tag paths, so ordinary PRs are unaffected.

Alternatives you have considered

• Gate on the fresh scan only. Simpler, and matches what AICR does today. Rejected during [FEA]: Scan released images for vulnerabilities and maintain an OpenVEX suppression document #627's design because a finding that was triaged and then ignored would never block anything.
• Gate on open alerts only. Avoids an overnight CVE blocking an unrelated release, but leaves a window between disclosure and the next weekly scan in which a release ships unexamined.
• Never gate. Rejected: the whole point of triage is that somebody has to act on it.

Additional context

Blocked on #628 and #629. Depends on #627 landing first.

Note for whoever picks this up: a finding on a released image can mean "already fixed on main, not yet shipped" rather than "unfixed" (#629 is exactly that case). A gate should not push people toward writing a VEX statement when the real remedy is cutting a release.

[lockwobr]

Constraint discovered while implementing #627, which this issue has to account for.

severity-cutoff does not filter grype's SARIF. It decides whether a result is emitted at SARIF error or warning/note level, and sets --fail-on, which is inert while fail-build is false. Measured against the current agent image, the uploaded report carries all 117 results with an available fix:

error:   58   (the HIGH+ set)
warning: 46
note:    13

Grype sets a security-severity property (CVSS, e.g. "8.1") on every rule, so code scanning grades these correctly rather than flattening them. That is why #627 uploads everything: the data is accurate and filterable, and dropping it at upload time would be irreversible.

The consequence for this issue: the open-alert gate described above must filter by severity. Phrased as "fail if an open code scanning alert with tool_name of Grype exists", it would block every release on a Low finding, which is far stricter than what was agreed during #627's design. The intended behavior is HIGH and CRITICAL only.

Concretely, the query needs a severity filter, along the lines of:

GET /repos/NVIDIA/nodewright/code-scanning/alerts?state=open&severity=critical
GET /repos/NVIDIA/nodewright/code-scanning/alerts?state=open&severity=high

filtered to tool.name == "Grype", rather than an unfiltered existence check.

Worth deciding explicitly when this is picked up: whether the gate should also ignore alerts whose only remedy is a release rather than a code change (#629 is that case), since blocking a release on a finding that the release itself fixes would deadlock.