Retire the VEX-superseded agent CVE exceptions and repair the rest - #511
Retire the VEX-superseded agent CVE exceptions and repair the rest#511ai-collaboration-app[bot] wants to merge 2 commits into
Conversation
The exception referred readers to #489, which tracks the OpenSSL CVE-2026-14456 row and is obsolete now that the 3.5.8 rebuild shipped, so anyone following it to re-verify this Python advisory would find nothing about it. #509 is the ticket that actually carries this row. Also record what the re-check actually established, so the next reviewer can confirm the no-backport claim without repeating the search. The expiry date is left alone deliberately: renewing or dropping a lapsed deferral is a disposition decision, not a correction.
|
Independent CVE review of
Verified as accurate in the PR body: #498 shipped OpenSSL 3.5.8 and those rows are absent from both active and ignored scanner output (including an independent arm64 scan); #489 is obsolete; #509 is the correct coordinating ticket. CI is green, no scope creep, no YAML comment issues. Suggested resolution: delete the expired, VEX-superseded exception file rather than re-point its tracker reference. A follow-up correction has been dispatched. Human review and merge remain mandatory. |
check-cve-exception-policy --as-of 2026-09-09 failed on all four files in exceptions/: every one expired on 2026-09-04, and three carried dispositions outside the supported set. Issue #500 made expiry fail closed, so the tree has to satisfy the checker. CVE-2025-15367 and CVE-2026-4360 are deleted because vexhub#39 merged reviewed statements that now cover them. In the 34330594840 Grype report for quay.io/stackstate/stackstate-k8s-agent:158e1098 both appear in ignoredMatches with appliedIgnoreRules namespace "vex" -- not_affected for CVE-2025-15367, fixed for CVE-2026-4360 -- against pkg:generic/python@3.13.15, the exact subcomponent the statements pin. The uncovered CVE-2026-17084 python row is still reported in the same run, so the suppression is the VEX statement rather than a scanner filter. The CVE-2025-15367 statement records re-verification on both published architectures, amd64 and arm64. The CVE-2026-4360 file said its own exit condition was a reviewed vexhub statement; that statement now exists. Both GO-2026-5932 files stay, because the advisory has no fixed version at all -- the range is "introduced: 0" with no fixed event -- so reachability is the only available disposition and something has to record it. Their status becomes not_affected, which the checker accepts and which is what the evidence supports: go list -deps over ./cmd/agent, ./cmd/installer and ./cmd/cluster-agent with the release build tag set contains no golang.org/x/crypto/openpgp package, while other x/crypto packages do appear, so the absence is real and not an empty list. Their claim that vexhub already carries an image-scoped statement was wrong and is corrected: vexhub carries GO-2026-5932 only for stackstate-k8s-process-agent and sts-opentelemetry-collector, and has no document for either agent image. The cluster-agent Grype report has no ignoredMatches at all, confirming no VEX reaches that image. A reviewed vexhub statement is the better home for both, and the renewed expiry is a short review deadline for that decision.
ai-collaboration-app
Bot
changed the title
|
Both findings accepted and applied on this branch, so the review history stays in one place. Head is now Finding 2, confirmed independently before deleting. Downloaded artifact Two things the review scoped narrower than they turned out to be.
Both While doing that I found a wrong claim in both files worth a maintainer's attention: they said vexhub already carried a reviewed image-scoped statement and the exception only bridged a scan-time identity gap. vexhub carries
|
|
arm64 confirmation, since a single-manifest check would not have settled this. Ran
This holds for the same structural reason on any manifest: the vexhub product identity is Same run also shows |
|
CI on The evaluator honours
That is the negative control for the repair: the status change restores real suppression rather than assuming it. Correction to my earlier comment. I said the VEX statements cover the scanned images, which is true of the published tags the gating cve-reporter scan reads, but I should have separated that from the in-repo scan. The in-repo scan targets
The gating scan is unaffected either way: |
1 participant
check-cve-exception-policy --as-of 2026-09-09failed on all four files inexceptions/: all expired 2026-09-04, three with dispositions outside the supported set. It now exits 0.stackstate-k8s-agent:158e1098they are inignoredMatcheswithappliedIgnoreRulesnamespacevex(not_affectedandfixed) againstpkg:generic/python@3.13.15. The uncoveredCVE-2026-17084python row is still reported in the same run, so VEX is doing the suppressing, not a filter.introduced: 0with no fixed event, so no x/crypto bump clears it and reachability is the only disposition. Status becomesnot_affected:go list -depsover./cmd/agent,./cmd/installerand./cmd/cluster-agentwith the release tag set has nogolang.org/x/crypto/openpgppackage, while other x/crypto packages do appear.Reviewer, one thing to decide: these two files claimed vexhub already carried an image-scoped statement. It does not — vexhub has GO-2026-5932 only for
stackstate-k8s-process-agentandsts-opentelemetry-collector, and no document at all forstackstate-k8s-cluster-agent. A reviewed vexhub statement is the better home for both; the 2026-09-23 expiry is the deadline for that call, not an acceptance.Supersedes the tracker-reference edit in the first commit, which the independent review asked to be replaced by deletion. Coordinating ticket: #509
Validation:
check-cve-exception-policy --as-of 2026-09-09 exceptions/exits 0; all filesyaml.safe_loadclean;exceptions/is read only by the twomode: informscan steps, so no gate behaviour changes.