GO — Healthy across the board

• Last commit 1d ago
• 24+ active contributors
• Distributed ownership (top contributor 40% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Cosign is a tool for signing OCI container images and arbitrary binaries using the Sigstore public good infrastructure (Fulcio CA and Rekor transparency log), with support for keyless signing, hardware/KMS signing, and encrypted keypair signing. It makes cryptographic signatures 'invisible infrastructure' by integrating signing seamlessly into container registries and CI/CD pipelines. Monorepo structure: cmd/cosign contains the CLI entry point with subcommands organized in cmd/cosign/cli/ (sign, verify, attest, attach, bundle); internal/ likely contains shared signing/verification logic; the codebase is predominantly Go (1.9MB of 1.95MB total code) with supporting shell scripts and Makefiles; Go modules used for dependency management (go.mod shows 1.25.7).

DevOps engineers, security teams, and container platform operators who need to sign and verify container images and binaries in production; developers integrating Sigstore into their supply chain security workflows; organizations implementing container image provenance and attestation.

Production-ready and actively maintained. The project is part of the OpenSSF Sigstore initiative, has comprehensive GitHub Actions workflows for testing and validation, passes CII Best Practices badge, and has a stable 2.x release branch with ongoing feature development. Future development is shifting toward sigstore-go (a companion library), but cosign 2.x continues to receive updates.

Moderate risk: The codebase depends on 30+ upstream Sigstore/Google components (fulcio, rekor, sigstore, sigstore-go, certificate-transparency-go) which creates transitive dependency complexity; the project explicitly notes that development is shifting to sigstore-go, meaning cosign's direct maintenance may decrease. However, it's production-grade with strong CI coverage, no obvious single-maintainer bottleneck, and gradual deprecation of the GCS bucket (not the tool itself).

The project is in maintenance mode for cosign 2.x while steering new feature development toward sigstore-go (mentioned in README). Recent activity includes dependency updates (Dependabot configured), conformance testing with nightly runs, and release validation workflows. The focus is stability and compatibility rather than major new features in cosign itself.

git clone https://github.com/sigstore/cosign && cd cosign && go install ./cmd/cosign && $(go env GOPATH)/bin/cosign

Daily commands: make build compiles the binary; go run ./cmd/cosign [command] runs directly; GitHub Actions workflows (build.yaml, e2e-tests.yml) show full test matrix. For development: make lint runs golangci-lint, make test runs Go tests.

• cmd/cosign/cli/commands.go — Entry point that wires all CLI commands; essential for understanding the command structure and how subcommands are registered
• cmd/cosign/cli/load.go — Core loader for images and artifacts; all signing/verification operations depend on this abstraction
• cmd/cosign/cli/fulcio/fulcio.go — Integrates Fulcio CA for keyless signing; critical for understanding the default Sigstore PKI flow
• cmd/cosign/cli/attest/attest.go — Attestation signing logic; demonstrates the pattern for container artifact manipulation
• cmd/cosign/cli/options/attest.go — Options parser for attestation; shows the flag/configuration pattern used across all commands
• .github/workflows/e2e-tests.yml — End-to-end test configuration; reveals expected behavior and integration test patterns
• go.mod — Module definition with all dependencies; critical for understanding sigstore integration and crypto libraries

Add a New CLI Signing Command

1. Create command struct in cmd/cosign/cli/{command}.go following the pattern in cmd/cosign/cli/attest.go (cmd/cosign/cli/attest.go)
2. Define command-specific options in cmd/cosign/cli/options/{command}.go with flags matching cmd/cosign/cli/options/attest.go structure (cmd/cosign/cli/options/attest.go)
3. Implement business logic in cmd/cosign/cli/{command}/{command}.go mirroring cmd/cosign/cli/attest/attest.go (cmd/cosign/cli/attest/attest.go)
4. Register the command in cmd/cosign/cli/commands.go by adding it to the root command's subcommands (cmd/cosign/cli/commands.go)
5. Add integration tests in cmd/cosign/cli/{command}/{command}_test.go following cmd/cosign/cli/attest/attest_blob_test.go pattern (cmd/cosign/cli/attest/attest_blob_test.go)

Add Support for a New Key/Certificate Source

1. Create a new provider module at cmd/cosign/cli/{provider}/ mirroring cmd/cosign/cli/fulcio/ (cmd/cosign/cli/fulcio/fulcio.go)
2. Implement certificate retrieval matching the interface expected by cmd/cosign/cli/attest/common.go (cmd/cosign/cli/attest/common.go)
3. Add corresponding verification logic in cmd/cosign/cli/{provider}/verifier similar to cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier.go (cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier.go)
4. Add command options in cmd/cosign/cli/options/ to expose the new provider's flags (cmd/cosign/cli/options/certificate.go)
5. Add provider-specific tests following cmd/cosign/cli/fulcio/fulcio_test.go patterns (cmd/cosign/cli/fulcio/fulcio_test.go)

Add Artifact Attachment Type (e.g., Custom Metadata)

1. Create attachment handler at cmd/cosign/cli/attach/{type}.go following cmd/cosign/cli/attach/sig.go pattern (cmd/cosign/cli/attach/sig.go)
2. Add download handler at cmd/cosign/cli/download/{type}.go mirroring cmd/cosign/cli/download/signature.go (cmd/cosign/cli/download/signature.go)
3. Register in cmd/cosign/cli/attach/attach.go to wire into the main attach orchestration (cmd/cosign/cli/attach/attach.go)
4. Add corresponding options in cmd/cosign/cli/options/attach.go if the type needs specific flags (cmd/cosign/cli/options/attach.go)
5. Write integration tests in cmd/cosign/cli/attach/ or cmd/cosign/cli/download/ matching existing _test.go files (cmd/cosign/cli/attach/attach.go)

Add a New Verification Path (e.g., Custom CA)

1. Extend the options in cmd/cosign/cli/options/certificate.go to accept your CA config (cmd/cosign/cli/options/certificate.go)
2. Create verification logic following the pattern in cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier.go (cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier.go)
3. Wire the verifier into the command flow via cmd/cosign/cli/attest/common.go or similar core operation (cmd/cosign/cli/attest/common.go)
4. Add tests in cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier_test.go or new test file (cmd/cosign/cli/fulcio/fulcioverifier/fulcioverifier_test.go)

• Go — Systems language enables fast, single-binary deployment for supply-chain security tooling; matches Sigstore ecosystem standards
• Fulcio + Rekor + Sigstore — Provides default keyless signing with OIDC identity and immutable transparency logs; reduces key management burden for users

Keyless signing requires network access to Fulcio and Rekor services (configurable via env vars); private key operations may require hardware tokens or KMS credentials (AWS_REGION, AZURE_TENANT_ID, GCP_PROJECT_ID depending on backend); the project uses Go 1.22+ as a hard requirement; OCI image references must be fully qualified (registry/repo:tag); signing/verification operations are slow for the first Rekor lookup due to transparency log tree operations.

• sigstore/sigstore-go — The canonical Go library for Sigstore operations; cosign is moving feature development here and this is the recommended path forward for new integrations
• sigstore/fulcio — The OpenSSF certificate authority that issues short-lived certificates for keyless signing used by cosign
• sigstore/rekor — The transparency log that records and verifies all signatures cosign creates; essential for supply chain provenance
• google/go-containerregistry — The underlying library cosign uses for reading/writing OCI container images and storing signature attachments
• in-toto/in-toto-golang — Provides attestation format support (SLSA provenance, CycloneDX) that cosign integrates via cmd/cosign/cli/attest/

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for cmd/cosign/cli/copy/copy.go

The copy command is a critical feature for mirroring signed artifacts across registries, but there's no corresponding copy_test.go file despite other CLI commands having test coverage. This is a high-value contribution that would improve reliability for a core use case. The test file already exists (copy_test.go), but based on the codebase patterns, it likely needs expansion to cover edge cases like authentication failures, registry connectivity issues, and multi-arch image copying.

• [ ] Review cmd/cosign/cli/copy/copy.go for all exported functions
• [ ] Check existing cmd/cosign/cli/copy/copy_test.go coverage gaps
• [ ] Add tests for: invalid source/destination registries, network failures, permission errors, and multi-platform images
• [ ] Run 'go test ./cmd/cosign/cli/copy/...' and aim for >80% coverage
• [ ] Ensure tests use testcontainers or mock registries to avoid external dependencies

Add integration tests for dockerfile verification in cmd/cosign/cli/dockerfile/verify.go

The dockerfile verification feature (cmd/cosign/cli/dockerfile/verify.go) has tests (verify_test.go exists), but based on the file structure, there's no dedicated CI workflow for dockerfile-specific scenarios. Adding an end-to-end test workflow would ensure Dockerfile scanning works correctly with real container images and signatures, complementing the unit tests.

• [ ] Review cmd/cosign/cli/dockerfile/verify.go and existing verify_test.go
• [ ] Create a new GitHub Actions workflow file: .github/workflows/dockerfile-verify-e2e.yml
• [ ] Workflow should: build a test Dockerfile, sign it with cosign, then verify signatures
• [ ] Add test cases for: FROM statements with unsigned images, verify success/failure scenarios, and signature validation
• [ ] Reference existing e2e-tests.yml and e2e-with-binary.yml as templates

Add unit tests for cmd/cosign/cli/attest/attest_blob.go signature validation

The attest_blob.go command handles attestation for arbitrary blobs (non-container artifacts), which is increasingly important for binary signing. While attest_blob_test.go exists, the related cmd/cosign/cli/attest_blob.go (top-level wrapper) likely needs corresponding tests to verify the CLI flag parsing, input validation, and error handling paths specific to blob attestation.

• [ ] Review cmd/cosign/cli/attest_blob.go for CLI command setup and flag definitions
• [ ] Check cmd/cosign/cli/attest/attest_blob_test.go for existing coverage gaps
• [ ] Add tests for: invalid file paths, missing required flags (key, attestation format), malformed attestation data
• [ ] Test integration with different attestation predicates (SLSA, vulnerability, etc.)
• [ ] Ensure tests cover both local key signing and KMS-based signing paths

1. Add missing integration test coverage for the cosign bundle command (cmd/cosign/cli/bundle/ exists but likely lacks comprehensive e2e tests similar to e2e-tests.yml structure). 2) Document KMS provider setup for Azure Key Vault in CONTRIBUTING.md or docs (the code uses sigstore/sigstore/pkg/signature/kms/azure but setup steps are sparse). 3) Add unit tests for cmd/cosign/cli/attest/attest_blob.go covering error cases like invalid input blobs and malformed attestation policies.

• High · Test Cryptographic Material Exposed in Version Control — .github/workflows/cosign-test.key, .github/workflows/cosign-test.pub. The files .github/workflows/cosign-test.key and cosign-test.pub contain test/example cryptographic keys committed to the repository. While these are marked as test keys, their presence in version control could be misused if an attacker gains repository access, and it sets a poor security precedent. Fix: Move test keys to secure secret management (GitHub Secrets, HashiCorp Vault). Reference them via environment variables in CI/CD workflows rather than committing them to the repository.
• High · Dependency on External Credential Helpers with Potential Supply Chain Risk — go.mod - dependencies: awslabs/amazon-ecr-credential-helper, chrismellard/docker-credential-acr-env, mozillazg/docker-credential-acr-helper. The project includes multiple external Docker credential helper dependencies (ecr-login, docker-credential-acr-env, docker-credential-acr-helper) which are critical for authentication flows. These external packages could be compromised in supply chain attacks. Fix: Implement strict dependency pinning and verification. Use Go's module verification (go.sum validation). Consider implementing Software Bill of Materials (SBOM) generation and scanning. Review and audit these dependencies regularly for security updates.
• High · Use of Deprecated or Lower-Level Cryptographic Packages — go.mod - dependencies: github.com/ThalesIgnite/crypto11, github.com/miekg/pkcs11. The project includes direct dependencies on miekg/pkcs11 and crypto11 (ThalesIgnite), which provide low-level cryptographic operations. These are prone to misuse if not handled carefully, especially regarding key management and memory protection. Fix: Ensure these are only used in well-controlled contexts with proper key material handling. Implement comprehensive testing for cryptographic operations. Consider using higher-level abstractions where possible. Ensure secure memory handling and key destruction.
• Medium · Open Policy Agent (OPA) Dependency with Complex Attack Surface — go.mod - dependency: github.com/open-policy-agent/opa v1.14.1. The inclusion of open-policy-agent/opa v1.14.1 introduces a large dependency with potential attack surface. OPA evaluates arbitrary policy code which could be a vector for expression injection or denial of service. Fix: Implement strict input validation and sanitization for any user-provided OPA policies. Run OPA in sandboxed/restricted environments if evaluating untrusted policies. Monitor OPA security advisories closely. Consider resource limits (timeout, memory) when evaluating policies.
• Medium · Multiple KMS Provider Dependencies with Varying Security Postures — go.mod - dependencies: sigstore/sigstore/pkg/signature/kms/aws, azure, gcp, hashivault. The project depends on multiple KMS implementations (AWS, Azure, GCP, HashiVault) from sigstore/sigstore. Each has different security models and potential misconfigurations. Inconsistent handling could lead to key exposure. Fix: Implement unified KMS abstraction layer with consistent security controls. Validate KMS configuration in all code paths. Ensure proper error handling that doesn't leak sensitive information. Test all KMS providers in CI/CD pipeline. Document security assumptions for each KMS provider.
• Medium · Protobuf Code Generation from External Specs — go.mod - dependency: github.com/sigstore/protobuf-specs v0.5.1. The sigstore/protobuf-specs dependency requires code generation from protobuf definitions. Malicious or vulnerable protobuf definitions could lead to code generation vulnerabilities. Fix: Pin protobuf-specs to specific versions and review major version changes carefully. Validate generated code before use. Use protobuf schema validation. Monitor for CVEs in protobuf toolchain itself.
• Medium · Go Version Specificity in Dockerfile — Dockerfile. The Dockerfile uses golang:1.25.7 as base image. While specific, this Go version should be verified for security patches and the base image itself should be scanned regularly. Fix: Implement automated scanning of the base image for vulnerabilities. Use multi-stage builds to minimize attack surface. Consider using distroless or minimal base images for final

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sigstore/cosign shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sigstore/cosign repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sigstore/cosign.

What it runs against: a local clone of sigstore/cosign — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sigstore/cosign | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sigstore/cosign. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sigstore/cosign.git
#   cd cosign
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sigstore/cosign and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sigstore/cosign(\\.git)?\\b" \\
  && ok "origin remote is sigstore/cosign" \\
  || miss "origin remote is not sigstore/cosign (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cmd/cosign/cli/commands.go" \\
  && ok "cmd/cosign/cli/commands.go" \\
  || miss "missing critical file: cmd/cosign/cli/commands.go"
test -f "cmd/cosign/cli/load.go" \\
  && ok "cmd/cosign/cli/load.go" \\
  || miss "missing critical file: cmd/cosign/cli/load.go"
test -f "cmd/cosign/cli/fulcio/fulcio.go" \\
  && ok "cmd/cosign/cli/fulcio/fulcio.go" \\
  || miss "missing critical file: cmd/cosign/cli/fulcio/fulcio.go"
test -f "cmd/cosign/cli/attest/attest.go" \\
  && ok "cmd/cosign/cli/attest/attest.go" \\
  || miss "missing critical file: cmd/cosign/cli/attest/attest.go"
test -f "cmd/cosign/cli/options/attest.go" \\
  && ok "cmd/cosign/cli/options/attest.go" \\
  || miss "missing critical file: cmd/cosign/cli/options/attest.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sigstore/cosign"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.