Technical Deep Dive
The pstoeckle/cosign-test repository is built on top of two key technologies: Sigstore and Cosign. Sigstore is a non-profit, open-source project that provides a public, transparent, and auditable system for signing and verifying software artifacts. Cosign is its primary CLI tool for container image signing, verification, and storage.
Architecture & Workflow:
The core workflow demonstrated in this repo is straightforward:
1. Build: A Docker image is built from a Dockerfile (or pulled from a registry).
2. Sign: The Cosign CLI signs the image digest using a keyless signing method. This leverages an OpenID Connect (OIDC) token from GitHub Actions (the `id-token: write` permission). Cosign exchanges this token with Sigstore's Fulcio certificate authority, which issues a short-lived signing certificate. The signature and certificate are then uploaded to Sigstore's Rekor transparency log, creating a publicly verifiable record.
3. Verify: A subsequent step or a separate workflow uses Cosign to verify the signature against the image. The verification checks the certificate chain, the identity embedded in the certificate (e.g., the GitHub repository and workflow name), and the Rekor entry.
Keyless Signing vs. Traditional Key-Based Signing:
Traditional signing requires generating, storing, and protecting a private key—a major friction point for developers. Keyless signing eliminates this by using ephemeral, short-lived certificates tied to the CI/CD identity. This means:
- No key management overhead.
- No risk of key compromise (keys are ephemeral).
- Automatic revocation (certificates expire quickly).
- Strong, auditable identity binding (the signer's identity is the GitHub Actions workflow run).
Engineering Details:
The repository uses a standard GitHub Actions YAML file. Key steps include:
- Setting permissions: `id-token: write` (required for OIDC token generation).
- Installing Cosign: Typically via a `cosign-installer` action or a simple `curl` command.
- Signing command: `cosign sign --yes <IMAGE_URI>` (the `--yes` flag bypasses confirmation prompts).
- Verification command: `cosign verify --certificate-identity <EXPECTED_IDENTITY> --certificate-oidc-issuer https://token.actions.githubusercontent.com <IMAGE_URI>`.
Relevant Open-Source Repositories:
- sigstore/cosign (GitHub stars: ~4.5k): The core tool for signing and verifying artifacts. It supports OCI images, blobs, and more. Recent updates include improved support for multi-architecture images and enhanced verification policies.
- sigstore/fulcio (GitHub stars: ~1.2k): The certificate authority that issues short-lived certificates based on OIDC tokens.
- sigstore/rekor (GitHub stars: ~1.1k): The transparency log that records all signatures, enabling public auditability.
- sigstore/gitsign (GitHub stars: ~1.0k): A related tool for signing Git commits using Sigstore.
Performance & Benchmark Data:
| Operation | Time (seconds) | Notes |
|---|---|---|
| OIDC token generation | < 1 | Automatic in GitHub Actions |
| Cosign install | 2-5 | Depends on network and runner |
| Cosign sign (keyless) | 3-8 | Includes Fulcio certificate issuance and Rekor upload |
| Cosign verify | 1-3 | Requires network access to Rekor |
Data Takeaway: The overhead of signing and verification is minimal (under 10 seconds total) compared to typical build times (often minutes). The trade-off is a slight increase in build time for a significant security gain.
Key Players & Case Studies
The primary players in this ecosystem are Sigstore (the open-source project) and GitHub (the CI/CD platform). The pstoeckle/cosign-test repository is a community-driven example, but its underlying technology is backed by major industry players.
Sigstore:
- Founded by: The Linux Foundation, with initial contributions from Google, Red Hat, and Purdue University.
- Goal: To make software signing ubiquitous and easy.
- Adoption: Sigstore has been adopted by major projects like Kubernetes (for signing release artifacts), Python (PyPI), and npm (experimental).
- Funding: Supported by the OpenSSF (Open Source Security Foundation) and individual donations.
GitHub:
- Role: Provides the CI/CD runtime (GitHub Actions) and the OIDC identity provider.
- Strategy: GitHub has been pushing supply chain security features heavily, including Dependabot, secret scanning, and now native integration with Sigstore. They have a dedicated team working on artifact attestations.
- Track Record: GitHub's Actions platform has become the de facto standard for CI/CD in the open-source world, with over 50 million workflows run per month (as of 2024).
Comparison of Signing Solutions:
| Feature | Cosign (Sigstore) | Notary v2 | In-toto |
|---|---|---|---|
| Key management | Keyless (OIDC) | Key-based | Key-based |
| Transparency log | Rekor (public) | Optional | None |
| Identity binding | CI/CD identity (e.g., repo) | User identity | User identity |
| Ease of adoption | High (no key setup) | Medium | Low (complex policy) |
| GitHub Actions support | Native (OIDC) | Manual | Manual |
| Community adoption | High (Kubernetes, Python) | Low | Medium (TUF) |
Data Takeaway: Cosign's keyless approach gives it a significant advantage in ease of adoption, especially for teams already using GitHub Actions. Notary v2 and in-toto are more powerful for complex policy scenarios but require more upfront investment.
Case Study: Kubernetes Release Process
Kubernetes uses Cosign to sign all its release artifacts (binaries, images, SBOMs). The signing is done via a GitHub Actions workflow that runs during the release process. This ensures that every official Kubernetes release is verifiable by anyone. The adoption has been a model for other CNCF projects.
Industry Impact & Market Dynamics
The pstoeckle/cosign-test repository is a microcosm of a larger trend: the democratization of software supply chain security. The market is being driven by several factors:
1. Regulatory Pressure: Executive Order 14028 (Improving the Nation's Cybersecurity) in the US, and similar regulations in the EU, mandate software attestation and supply chain security for government software vendors. SLSA (Supply-chain Levels for Software Artifacts) is becoming a de facto standard.
2. High-Profile Breaches: The SolarWinds (2020), Codecov (2021), and Log4j (2021) incidents have made supply chain security a board-level concern.
3. Shift-Left Security: Organizations are moving security earlier in the development lifecycle, and signing is a natural part of that.
Market Growth:
| Metric | 2023 | 2024 (est.) | 2025 (est.) |
|---|---|---|---|
| Global software supply chain security market size | $4.5B | $6.2B | $8.5B |
| Percentage of organizations using artifact signing | 15% | 25% | 40% |
| GitHub Actions workflows using Cosign | <1% | 3% | 10% |
Data Takeaway: The market is growing rapidly, but adoption of signing is still low. Repositories like pstoeckle/cosign-test are crucial for bridging the gap between awareness and action.
Competitive Landscape:
- Sigstore/Cosign: The open-source leader, especially for container images.
- AWS Signer: Amazon's managed signing service, integrated with ECR and CodeBuild.
- Azure Code Signing: Microsoft's service for signing code and containers.
- Google Cloud Artifact Registry: Supports signing via Cosign and KMS.
- Commercial vendors: Chainguard (offers a managed Sigstore platform), Snyk, Aqua Security, and others are building supply chain security products.
AINews Insight: The open-source nature of Sigstore, combined with its backing by the Linux Foundation, gives it a strong position. However, managed services from cloud providers may win in enterprise environments where compliance and support are critical. The pstoeckle/cosign-test repository is a great starting point, but teams should evaluate whether they need a fully managed solution for production.
Risks, Limitations & Open Questions
While the pstoeckle/cosign-test repository is a useful demo, there are several risks and limitations to consider:
1. Rekor Transparency Log Privacy: All signatures are recorded in a public, immutable log. This means anyone can see which images your organization is signing, which could leak information about your software inventory. Sigstore is working on private Rekor instances, but they are not yet widely available.
2. OIDC Token Security: The security of keyless signing relies entirely on the security of the OIDC token. If an attacker gains access to the GitHub Actions workflow (e.g., via a compromised dependency), they can sign malicious images with your identity. This is a valid concern, though it is mitigated by the ephemeral nature of the tokens.
3. Verification Complexity: While signing is easy, verification can be complex. You need to specify the expected identity (e.g., `https://github.com/myorg/myrepo/.github/workflows/build.yml@refs/heads/main`). If this identity changes (e.g., branch rename), verification will fail. This can lead to operational friction.
4. Dependency on GitHub: The keyless flow is tightly coupled to GitHub's OIDC provider. If you move to another CI/CD platform (e.g., GitLab CI, Jenkins), the setup will be different. GitLab and others do support OIDC, but the integration is not as seamless.
5. Limited Scope: The demo only covers container image signing. Real-world supply chain security requires signing many artifact types: binaries, libraries, SBOMs, attestations, and Git commits. Cosign supports these, but the demo does not cover them.
6. False Sense of Security: Signing alone is not a silver bullet. It must be combined with other practices like dependency scanning, SBOM generation, and policy enforcement (e.g., via Kyverno or OPA).
Open Questions:
- How will the community handle the privacy implications of public Rekor logs?
- Can keyless signing be made truly cross-platform (e.g., GitLab, Jenkins, CircleCI) without sacrificing ease of use?
- Will enterprises accept the risk of OIDC token compromise, or will they demand hardware-backed keys?
AINews Verdict & Predictions
The pstoeckle/cosign-test repository is a valuable, if minimal, educational resource. Its true value is not in the code itself but in the pattern it establishes: making security tooling accessible to everyday developers. This is exactly what the industry needs to move the needle on supply chain security.
Our Predictions:
1. By the end of 2026, keyless signing via Cosign will become the default for all GitHub-hosted open-source projects. GitHub will likely make it a one-click feature in their UI, similar to how they integrated Dependabot. The pstoeckle/cosign-test pattern will be obsolete because the platform will handle it automatically.
2. Private Rekor instances will become a paid feature offered by cloud providers. Organizations that need privacy will pay for managed Sigstore services (e.g., Chainguard, AWS Signer) rather than running their own infrastructure.
3. The next major supply chain attack will exploit a weakness in OIDC token handling. This will lead to a new wave of security research and hardening around CI/CD identity. The pstoeckle/cosign-test demo does not address this risk, but future versions of Cosign will likely add additional safeguards (e.g., requiring multiple signatures for critical releases).
4. The concept of 'signing' will expand beyond containers to include all artifacts in the software supply chain. Repositories like this one will need to evolve to cover signing of SBOMs, attestations, and even individual commits (via Gitsign).
What to Watch:
- Sigstore's roadmap: Look for features like policy-based signing, multi-party approval, and integration with hardware security modules (HSMs).
- GitHub's artifact attestations: GitHub is building a feature called 'artifact attestations' that will deeply integrate Sigstore into the Actions platform. This will likely make the manual setup in pstoeckle/cosign-test unnecessary.
- OpenSSF's SLSA framework: As SLSA levels become more widely adopted, tools like Cosign will be essential for achieving higher levels (SLSA 3+).
Final Verdict: The pstoeckle/cosign-test repository is a good starting point, but it is not production-ready. Teams should use it to learn the concepts, then invest in a more robust solution (either open-source with proper policy management or a managed service) for their actual deployments. The future of software supply chain security is automated, transparent, and keyless—and this repo points in the right direction.