WOSS
What Is the OpenSSF? Securing the Software Everyone Depends On
Aman Mundra · 2026-07-11 · 4 min read
Contents
TL;DR - The Open Source Security Foundation (OpenSSF) is the Linux Foundation's cross-industry initiative to improve the security of the open source software the whole world runs on - from supply-chain integrity to secure development practice. Its flagship projects are Sigstore (keyless code signing), Scorecard (automated security health metrics), and SLSA (a supply-chain integrity framework). If your software is mostly other people's open source - and it is - these are the tools that let you trust it.
Here is an uncomfortable truth about modern software: you did not write most of it. A typical application is a thin layer of your own code sitting on a mountain of open-source dependencies, each with its own dependencies, assembled by a build pipeline, and shipped as an artifact. Every link in that chain is a place an attacker can inject something malicious - and supply-chain attacks have become one of the most effective ways to compromise software at scale. The OpenSSF exists to harden that chain.
What the OpenSSF is
Founded in 2020 as a Linux Foundation initiative, the OpenSSF is a cross-industry collaboration - a sibling of the CNCF and the PyTorch Foundation under the same neutral roof - focused on one problem: making the open-source ecosystem, which everyone depends on and no single company owns, more secure. It does this not by writing security policy documents but by shipping practical tooling and measurable standards.
Three projects do most of the work, and they fit together as complementary layers of a single answer to "can I trust this artifact?"
Sigstore: signing without the key-management nightmare
Code signing is an old idea with a fatal practical flaw: managing signing keys is painful, and mismanaged keys are worse than no keys. Sigstore removes the keys. It provides keyless signing - instead of guarding a long-lived private key, a developer authenticates via their existing identity (OIDC), and Sigstore issues a short-lived certificate tied to that identity. Three components make it work:
- Cosign signs and verifies container images and artifacts.
- Fulcio is a certificate authority that issues those short-lived, identity-bound certificates.
- Rekor is a public transparency log that permanently records every signing event, so anyone can audit what was signed, by whom, and when.
The result is that verifying an artifact's origin becomes cheap and routine rather than a specialist chore.
Scorecard and SLSA: measuring and proving
Scorecard answers "is this project following good security practices?" automatically. It runs a battery of checks (18+ of them: branch protection, code review, dependency hygiene, CI/CD security, fuzzing, vulnerability disclosure) and produces a score. Point it at any repository and you get an objective, comparable read on its security posture - invaluable when you are deciding whether to take on a dependency.
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is the framework that ties it together. It defines provenance levels, from L1 up to L3, describing how much you can trust that an artifact really came from the build you think it did. L2 adds signed provenance; L3 requires build isolation and verified authenticity. Contributed to the OpenSSF in 2021 and now at specification v1.2, it gives teams a concrete ladder to climb rather than a vague aspiration to "secure the pipeline."
A 2026 supply-chain incident made the value of that ladder vivid: an npm attack managed to publish malicious packages carrying cryptographically valid provenance attestations - but the build platform behind them did not meet SLSA Build L3's isolation requirement, and a platform that did would have blocked the attack's primary vector. Signed provenance alone was not enough; the isolation that L3 demands was the missing control. It is a sharp reminder that these frameworks describe real, differentiated levels of assurance, not checkbox theater.
Why it matters
The OpenSSF is where the security hygiene lives that makes any open-source contribution credible. As you ship code into projects others depend on, holding your own repositories to a published supply-chain bar - a passing Scorecard, signed releases via Sigstore, a known SLSA level - is how you earn trust rather than merely assert it. And for anyone consuming open source, which is everyone, these tools turn "I hope this dependency is safe" into "I can verify it." That shift, from hope to verification, is the whole point.
