Repository navigation
Resolve scanner dependency advisories before adoption #5553
Description
🤖 Generated by the Agentic Engineer
Problem and impact
The public kubevuln scanner release reports reachable dependency advisories in both executable entrypoints. A functional scanner repair therefore needs a separate security disposition before adoption; a verified signature does not establish that result.
An audit of unmodified v0.3.571 reproduces eight advisory records across three modules. Some records cover broad legacy modules, so their reported count must not be presented as eight proven exploitable defects. The HTTP dependency has a published fixed release; the existing upstream RAR-decoder issue remains separately tracked by the project.
Acceptance criteria
- Establish a reproducible source and actual published-binary baseline with the public advisory database.
- Apply supported dependency corrections without changing scanner capabilities, discarding results or suppressing advisories.
- Analyze remaining records against their upstream advisories and real call paths; retain unresolved findings as blockers.
- Validate both scanner entrypoints and the existing functional regression suite, with an independent review of the proposed head.
- Adopt only a reviewed, tested, signed immutable artifact, then prove complete current-image result coverage through the protected deployment path.
This is a prerequisite for the scanner adoption in #5403, under the platform roadmap #2043. Detailed audit and runtime evidence stays in private operator evidence. Upstream dependency coordination remains with the upstream maintainers; no unrelated Syft or Grype version change is proposed.
Metadata
Metadata
Assignees
Labels
Type
Fields
Projects
- Status
Activity
chore: agent-claim #5553 nonce=74d3f8abd09ebfa331cfa9535cb97125
devantler commentedon Oct 29, 2026
The latest published upstream scanner reproduces the dependency audit blocker. A manifest pin cannot change embedded executable dependencies, and no existing portfolio-owned artifact supplies the correction. The sufficient source change is a small upstream dependency update; the public project and its contribution policies have been checked, and its PR template is available.
The prepared change updates only the HTTP dependency and its Go-generated checksums. Both entrypoints build; the complete source race suite, vet and pinned lint pass. The target's full test command passes with its four existing skips explicitly retained as unexecuted coverage. Source and both executable audits remove the HTTP records while preserving three other unresolved records. A clean overall audit and deployment acceptance have not been established, so the image-adoption hold remains.
chore: agent-claim #5553 nonce=239ca78e67341083bb6a0bb4b2a5449d
devantler commentedon Oct 29, 2026
The minimal HTTP dependency correction is offered upstream as kubescape/kubevuln#1218, Ready for Review at signed head
8ec68b4582dbb185b1b9ca8d827ec468d182f7e3. The target template and published body are now verified through the required write gate. Local validation is complete with the declared integration-test skips; hosted fork workflows require upstream maintainer approval, so no hosted success is claimed.The remaining dependency records and protected artifact/adoption acceptance remain unresolved. This issue and the scanner adoption stay open; the upstream review handoff does not establish platform recovery.
devantler commentedon Oct 29, 2026
The HTTP dependency correction kubescape/kubevuln#1218 merged on 29 October after upstream approval at its exact proposed head. The resulting upstream revision is
3f1c4edc7a5a667ffba357122add316900daacd3.The post-merge executable audit still fails with three remaining advisory records. This confirms partial upstream delivery, without establishing a clean audit, an accepted published artifact or platform adoption. The remaining analysis and protected adoption criteria above remain open; #5403 and its delivery PR stay held.
devantler commentedon Oct 29, 2026
The existing upstream stack upgrade now covers the Syft, stereoscope and container-registry dependency changes, so a duplicate proposal is unnecessary. At
6462921584b809d48e76f986280d9f336d9e912e, native build, lint and Basic-Test checks pass. The upstream review still requests the fixed Syft fork, and the proposed upgrade retains other dependency-audit findings.This is static source and native-check evidence only. The branch has not been executed locally, no new scanner artifact has been accepted, and #5405 stays held. After the upstream repair lands, independently audit both published executables and validate current-image scan coverage through protected deployment before closing this issue.
devantler commentedon Nov 2, 2026
Upstream moved today, but the audit is still red, so this stays open and #5405 stays held. Read on 2 November from public upstream records only. I did not build, run or pull the scanner.
kubescape/kubevuln#1224 merged at 07:11 UTC and v0.3.575 followed at 15:08 UTC, with Grype v0.121.0 and Syft v1.55.0.
github.com/docker/dockerv28.5.2What the two records are. Both describe Moby plugin features: an AuthZ plugin bypass and a plugin privilege check. Neither record lists affected symbols, and both mark every version of
docker/dockeras affected with no fix on that module path. The only listed fix isgithub.com/moby/moby/v22.0.0-beta.8. So no version bump of this module can clear them. A disposition from real call paths looks like the route, and it has not been done yet.Three things this read does not establish:
kubevuln. The tag also hascmd/cliandcmd/sbom-scanner, so this result does not cover them.docker-credential-helpersclient symbols under these records, which the records themselves do not name. I have not traced why.Adoption is now bigger than the #5405 pin:
kubescape/storagev0.0.382 to decode new source types and keep new package metadata. The platform runs its own storage build based on v0.0.297, so a scanner bump alone risks storing incomplete SBOMs. The storage build has to move first or together with it. I did not test this.Next: trace how
docker/dockeris imported, audit the published image's executables, then decide the scanner and storage order.devantler commentedon Nov 2, 2026
Reachability trace, v0.3.575 source at
cbaa9d5.go list -depson each entrypoint, without building or running anything.docker/dockerpackages linkedmoby/mobypackages linkedcmd/http,cmd/sbom-scannerapi/types/versions,api/types/filters,api/types/registryapi/types/*andclient/*cmd/cliSo neither serving entrypoint links the Docker daemon, its authorization middleware or its plugin manager. Both records describe those features and carry no symbol list, so govulncheck can only match them at module level. That supports a documented not-affected disposition for these two records, but it is my reading of the advisory summaries plus this package list, not a confirmed upstream statement. I have not recorded that disposition or cleared the blocker. It covers source at the tag, and the published image audit remains open. The earlier note about 17
docker-credential-helperssymbols is still unexplained.fix(kubescape): prepare verified scanner parser repairs
3 remaining items
fix(kubescape): harden compatibility storage dependencies
chore: integrate reviewed main for hardened storage
chore: integrate reviewed migration diagnostics
devantler commentedon Nov 2, 2026
#5776 prepares the compatibility-storage producer needed before #5405: inventory preservation, supported dependency fixes, a pinned builder, and audit checks for both storage programs.
The complete local suite passes with three existing skips, and the binary audits pass without suppressions. The draft still needs hosted validation and current-head review, then publication and image readback before runtime adoption. #5553 remains open until its deployment and compatibility acceptance are demonstrated.
devantler commentedon Nov 2, 2026
The official scanner's v0.3.575 release explicitly leaves a retracted dependency as follow-up work. A small upstream dependency update is needed before that official artifact can be adopted securely.
A Platform image-reference change cannot repair the dependency embedded in the vendor binary. Maintaining another scanner build would duplicate the producer and its ongoing maintenance rather than fix the official artifact, so there is no sufficient in-portfolio configuration fix for this adoption path. I am preparing the minimal two-file dependency update under the project's contribution policy; runtime adoption remains held until a corrected artifact is published and verified.
The dependency bump passes the required local tests, race checks, production build, vet and lint, with the four existing Docker-backed skips retained. A separate binary-audit attribution failure reproduces unchanged on the official baseline, so the upstream contribution will remain draft while that blocker is resolved.
devantler commentedon Nov 2, 2026
The remaining audit attribution failure now reproduces with a small standalone program using only public dependencies. Both the existing auditor and its current stable release assign Docker-module advisories to a separate module with an overlapping path prefix.
The matching is implemented inside the upstream Go auditor, and there is no sufficient Platform configuration alternative that repairs that logic while preserving the binary-audit gate. I am reporting the reproducible tool defect on its canonical
golang/gotracker under that project's vulnerability-management issue form. The official audit remains enforced, and scanner adoption stays held until the attribution problem is resolved.devantler commentedon Nov 2, 2026
The defect reported in golang/go#82780 is in the auditor owned by
golang/vuln. A minimal two-file correction now passes the canonical source's full test suite, affected-package race tests, vet, and the unchanged public reproduction.The current released auditor still reproduces the defect; a Platform configuration change cannot repair its module-matching implementation while preserving the binary-audit gate. The necessary upstream code contribution will therefore target
golang/vulnusing its supported GitHub contribution process. Scanner adoption remains held until a reviewed, corrected auditor and the required scanner artifact are available.devantler commentedon Nov 2, 2026
The storage compatibility and dependency repair in #5776 has passed current-head validation and review and is in the protected merge queue. Its immutable image is not published or adopted yet.
The scanner dependency follow-up is kubescape/kubevuln#1226. Its ordinary binary audit still fails on the unchanged release and the proposed update. The reproduced module-attribution defect is golang/go#82780; golang/vuln#15 is now ready for upstream review after local validation and the passing CLA check. Experimental auditor binaries have not replaced the normal acceptance gate. The scanner PR and runtime adoption remain held; this issue stays open.
chore: agent-claim #5553 nonce=f19fe2cb048a93743e016e1ace8f2312
chore: agent-claim #5553 nonce=fedf29721240589e1677a62134d3aaf1
chore: agent-claim #5553 nonce=89454d81553963b73980e15af5482f86
chore: agent-claim #5553 nonce=ead219a0f4f69725f0ac13ba7c0ca29d
chore: agent-claim #5553 nonce=586c7ffcb63120f3a0d00e94041b64da
devantler commentedon Nov 3, 2026
The storage prerequisite has advanced: #5776 merged and its publication workflow succeeded. I independently verified the immutable image signature and provenance, then extracted and audited both shipped executables with the official released auditor; both pass.
Runtime adoption is proposed in draft #5808. Local manifest and authorization validation pass, including the complete-object ledger update required for the image pin. Current-head hosted checks, independent review, protected deployment and complete current-image result readback remain required.
The scanner upgrade remains held on its separately tracked dependency and ordinary-auditor gates. Neither this publication nor the adoption draft closes #5553 or establishes complete platform security.
devantler commentedon Nov 3, 2026
The scanner dependency correction kubescape/kubevuln#1226 merged at 06:45 UTC on 3 November as
cf9ff2edf174e41ad6ac2712e1dde7e1a046a1c5. The latest published scanner release is still v0.3.575, so that source delivery has not yet produced an accepted replacement artifact.I also independently checked the latest official Go auditor: v1.9.0, with its module checksum and public tag bound to the canonical Go repository. It still reproduces the module-prefix attribution defect on the unchanged public reproduction. The upstream Gerrit review remains open without maintainer feedback. This confirms the blocker against the current released auditor; no experimental auditor was substituted and no binary-audit gate was relaxed.
Storage adoption #5808 now has current-head green checks and clean independent review and is accepted into the protected merge queue. Actual runtime adoption, the newly corrected scanner publication and complete current-image results remain outstanding; this issue and #5405 stay open.