Index › devops › cosign cosign 1 tool · 1 release line container signing, verification and storage in an OCI registry. Every tool here carries the same sandbox boundary. $ boks cosign ⧉ Source ↗ Registry ↗ Release lines we maintain · the project decides these findings shown are the whole project at that line Tag Resolves to Lifecycle Updated Findings What the tag promises ▸ latest 3.1.3 stable 2026-08-19 7 tracks the newest supported release stable — floats, carries security updates unstable — tracks pre-releases, may break eol — frozen, upstream is done Tools in this project · pick one to inspect all share one boundary Tool Capabilities Seccomp Findings Image Description ▸ cosign netrw default H4?3 cosign Container signing, verification and storage in an OCI registry ▸ showing cosign from cosign@latest → 3.1.3 stable Findings H4?3 identical on amd64, arm64 — one table describes both CVE Sev CVSS Affects Description GHSA-hrxh-6v49-42gf ↗ H 8.8 google.golang.org/grpc gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities GO-2026-6179 ↗ H 8.4 golang.org/x/mod A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. GO-2026-5970 ↗ H 7.5 golang.org/x/text A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes. GO-2026-6180 ↗ H 7.5 golang.org/x/mod A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by… GO-2026-5841 ↗ ? — github.com/klauspost/compress Providing a specially crafted dictionary to s2.NewDict and using it to encode data can make the encoder read out of bounds. GO-2026-5932 ↗ ? — golang.org/x/crypto The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used. GO-2026-6225 ↗ ? — github.com/chrismellard/docker-credential-acr-env In github.com/chrismellard/docker-credential-acr-env/pkg/credhelper, the regular expression used by isACRRegistry to validate Azure Container Registry hostnames is unanchored. These are the findings of cosign, which ships every tool in this project. boks reports and gates; it never edits an image to clear a finding. Composition default nothing — stands alone runtime none — self-contained composes not used as a runtime Some tools are only useful composed: a pip-installed CLI needs python as its runtime, bash pulls in coreutils. boks resolves that for you — -e git,python:flake8 composes explicitly. Image image ghcr.io/boks-sh/cosign:3.1.3 digest sha256:a3c2…9029 copy platforms amd64 sha256:7166…c366 copy arm64 sha256:5856…6c86 copy size 101 MB unpacked · 1 layer base scratch signed cosign · verified last scan 2026-08-19 Sandbox boundary cosign capabilities netrw Filled is granted by default; the rest need --cap at the point of use. seccomp tier per tool default The syscall filter applied to this tool's entry point. Tools sharing an image do not share a tier. dotfiles mapped in read-only unless noted ~/.sigstore · writable env passed through 0 of 1 Nothing else crosses in. No AWS_*, no SSH_AUTH_SOCK unless you ask. per-subcommand no overrides Every invocation gets the same boundary. Where a tool needs more for one subcommand only, boks scopes it there rather than granting it everywhere. Provenance sbom amd64 ↗ arm64 ↗ attestation amd64 ↗ arm64 ↗ scan report amd64 ↗ arm64 ↗ grype · 2026-08-19 vex amd64 ↗ arm64 ↗ Every image ships a full SBOM and a signed build attestation. Nothing here is a claim you have to take on trust. 7 findings across this project at latest. Counted once per advisory across every image the project builds.