[stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509

Activity

1. ai-collaboration-app commented on Sep 6, 2026

   

   ai-collaboration-appbot

   on Sep 6, 2026

   Last edited by ai-collaboration-app

   Author

   More actions

   Checkpoint — code candidate open

   Pull request	#510
   Branch	cve-xcrypto-0.56.0-grpc-1.83.1
   Head	c22f7cbdd624db32f91d92b599db38b9b42f0534
   Scan run	34027081656 (attempt 1, source 7c83f371)
   Status	partial — fixable subset delivered, nine no-adoptable-fix rows plus one fixed-but-misreported row deferred
   CI	terminal green at this head — 25 checks pass, 17 skipped, 0 failed
   Accepted head	c22f7cbdd624db32f91d92b599db38b9b42f0534 (reviewed clean, round 3)
   Review audits	round 2 — findings · round 3 — clean

   Three signed commits: b96bbeac bumps the root module, 56675787 corrects one exception record, and
   c22f7cbd fixes a date error that review caught in that correction.

   Round 2 review findings — both accepted and addressed. Review was right on both counts, and the second
   one improved the evidence rather than just the wording:

   1. CVE-2026-4360 was miscounted among "ten no-fix rows". It is fixed in the shipped interpreter, so the
      accurate split is nine with no adoptable fix plus one fixed-but-scanner-misreported. Corrected in
      this checkpoint, in the ticket body and in the Bump x/crypto to 0.56.0 and grpc to 1.83.1 for three HIGH CVE rows #510 description. This mattered — the old wording
      contradicted the very correction the second commit had made.
   2. The exception file said "16 years"; Python 3.1.5 is dated 2012. Correct — the gap is roughly fourteen
      years, not sixteen. Fixed in c22f7cbd, which also replaces the vaguer "obvious data-entry artifact"
      claim with the traceable cause: the PSF advisory's first listed fix commit,
      python/cpython@c37a4fdf, is the 2012-04-06 "bump to 3.1.5 final" release commit that the lightweight
      v3.1.5 tag points at, so a deriver resolving it to its nearest tag yields "fixed in 3.1.5" — exactly
      the < 3.1.5 CPE range NVD carries.

   Delivered

   Three HIGH rows fixed at the root module, which is where every shipped binary comes from:

   • CVE-2026-56855 (GO-2026-6355) and CVE-2026-78662 (GO-2026-6354) — golang.org/x/crypto v0.55.0 → v0.56.0
   • CVE-2026-84304 (GHSA-vp52-pcj8-j9qc) — google.golang.org/grpc v1.82.1 → v1.83.1

   Evidence

   • Fix versions read from upstream advisories, not scanner leads: both x/crypto CVEs are golang.org/x/crypto/ssh deadlock DoS bugs with fixed: 0.56.0; the grpc CVE is HTTP/2 DATA-frame heap exhaustion, vulnerable <= 1.83.0, first patched 1.83.1.
   • go version -m on binaries built for both published architectures — installer amd64, installer arm64, cluster-agent amd64 — all report x/crypto v0.56.0 and grpc v1.83.1, with zero occurrences of v0.55.0 or v1.82.1 in the embedded module graphs. go.sum no longer carries x/crypto v0.55.0.
   • All 186 workspace modules tidy clean (go get → go work sync → go mod tidy), reproducing CI's check-mod-tidy.
   • go list -deps shows the cluster-agent links neither x/crypto/ssh nor x/crypto/openpgp, matching the scan attributing x/crypto rows to the agent image only.
   • Dependabot verification: Bump google.golang.org/grpc from 1.80.0 to 1.83.2 in /comp/otelcol/otlp/components/statsprocessor #503 (statsprocessor) is absent from go.work and not required by the root go.mod, so it reaches no shipped binary and does not substitute for this bump; Bump google.golang.org/grpc from 1.82.1 to 1.83.1 in /test/e2e-framework #504 (test/e2e-framework) is test-only and is subsumed by go work sync. Bump github.com/apache/thrift from 0.22.0 to 0.24.0 in /comp/otelcol/collector-contrib/impl #505/Bump github.com/apache/thrift from 0.22.0 to 0.24.0 #506 (thrift) belong to no stackstate-agent row this cycle.
   • Exception schema: all four files validate against image-pipeline/schemas/exception.schema.json.

   CI reached a terminal state

   All three required workflows completed successfully at 56675787 — the head this section describes — so the per-architecture shipped
   artifacts are now verified by CI rather than only by the local approximation below:

   Workflow	Result
   Lint and unit tests	success — includes Go module tidiness (go.mod / go.sum)
   Binary builds	success — agent and cluster-agent, amd64 and arm64
   DEB package build	success — omnibus, amd64 and arm64, plus branding verification

   Go module tidiness passing is the check that matters most for this change: it re-runs go work sync
   and go mod tidy per module and fails on any diff, independently confirming the 186-module tidy result.
   The agent binary builds passing on both architectures also retires a local-only compile error seen
   during verification — that came from an ad-hoc build-tag combination, not from this change, which
   touches no Go source (26 go.mod, 25 go.sum, 3 YAML).

   No review comments and no requested changes on #510 as of this checkpoint.

   Scanner-verified, not just version-verified

   The cluster-agent image was rebuilt locally from the bumped binary against the real bci-micro base and rescanned with all three required scanners. CVE-2026-84304 is gone:

   Scan	Result
   Trivy vuln, image, UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL	only GO-2026-5932 (x/crypto v0.56.0, UNKNOWN)
   Trivy secret, image, all severities	no secrets found
   Grype, image	no matches
   Trivy vuln, cluster-agent binary directly	only GO-2026-5932
   Grype, cluster-agent binary directly	no matches

   The single remaining row is the no-fix openpgp advisory whose exception was deliberately kept — exactly the expected residue, and confirmation that dropping those two files would have turned it unmanaged.

   The local run had a real scope limit — a placeholder config, and the agent image could not be built
   locally at all because it needs the full omnibus DEB. CI has now closed that gap. All four published
   image variants were rebuilt and rescanned at 56675787 by the report-only scan-image action
   (Trivy vuln + Grype, VEX-aware, plus a separate Trivy secret scan at UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL):

   Image variant	Trivy vuln	In-scope	Suppressed	Expired	Unmanaged
   agent amd64	1 UNKNOWN, 0 HIGH	7	0	3	4
   agent arm64	1 UNKNOWN, 0 HIGH	7	0	3	4
   cluster-agent amd64	1 UNKNOWN, 0 HIGH	1	0	1	0
   cluster-agent arm64	1 UNKNOWN, 0 HIGH	1	0	1	0

   • All three target CVEs are absent from every variant — zero occurrences of CVE-2026-56855,
     CVE-2026-78662 or CVE-2026-84304 in any of the four scan logs, and zero HIGH rows anywhere.
   • Trivy secrets: No secrets detected in image. on every variant.
   • The single UNKNOWN row on each is GO-2026-5932 against x/crypto v0.56.0 — the no-fix openpgp
     advisory whose exception was deliberately kept. It correctly reports at the new version, confirming
     the purl update tracked the bump and that dropping those files would have turned the row unmanaged.

   One discrepancy to record rather than smooth over: no krb5 row appears in any of the four CI scans,
   though the chart scan surfaced four krb5 HIGHs on the published ff38da51 agent image. The likely reason
   is that this CI action is VEX-aware and vexhub carries krb5 statements (vexhub#34, vexhub#38), whereas the
   chart scan matches VEX by published image identity and so does not apply them to a freshly built commit
   image. That is inference, not proof — I did not verify vexhub's contents. It does not discharge the krb5
   obligation: the chart scan is the gating signal, it still reports those rows, and the human VEX-versus-
   exception decision stands.

   The expiry lapse is now CI-proven, not just inferred

   The agent scans report expired: 3 and the cluster-agent scans expired: 1 — all four exceptions/
   files, named explicitly in the log with expired 2026-09-04. This is direct confirmation that expiry
   evaluation is fail-closed (the evaluator classifies past-dated exceptions as Expired, not as
   suppressions — note suppressed by exception: 0 on every variant) and that in gate mode these would
   fail the build. They do not fail here only because this repository's own scan runs mode: inform, which
   returns 0 unconditionally. So nothing is silently lapsing in a gating sense, but nothing is protecting
   these rows either.

   Corrections made

   • GO-2026-5932 exception files kept for both images — introduced: 0, no fixed version in any release, so it survives the bump. Only the pinned purl moved to v0.56.0. Expiry untouched.
   • CVE-2026-4360 exception corrected: its claim of "no upstream fix in any release line" is false. python/cpython@eee3ddf0 is the 3.13 backport and eee3ddf0...v3.13.15 gives behind_by: 0, so the embedded 3.13.15 already carries the fix. Set to under_investigation; disposition left to the owner.

   Deferred — human decision, owner @StackVista/observability-team

   No VEX approved, no .trivyignore entry, no local suppression added.

   • krb5 1.21.3 — CVE-2026-40355, CVE-2026-40356 are true positives with no released fix: upstream committed it, but 1.22.3 is unreleased and 1.22.2 remains in range, so even a bump to latest would not clear them. CVE-2007-3149 and CVE-2007-5894 are versionless-CPE mismatches — the first is a sudo defect, the second vendor-disputed gssftp ftpd; neither is the shipped libkrb5.so.3.3. krb5 is embedded only to satisfy the msodbcsql18 ODBC driver (deps/repos.MODULE.bazel), and both 2026 CVEs need the acceptor side (gss_accept_sec_context()) plus a NegoEx entry in /etc/gss/mech, which is not provisioned anywhere in the repo. Not proven by symbol-level callgraph analysis.
   • python 3.13.15 — CVE-2025-15367, CVE-2026-15806, CVE-2026-17084, CVE-2026-19672, CVE-2026-15310 are fixed only in unreleased 3.15/3.16. Re-verified today: latest 3.13 tag is v3.13.15, no backports.

   Expiry lapse

   All four exceptions/ files carry expires: '2026-09-04' and are expired as of today. Fail-closed is live but lives in image-pipeline (evaluator/evaluate.go treats missing, unparseable or past dates as Expired; ExitCode fails gate mode on Expired > 0) — which is why #501 was closed unmerged rather than landing here. Nothing is silently lapsing in a gating sense, but this repo's own image scan runs mode: inform, which returns 0 unconditionally, so these dates gate nothing here.

   Finalization — CI and rescans now confirmed at this head

   The two CI obligations carried in the previous revision are discharged by observed evidence at
   c22f7cbd, not by inference from the earlier head:

   • All three required workflows concluded success: Lint and unit tests, Binary builds, DEB package
     build. 25 checks pass, 17 skipped, 0 failed, 0 pending. (The count differs from the earlier head's
     30/12 because publish-path jobs skip differently on this run, not because coverage shrank —
     Go module tidiness, all four binary builds and both DEB builds all pass.)
   • All four published image variants were rebuilt and rescanned at this head. Verified directly from the
     job logs rather than taken from the review: zero HIGH rows on every variant, zero occurrences of
     CVE-2026-56855, CVE-2026-78662 or CVE-2026-84304 in any scan log, and No secrets detected in image. everywhere. Agent variants report 7 in-scope / 0 suppressed / 3 expired / 4 unmanaged;
     cluster-agent variants 1 / 0 / 1 / 0. The single UNKNOWN per variant remains GO-2026-5932 against
     x/crypto v0.56.0 — the deliberately kept openpgp exception, still tracking the bump.
   • Expiry remains fail-closed at this head: the four lapsed files are classified Expired, never
     suppressed (suppressed by exception: 0 on every variant).

   Round 3 review returned clean with no findings. A clean review is not CVE closure.

   Remaining work

   1. Human review and merge of Bump x/crypto to 0.56.0 and grpc to 1.83.1 for three HIGH CVE rows #510 — still REVIEW_REQUIRED, mergeStateStatus BLOCKED, not merged.
   2. Human decision per package on the nine no-adoptable-fix rows: reviewed vexhub statement or scoped dated exception.
   3. Human decision on the four lapsed expiry dates, and on the CVE-2026-4360 disposition.
   4. Await the next complete dev chart scan confirming the three Go rows clear on republished images.
   5. Confirm why no krb5 row appears in CI's VEX-aware scans while the chart scan reports four — still inference, not verified against vexhub contents.
   6. Close dependabot Bump google.golang.org/grpc from 1.82.1 to 1.83.1 in /test/e2e-framework #504 as redundant once Bump x/crypto to 0.56.0 and grpc to 1.83.1 for three HIGH CVE rows #510 lands; Bump google.golang.org/grpc from 1.80.0 to 1.83.2 in /comp/otelcol/otlp/components/statsprocessor #503 stays independently valid for the out-of-graph statsprocessor module.
   7. Closing [stackstate-agent] CVE-2026-14456 (openssl 3.5.7) — no upstream fix published, needs a tracked exception #489 is a human call now that ff38da51 shipped the OpenSSL fix.

   Next action: review and merge #510, then @StackVista/observability-team takes the VEX-versus-exception decisions.

   This ticket stays open. A merged pull request is not closure evidence; closure needs a later complete dev scan showing every target for this repository clean.
2. ai-collaboration-app commented on Sep 6, 2026

   

   ai-collaboration-appbot

   on Sep 6, 2026

   Author

   More actions

   CVE review audit

   • Round: 2
   • Model: Codex (GPT-5)
   • Head: 56675787de6b7341f19583b676b715f81037fae4
   • Verdict: findings
   • Checks: exact checkout/base and verified commits; full 54-file diff; original scan jobs 101470061699/101470061724; four PR image-scan jobs; current PR feedback and 30-pass/12-skip CI; upstream Go/GitHub/CVE records; CPython ancestry; go mod verify; exception parsing; canonical ticket and Project 4 state.

   Actionable findings:

   1. Reconcile CVE-2026-4360 across the candidate receipt, [stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509, and PR text. It is not one of ten no-fix rows: the current CNA record fixes the 3.13 line in 3.13.15, eee3ddf0 is an ancestor of v3.13.15, and this branch embeds 3.13.15. Record nine no-adoptable-fix rows plus one fixed-but-scanner-misreported row; keep any human disposition decision scoped to handling that false positive.
   2. Correct the exception statement saying the advisory postdates Python 3.1.5 by 16 years. The official 3.1.5 artifacts are dated 2012-04-09, so the interval is about 14 years as of this review; use the exact date or nonnumeric wording.

   Optional suggestions: none.
3. ai-collaboration-app

   added a commit that references this issue on Sep 6, 2026

   Fix the CVE-2026-4360 date claim and name the real cause of the bad r…

   ...

   c22f7cb
4. ai-collaboration-app commented on Sep 6, 2026

   

   ai-collaboration-appbot

   on Sep 6, 2026

   Author

   More actions

   CVE review audit

   • Round: 3
   • Model: Codex (GPT-5)
   • Head: c22f7cbdd624db32f91d92b599db38b9b42f0534
   • Verdict: clean
   • Checks: exact checkout/base and three verified signed commits; full 54-file diff plus YAML-only round-2 correction; original scan jobs 101470061699/101470061724; current-head CI runs 34040570744, 34040570749, 34040570726 terminal success (25 passed, 17 skipped); image-scan jobs 101509107051, 101509107034, 101512425251, 101512425207 with zero HIGH rows, no target-CVE occurrences and no secrets; exception schema validation, go mod verify, CPython/OSV/NVD correction, PR feedback, ticket and Project 4 state.

   Actionable findings: none.

   Optional suggestion: refresh the checkpoint CI count from the prior-head 30 passed / 12 skipped to the current-head 25 passed / 17 skipped. The partial ticket remains open for review/merge, owner VEX-or-exception and expiry decisions, the krb5 scan discrepancy, Dependabot/#489 follow-up, and a later complete published-chart scan.
5. ai-collaboration-app commented on Sep 8, 2026

   

   ai-collaboration-appbot

   on Sep 8, 2026

   Author

   More actions

   Dev scan 34191503812 checkpoint — stackstate-agent

   Verified against the chart-scan-aggregate artifact of dev scan 34191503812 (source sha 3cd8097), which scanned quay.io/stackstate/stackstate-k8s-agent:158e1098, digest sha256:35e66696a1bdc0d470e0d11d7711e426548a09d31190bdd94cd1350b464dc839 — this repository's default-branch head 158e1098755d8ee4e563348ae0b861fa217a5c1b.

   No source patch this round. The agent image carries exactly four findings, all on the embedded CPython, and none of them has a shippable fix. What remains is a human disposition decision.

   Scope narrowed — but the two halves cleared by different mechanisms

   The OpenSSL and krb5 rows are both gone from the agent image. They did not clear the same way, and the difference decides what keeps each one clear:

   • OpenSSL — genuinely remediated. The openssl rows are absent from both Grype matches and ignoredMatches, so the vulnerable version is simply no longer present. The 3.5.8 rebuild from Bump embedded OpenSSL to 3.5.8 (CVE-2026-14456) #498 shipped: omnibus/config/software/openssl3.rb:34 and deps/openssl/version.bzl:1 both pin 3.5.8, and the CVE-2026-14456 exception was dropped in c251351. Nothing further needed here.
   • krb5 — suppressed, not fixed. krb5 is still installed at 1.21.3. CVE-2007-3149, CVE-2007-5894, CVE-2026-40355 and CVE-2026-40356 sit in Grype ignoredMatches with appliedIgnoreRules namespace vex, i.e. cleared by merged vexhub statements. That stays true only while those statements keep matching this image identity.

   stackstate-k8s-cluster-agent:158e1098 passed the gate. stackstate-k8s-agent:158e1098 is decision: failed, solely on the four Python rows.

   The four Python rows on embedded CPython 3.13.15

   3.13.15 is the newest released 3.13.x — tags v3.13.0 through v3.13.15, no v3.13.16 — so there is no bump target. Verified upstream, not taken from the scanner.

   CVE	Severity	Affected module	Fix status for the 3.13 line
   CVE-2026-15806	MEDIUM 6.0	urllib.request HTTPPasswordMgr* matched credentials without regard to URL scheme, so HTTPS-registered credentials can be sent over plain HTTP	A 3.13 backport exists but is not in our tag. a2773a34183b7d94a243bb98fd658926cc5348ce (2026-08-18); compare/a2773a34...v3.13.15 gives behind_by: 60 — our tag is an ancestor of the fix. Ships in an unreleased 3.13.16.
   CVE-2026-17084	MEDIUM 6.0	stringprep.map_table_b2/b3 and the idna codec use current Unicode instead of Unicode 3.2.0	No 3.13 backport. Expressed only as commits 1e54caa09667, 5181304bcec9, 7e109d084d55, all diverged from v3.13.15 and from the 3.13 branch head. OSV fix 3.15.0rc2 — a pre-release.
   CVE-2026-19672	MEDIUM 6.3	tarfile tar/data filters create empty directories outside the destination; member contents stay contained	No shippable fix in any line. CNA range is < 3.16.0, a version that does not exist. Not in OSV. Only reference is PR python/cpython#156000 — no commit SHAs published, so commit reachability could not be verified.
   CVE-2026-15310	LOW 2.1	zipfile bzip2/LZMA/Zstandard members decompress with no max_length bound, so a crafted archive drives memory exhaustion	No 3.13 backport. Commits 1b424c0178a0, 31980e84b9a7, f897dbf2f36a all diverged. Fix 3.15.0rc2 — a pre-release.

   Reachability in this repository. None of the four affected module paths is referenced by any Python that ships in the image. The only zipfile/tarfile callers live under tasks/ (invoke build and dev tooling), which Dockerfiles/agent/Dockerfile never COPYs into the image — they run under the developer/CI system interpreter, not /opt/stackstate-agent/embedded/bin/python3.13. The one Python helper that does ship, Dockerfiles/agent/secrets-helper/readsecret.py, imports only argparse, json, os.path and sys. There is no ZIP_BZIP2/ZIP_LZMA/ZIP_ZSTANDARD usage anywhere in the tree.

   Residual gap: the embedded interpreter also executes checks from StackVista/stackstate-agent-integrations, which is outside this checkout and was not assessed. Any not_affected argument has to cover that surface too.

   VEX versus dated exception — what the evidence shows

   This part is empirical rather than a matter of preference:

   A repo-local dated exception cannot clear the gating scan. CVE-2025-15367 and CVE-2026-4360 each already have an exception file in this repository, yet what actually cleared them from this gate was rules=vex in Grype ignoredMatches — merged vexhub statements. The gating chart scan does not read exceptions/ at all. The tree's only consumer here is .github/workflows/build-deb.yml:330 (exceptions-path: exceptions) running in mode: inform, which always exits 0.

   So, for the decision:

   • Only a reviewed vexhub statement will stop the daily dev scan failing on these four rows.
   • A repo-local exception records intent and feeds the report-only DEB scan. It is not a gate mechanism.
   • CVE-2026-15806 is not a VEX-on-no-fix case. Upstream already backported it to 3.13; it just missed our tag. The natural disposition is to bump the embedded interpreter when 3.13.16 releases, with a short dated review window until then.
   • The other three have no shippable fix in any released line and are the genuine VEX-versus-exception candidates.

   I am not approving VEX or writing an acceptance — that disposition is yours.

   All four exception files are lapsed, and nothing enforces them

   Every file in exceptions/ carries expires: '2026-09-04', four days past as of 2026-09-08:

   • exceptions/stackstate-k8s-agent/CVE-2025-15367.yaml
   • exceptions/stackstate-k8s-agent/CVE-2026-4360.yaml
   • exceptions/stackstate-k8s-agent/GO-2026-5932.yaml
   • exceptions/stackstate-k8s-cluster-agent/GO-2026-5932.yaml

   I have not renewed them. Renewing a lapsed deferral is a disposition call.

   #501 and #500 disagree, and that needs confirming. #500 is closed as completed, but #501 was closed without merging (mergeCommit: null) on 2026-09-02, eighteen seconds before #500 was closed. scripts/check_cve_exception_expiry.py is not present on stackstate-7.78.2, so the expiry dates remain advisory — precisely the gap #500 was filed to close.

   The code on cve-exception-expiry-fail-closed (c9414b9) does work. Running it here: against the live tree it exits 1 and names all four lapsed files; against a tree with a future date it exits 0; its own suite passes 10/10 under unittest, covering expired dates, missing dates, malformed YAML, non-mapping documents, ISO week dates, compact dates and invalid calendar dates. So if closing #501 was a deliberate change of direction, #500's rationale is stale. If it was accidental, the branch is ready to land. I have not reopened or re-pushed it either way.

   Separately, this correction is worth recording: an earlier automated note on #500 stated that #501 was open with green required checks and awaiting review. That is no longer true.

   Also verified

   • Independent Trivy 0.74.0 secret scan of the exact digest at all severities (CRITICAL,HIGH,MEDIUM,LOW,UNKNOWN): zero secret findings, corroborating the pipeline's own secrets report.
   • GO-2026-5932 does not appear for either agent image in this aggregate — it shows up only against a stackstate-backup-cli release asset, a different workstream.

   Remaining work

   1. Human decision on the four Python rows: reviewed vexhub not_affected statements versus short dated review-window exceptions, noting that only VEX affects the gate.
   2. Confirm the Fail CI when a CVE exception has passed its expires date #501/[stackstate-agent] Make CVE exception expiry dates fail closed #500 outcome. Was closing Fail CI when a CVE exception has passed its expires date #501 unmerged deliberate? The four lapsed exceptions currently have no enforcement.
   3. Decide the lapsed files' disposition — renew with a short dated window, or drop. Deliberately left untouched.
   4. CVE-2026-15806: bump embedded CPython to 3.13.16 once it is released. Nothing actionable until then.
   5. Fresh-scan verification stays open. A later complete dev scan has to show the agent target clean, or these rows formally managed. Today it is decision: failed.

   Consolidation

   This ticket is the canonical coordinator for the workstream: it is in the affected repository and it carries the marker lineage. cve-reporter#29 has no workstream marker in its body or comments, so I left it unmarked rather than duplicate this one. #489 is obsolete — its subject, the OpenSSL 3.5.7 exception, is remediated as described above — and should be closed against this ticket. No new ticket was created.

   Next action: decide VEX versus a short dated exception for the three no-fix Python rows, and confirm whether the #501 expiry guard should land.
6. ai-collaboration-app commented on Sep 8, 2026

   

   ai-collaboration-appbot

   on Sep 8, 2026

   Last edited by ai-collaboration-app

   Author

   More actions

   CVE review audit

   • Round: 1
   • Model: Codex (GPT-5)
   • Head: 158e1098755d8ee4e563348ae0b861fa217a5c1b
   • Verdict: findings

   Checks:

   • git rev-parse HEAD, git rev-parse origin/stackstate-7.78.2, the GitHub default-ref API, and git status --porcelain=v1 --untracked-files=all: exact head 158e1098755d8ee4e563348ae0b861fa217a5c1b; clean tree.
   • sha256sum chart-scan-aggregate.zip matched sha256:5a385f5415475ccd20f97b8dc23014bb8ab587aeef2523aba7519d485a0d44df; run https://github.com/StackVista/cve-reporter/actions/runs/34191503812 completed, with the agent failing on exactly four Python 3.13.15 rows, the cluster-agent passing, and zero secret findings.
   • jq on the exact per-image Grype evidence: four live Python rows; krb5 1.21.3 rows are ignored only by namespace=vex; OpenSSL is absent from both matches and ignoredMatches.
   • skopeo inspect found amd64 and arm64 manifests for both published tags at OCI revision 158e1098755d8ee4e563348ae0b861fa217a5c1b; arm64 syft/grype on manifest sha256:0a1225b2921e7fc4e5cd04c6afbfccb641a82223e33dc9cd1c2484eea6e7561f found Python 3.13.15 with the same four target rows, OpenSSL 3.5.8, and krb5 1.21.3.
   • GitHub CPython tag/compare APIs: v3.13.15 remains latest; a2773a34183b7d94a243bb98fd658926cc5348ce is 60 commits after the tag, and CVE-2026-19672 backport c7979f3a819011a3222bd16e671264b1e34282cb is on 3.13 and 69 commits after the tag; CVE-2026-17084/CVE-2026-15310 fix commits diverge from the tag and branch.
   • check-cve-exception-policy --as-of 2026-09-08 over all four exception files exited 1: four expired files plus three unsupported dispositions; the 2027-01-01 variant also exited 1 because 115-day windows exceed policy.
   • python3 -m unittest -v check_cve_exception_expiry_test.py at c9414b9659ce95652d6c3d9c3bd28656622d47ad passed 10/10; its CLI exited 1 on the live tree but 0 on the 2027-01-01 variant, so it does not enforce review-window or disposition policy.
   • GitHub API: [stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509 is open with no newer maintainer feedback and Project 4 status In review; Fail CI when a CVE exception has passed its expires date #501 is closed unmerged with no reviews/comments; exact-head push CI runs 34062866377, 34062866413 and 34062866425 are green; scheduled DEB run 34274797181 was non-terminal with no failed job at the review cutoff.

   Actionable findings:

   1. Blocking defect: correct CVE-2026-19672's disposition. CPython merged the 3.13 backport c7979f3a819011a3222bd16e671264b1e34282cb on 2026-08-19; it is on the current 3.13 branch and 69 commits after v3.13.15. Move this row out of the no-backport/VEX set and track it with CVE-2026-15806 as a 3.13.16 bump obligation; update the [stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509 checkpoint and human decision set.
   2. Delivery obligation: do not describe c9414b9659ce95652d6c3d9c3bd28656622d47ad as ready to land. Its own 2027-01-01 control passes, while the required policy checker rejects those 115-day windows and three current disposition values. If the guard is revived, enforce the 14-day review window and accepted dispositions, or explicitly scope it as expiry-only and add the missing policy control.
   3. Blocking no-change defect: exceptions/stackstate-k8s-agent/CVE-2025-15367.yaml still says it is tracked in [stackstate-agent] CVE-2026-14456 (openssl 3.5.7) — no upstream fix published, needs a tracked exception #489, but [stackstate-agent] CVE-2026-14456 (openssl 3.5.7) — no upstream fix published, needs a tracked exception #489 is the obsolete OpenSSL CVE-2026-14456 ticket this candidate recommends closing. Point the exception at [stackstate-agent] Dev scan 34027081656: bump x/crypto to 0.56.0 and grpc to 1.83.1; krb5 and python rows need a human VEX or exception decision #509 or its actual owner before any renewal; this is a source correction warranted at this head.

   Optional suggestions:

   • Correct the reachability wording: cmd/system-probe/subcommands/usm/debug_scripts/usm_leak_detector/backends/bpftool_downloader.py imports tarfile and urllib.request, although it is absent from the published image layers. Use artifact absence rather than the claim that all such callers are under tasks/.
   • Correct the exception-consumer wording: .github/workflows/build-binaries.yml also passes exceptions-path: exceptions; both repository consumers remain mode: inform, so the gate conclusion is unchanged.
7. ai-collaboration-app commented on Sep 8, 2026

   

   ai-collaboration-appbot

   on Sep 8, 2026

   Author

   More actions

   Dev scan 34191503812 — round 2, after review

   Review round 1 (audit) found three defects in my previous checkpoint. All three were valid. Two of them mean my earlier classification of the Python rows was wrong, so this comment supersedes the relevant parts of that checkpoint.

   Candidate: #511, head 83cfa1fb7fe6015f659931c063e41bc349f3cd2f, branched from 158e1098755d8ee4e563348ae0b861fa217a5c1b.

   Correction 1 — two Python rows are 3.13.16 bump rows, not no-fix rows

   I classified CVE-2026-19672 as having no fix anywhere, on the grounds that its CNA range (< 3.16.0) names a version that does not exist and the advisory publishes no commit SHAs. That was wrong, and the method was the problem: I checked only the advisory's main-branch commits and their divergence from our tag, instead of following the upstream issue to its per-branch backport pull requests.

   CVE-2026-19672 (gh-155999) does have a merged 3.13 backport — PR python/cpython#156042, merge commit c7979f3a819011a3222bd16e671264b1e34282cb, base branch 3.13, merged 2026-08-19. compare/c7979f3a...v3.13.15 is behind_by: 69, and compare/c7979f3a...3.13 confirms it is an ancestor of the branch. So it is guaranteed to ship in 3.13.16.

   Re-running the same method on the other two changes their story as well. Neither is a permanent no-fix row:

   CVE	3.13 status	Lands in 3.13.16?
   CVE-2026-15806	Backport merged: a2773a34183b7d94a243bb98fd658926cc5348ce, 60 commits after v3.13.15	Yes, guaranteed
   CVE-2026-19672	Backport merged: c7979f3a819011a3222bd16e671264b1e34282cb, 69 commits after v3.13.15	Yes, guaranteed
   CVE-2026-17084	Backport open, unmerged: #156922, base 3.13, opened 2026-09-04	Only if it merges
   CVE-2026-15310	Backport open, unmerged: #156738, base 3.13, opened 2026-08-31	Only if it merges

   For the two open ones, search/issues q='repo:python/cpython is:pr is:merged base:3.13 gh-<issue>' returns zero, and each PR's merge_commit_sha is only GitHub's speculative test-merge ref — compare/<ref>...3.13 reports diverged, so neither is on the branch. That negative result is trustworthy rather than a query artifact: the identical query for gh-155999 does return the known-merged #156042. Both fixes are merged on 3.14 and 3.15. Note CVE-2026-15310's 3.13 backport is scoped to bzip2/LZMA only, because 3.13 has no zstd module.

   v3.13.15 remains the newest released 3.13.x, so nothing is bumpable today — but the disposition framing changes: for two rows this is "wait for 3.13.16", not "argue no fix exists". A not_affected VEX would be the wrong instrument for those.

   Correction 2 — my reachability evidence was wrong

   I previously wrote that no affected module path is referenced by Python shipped in the image, based on Dockerfile COPY inference. The review pointed out a non-tasks/ helper that imports tarfile and urllib.request, and it is right: cmd/system-probe/subcommands/usm/debug_scripts/usm_leak_detector/backends/bpftool_downloader.py. So I checked the published image directly instead of inferring, which is the evidence that actually counts.

   Inside quay.io/stackstate/stackstate-k8s-agent@sha256:35e66696a1bdc0d470e0d11d7711e426548a09d31190bdd94cd1350b464dc839:

   • The repo's tasks/ tree is absent, and so are bpftool_downloader.py and usm_leak_detector. The only shipped first-party Python is /readsecret.py, which imports just argparse, json, os.path and sys. That part of my earlier conclusion survives — but it was luck, not method.
   • However, shipped third-party site-packages do reach the affected modules, which my earlier claim denied. Per row:

   CVE	Reached by shipped code?	Evidence
   CVE-2026-17084 stringprep/idna	Yes — genuinely reachable	scramp/core.py (SASLprep over credentials, exercised by any SCRAM auth), urllib3/connection.py and urllib3/util/connection.py (.encode('idna') on hostnames), plus idna/codec.py, pydantic/v1/networks.py, asn1crypto. Precondition for impact is a codepoint whose Unicode 3.2.0 and current-Unicode mappings differ, but the code path itself is on the agent's own HTTP and SASL paths.
   CVE-2026-19672 tarfile filters	Yes, but not on an agent runtime path	dateutil/zoneinfo/rebuild.py, build/_compat/tarfile.py, build/_builder.py, pyproject_hooks. These are packaging and tz-rebuild utilities, so it is not cleanly unreachable either.
   CVE-2026-15806 urllib password managers	Effectively no	Only six.py and botocore/vendored/six.py mention HTTPPasswordMgr*, and only as urllib2 name re-exports. No password manager is constructed.
   CVE-2026-15310 zipfile bz2/LZMA/zstd	No	Zero hits for ZIP_BZIP2, ZIP_LZMA or ZIP_ZSTANDARD anywhere in shipped code.

   The practical consequence: CVE-2026-17084 should not receive a reachability-based not_affected statement. It is in the HTTP and SASL path. CVE-2026-15310 is the strongest not_affected candidate on reachability grounds. The two merged-backport rows are best handled by the 3.13.16 bump regardless.

   One prior gap is now partly closed: stackstate_checks (base 6.12.0) is present in the image, so the integrations surface ships here and is directly assessable rather than being wholly outside this checkout as I previously recorded. A full not_affected argument still has to account for check code in StackVista/stackstate-agent-integrations, but it can now be examined in-image.

   Correction 3 — the exception pointed at the wrong tracker (fixed in #511)

   exceptions/stackstate-k8s-agent/CVE-2025-15367.yaml referred readers to #489 for tracking. #489 is the OpenSSL CVE-2026-14456 ticket and is obsolete, so anyone following it to re-verify this Python row would find nothing about it. #511 points it at this ticket and records the re-check evidence (b234a2b67539f787e191d2ef19a7cbdce32874e7 diverged from both v3.13.15 and the 3.13 branch head).

   expires: '2026-09-04' is deliberately unchanged. CVE-2026-4360.yaml already referenced this ticket correctly.

   The expiry guard: scoped as expiry-only, and why it should not land yet

   The review is right that branch cve-exception-expiry-fail-closed (c9414b96) is not policy-complete. The SLA's authoritative encoding enforces considerably more than a date:

   • a maximum 14-day review window, not merely a future date;
   • a closed set of dispositions — accepted_pending_upstream_fix, accepted_risk, false_positive, not_affected;
   • required status, reason, owner, statement, plus product.consumer and product.image;
   • an https upstream_reference whenever the status is accepted_pending_upstream_fix.

   That guard checks the expiry date and nothing else, so it would pass files that breach the SLA. Measured against this tree, three of the four current files carry dispositions outside the supported set — under_investigation in CVE-2026-4360.yaml, and accepted_with_compensating_control in both GO-2026-5932.yaml files — and the guard is indifferent to all three. A 2027-01-01 date is 115 days out, far past the 14-day window, and the guard exits 0 on it.

   I am scoping it explicitly as expiry-only rather than completing it, because of sequencing. Any fail-closed guard fails on this tree the moment it lands: all four files are lapsed, and policy-complete enforcement would add three disposition violations on top. Making it green requires renewing or dropping those exceptions, which is precisely the human disposition decision below. So guard delivery has to follow that decision, not precede it — landing it first would just red the default branch with no one able to fix it but a maintainer. That is also why I have not resurrected #501, which a maintainer closed unmerged.

   Worth noting for scope: full policy enforcement already exists in the review harness, so the gap is enforcement in this repo's CI, not an absence of any check at all.

   Minor correction

   exceptions/ has two consumers, not one: .github/workflows/build-deb.yml:330 and .github/workflows/build-binaries.yml:250. Both are mode: inform, so the conclusion is unchanged — nothing in this repo gates on the tree, and the gating chart scan never reads it — but my earlier "only consumer" claim was wrong.

   CI

   #511 required CI reached a terminal state and is green: 25 successful checks, 17 skipped, no failures and nothing pending. That includes both Unit tests variants, both omnibus DEB builds, and the agent and cluster-agent container image builds on amd64 and arm64. No review feedback on the PR at the time of writing.

   Remaining work

   1. Human disposition on the four Python rows, now with a sharper split: CVE-2026-15806 and CVE-2026-19672 are wait-for-3.13.16 bumps; CVE-2026-15310 is the clean not_affected candidate; CVE-2026-17084 is reachable and needs a risk decision, not an unreachability argument. Only a reviewed vexhub statement affects the gating scan.
   2. Disposition the four lapsed files (all expires: '2026-09-04'), and note that three also need a supported status and a window inside 14 days. Untouched by me.
   3. Land expiry/policy enforcement in CI after step 2, choosing expiry-only or policy-complete. Branch c9414b96 is verified working as an expiry-only guard (10/10 unit tests; exits 1 on this tree).
   4. Bump embedded CPython to 3.13.16 when released — clears CVE-2026-15806 and CVE-2026-19672 outright, and CVE-2026-17084/CVE-2026-15310 too if #156922/#156738 merge first.
   5. Fresh-scan verification stays open. Today's dev scan is decision: failed; Retire the VEX-superseded agent CVE exceptions and repair the rest #511 does not change any scanned artifact.
   6. Assess check code in stackstate-agent-integrations for the CVE-2026-17084 IDNA path specifically.
   7. Maintainer call on closing [stackstate-agent] CVE-2026-14456 (openssl 3.5.7) — no upstream fix published, needs a tracked exception #489, obsolete since the OpenSSL 3.5.8 rebuild.

   Next action: decide CVE-2026-17084 on risk rather than reachability, and treat CVE-2026-15806/CVE-2026-19672 as a 3.13.16 bump rather than VEX candidates.
8. ai-collaboration-app commented on Sep 9, 2026

   

   ai-collaboration-appbot

   on Sep 9, 2026

   Author

   More actions

   Extending this ticket to dev scan 34330594840

   Scan 34330594840 attempt 1, source aaf94a21, artifact sha256:d40f1cf0f71e. Both targets now build from 158e1098, the merge of #510. 0 CRITICAL, 5 HIGH rows, 1 MEDIUM — but only two distinct advisories.

   The five HIGH rows are all CVE-2026-84445 on google.golang.org/grpc v1.83.1, counted once per scanner per image. Everything #510 fixed is gone: no x/crypto row, no CVE-2026-84304.

   Severity	CVE	Package	Installed	Fixed in	Verified against
   HIGH	CVE-2026-84445	google.golang.org/grpc	v1.83.1	1.83.2	GHSA-2v4p-qf9q-27wj
   MEDIUM	CVE-2026-17084	python	3.13.15	none	carried over, still no fix

   CVE-2026-84445 is a DoS crash in gRPC-Go xDS servers on a request with neither :authority nor Host. Per the upstream GHSA the 1.83.x line is vulnerable in >= 1.83.0, < 1.83.2. It reaches all three shipped binaries: bin/agent/agent and bin/installer/installer in the agent image, bin/stackstate-cluster-agent/stackstate-cluster-agent in the cluster-agent image.

   Fixed in #514. That PR adopts Dependabot #512 and #513 as their own commits and adds the root go get plus go work sync that neither of them has. Validated by reading go version -m back off all three built binaries.

   The Dependabot PRs, precisely

   • Bump google.golang.org/grpc from 1.83.1 to 1.83.2 in /pkg/proto #512, Bump google.golang.org/grpc from 1.83.1 to 1.83.2 in /comp/core/tagger/impl-remote #513 — correct content, but submodule-only, so neither reaches a shipped binary. Adopted into Bump grpc to 1.83.2 for CVE-2026-84445 #514; close both in favour of it. Their CI cannot go green regardless: the dependency-cache job fails with password is empty because registry secrets are not exposed to Dependabot-authored PRs.
   • Bump google.golang.org/grpc from 1.80.0 to 1.83.2 in /comp/otelcol/otlp/components/statsprocessor #503 — bumps comp/otelcol/otlp/components/statsprocessor to 1.83.1, still inside the vulnerable range, so it does not fix this row. That module is one of four outside go.work and outside the root build graph (with datadogconnector, pkg/dyninst/testprogs/progs, test/integration/serverless/src) that stay at v1.80.0 and ship in no image. Independently valid, but needs re-targeting to 1.83.2 to be worth merging.
   • Unrelated: the Dependabot runs for /comp/otelcol/otlp/example/metric and /test/e2e/containers/otlp_sender fail because those directories no longer exist. Stale dependabot.yml entries, not a CVE issue.

   Exceptions: check-cve-exception-policy --as-of 2026-09-09 failed on all four files

   All four expired 2026-09-04 and three carried unsupported dispositions. Fixed in #511, which now exits 0.

   • CVE-2025-15367 and CVE-2026-4360 deleted. vexhub#39 merged reviewed statements covering both. In this run's Grype report for the agent image both sit in ignoredMatches with appliedIgnoreRules namespace vex — not_affected and fixed respectively — against pkg:generic/[email protected], the exact subcomponent the statements pin. The uncovered CVE-2026-17084 row is still reported in the same run, so VEX is doing the suppressing rather than a scanner filter. This closes the deferral recorded above for CVE-2025-15367.
   • Both GO-2026-5932 files kept and repaired, status not_affected, expiry 2026-09-23. The advisory range is introduced: 0 with no fixed event, so no x/crypto release clears it and reachability is the only disposition: go list -deps over ./cmd/agent, ./cmd/installer and ./cmd/cluster-agent with the release tag set contains no golang.org/x/crypto/openpgp package.

   One thing for a human: the vexhub gap those files claimed away

   Both GO-2026-5932 files stated that vexhub already carried a reviewed image-scoped not_affected statement and that the exception merely bridged a scan-time identity gap. That was wrong. vexhub carries GO-2026-5932 only for stackstate-k8s-process-agent and sts-opentelemetry-collector, and there is no vexhub document for stackstate-k8s-cluster-agent at all — the cluster-agent Grype report has zero ignoredMatches, confirming no VEX reaches that image. A reviewed vexhub statement is the better home for both; the 2026-09-23 expiry is the deadline for that call, not an acceptance.

   Still deferred

   CVE-2026-17084 (python 3.13.15, MEDIUM, no published fix) is the only live row left after #514. It needs a reviewed vexhub statement or a fresh exception — a human decision, related to vexhub#34. The krb5 rows are no longer attributed to this repo in this scan.

   #489

   The delivery evidence it was waiting on is confirmed again here: no OpenSSL row appears in this scan, active or ignored. It is stale and misleading as written — recommend closing it as delivered by #498, with CVE-2026-17084 and the vexhub work tracked here instead. Left open for a human to close.
9. ai-collaboration-app commented on Sep 9, 2026

   

   ai-collaboration-appbot

   on Sep 9, 2026

   Author

   More actions

   Both PRs terminal green

   PR	Head	Lint & unit tests	Binary builds	DEB package build
   #511 exceptions	f821d4528a	success	success	success
   #514 grpc 1.83.2	36eb6c20a6	success	success	success

   The image-scan steps in those runs are a real before/after, since the two branches differ only in grpc:

   • agent image: 8 findings incl. CVE-2026-84445 [HIGH] [email protected] [grype,trivy] on Retire the VEX-superseded agent CVE exceptions and repair the rest #511's branch → 7, row gone on Bump grpc to 1.83.2 for CVE-2026-84445 #514's, on amd64 and arm64.
   • cluster-agent image: 2 → 1, row gone, both architectures.

   Also confirmed the exception evaluator enforces expiry, which means the baseline files were suppressing nothing: on #514's branch (baseline exceptions) the agent scan reports suppressed by exception: 0, expired: 3. On #511's branch it reports expired: 0 and GO-2026-5932 … (not_affected — vulnerable_package_absent_from_command_dependency_graph) suppressed on both images. So #500's contract was already biting silently, and #511 is what restores it.

   One nuance recorded honestly rather than glossed: the in-repo scan targets …:ci-<arch>, a different image identity from the published tags, so VEX does not reach it and after the two deletions CVE-2025-15367 and CVE-2026-4360 show as unmanaged there. That scan is mode: inform and it already listed CVE-2026-15310, -15806 and -19672 as unmanaged before this work — VEX-covered at publish, no local exception — so the two rows join a pre-existing category rather than a new one. The gating cve-reporter scan suppresses both via vexhub#39.

   Next action is human: review and merge #511 and #514 together (the tree only passes check-cve-exception-policy once #511 lands), close #512 and #513 as adopted, retarget or close #503, and close #489 as delivered by #498. Then a fresh dev scan should leave only CVE-2026-17084 on this repo, which needs a reviewed vexhub statement — along with GO-2026-5932 for both agent images, where vexhub currently has no document at all.