The Open Source Security Foundation now runs eight named technical initiative areas — AI/ML Security, Compliance, Developer Best Practices, Fuzzing, Repository Security, SBOM Tools, Software Supply Chain, and Vulnerability Disclosures — plus four active working groups spanning AI/ML Security, Global Cyber Policy, Supply Chain Integrity, and Vulnerability Disclosures, according to OpenSSF's own project listing at openssf.org. Its homepage currently headlines four flagship efforts: GUAC for correlating supply-chain metadata into actionable insight, OSPS Baseline for mapping security requirements to international frameworks, Sigstore for signing and verifying software, and SLSA for safeguarding artifact integrity end to end. That's a lot of surface area for a security team that just wants to know what to do on Monday morning. Scorecard — OpenSSF's automated repository health checker, which has run against hundreds of thousands of open-source projects and feeds risk signals directly into deps.dev and Google's Open Source Insights — isn't even on that current homepage list, despite being one of the foundation's most widely deployed tools, which itself says something about how fast this space moves. This post cuts through the initiative sprawl and gives you a practical order of operations: what SBOM, Scorecard, and Sigstore actually do, what they cost to adopt, and which one to start with given your stack today.
What is OpenSSF actually prioritizing right now?
OpenSSF describes itself as a community of developers, security engineers, and researchers "working together to secure open source software for the greater public good," and its current structure reflects a shift from writing standards to operationalizing them. The four homepage flagship projects — GUAC, OSPS Baseline, Sigstore, and SLSA — represent a move toward correlation and enforcement rather than one-off scanning: GUAC exists specifically to stitch together SBOMs, vulnerability feeds, and provenance data into a single queryable graph, because raw SBOMs sitting in a folder answer almost no questions on their own. OSPS Baseline, meanwhile, is OpenSSF's attempt to give compliance teams one structured checklist that maps to multiple regulatory frameworks at once, rather than re-deriving controls for each one. Alongside the flagships, OpenSSF runs a free security training certificate program, the "What's in the SOSS?" podcast, and periodic research reports on cyber resilience — signaling the foundation is investing as much in practitioner education as in tooling itself.
What does SBOM tooling actually require of a team?
An SBOM (Software Bill of Materials) is a structured, machine-readable list of every component in a piece of software — in practice, one of two formats: CycloneDX or SPDX. Executive Order 14028 pushed SBOMs into federal procurement in May 2021, and while OMB's 2026 guidance relaxed the government-wide mandate into an agency-by-agency, risk-based choice, the NTIA's minimum-elements guidance (supplier name, component name, version, dependency relationships, timestamp, and unique identifiers like PURLs) has stuck around as the de facto baseline vendors are measured against, federal contract or not. The practical failure mode isn't generating an SBOM once — most build tools can do that in under a minute for a small project — it's keeping it current. A point-in-time SBOM answers "what did we ship on release day" but not "are we affected by the CVE disclosed this morning," which is the question that actually matters. Teams that treat SBOM generation as a CI step tied to every build, rather than a quarterly compliance exercise, are the ones who can answer that second question in minutes instead of days.
Why does Scorecard matter even though it doesn't fix anything?
OpenSSF Scorecard runs roughly 20 automated checks against a repository — branch protection, whether CI runs on pull requests, presence of a security policy, use of pinned dependencies, whether maintainers have 2FA enabled — and produces a single risk score from 0 to 10. It doesn't patch anything and it doesn't stop an attack; what it does is turn "is this dependency trustworthy" from a judgment call into a queryable signal, which is exactly why deps.dev and Google's Open Source Insights surface Scorecard results for hundreds of thousands of packages. The practical value shows up at decision time: when a team is choosing between two libraries that do the same thing, or auditing an existing dependency tree for weak links, Scorecard gives a defensible, repeatable answer instead of a gut check. Its limitation is equally important to name — a high score reflects repository hygiene, not the absence of vulnerabilities, so it belongs alongside SCA and reachability analysis, not in place of them.
What problem does Sigstore actually solve?
Sigstore solves the "how do I know this artifact came from where it claims to" problem without forcing every open-source maintainer to manage a private key for the rest of their life — historically the single biggest reason artifact signing never reached mass adoption in open source. Instead of long-lived keys, Sigstore's Fulcio component issues short-lived certificates bound to a workload identity (a GitHub Actions OIDC token, for example), and every signature gets recorded in Rekor, a public, append-only transparency log anyone can audit later. That keyless model is why npm publish --provenance and PyPI's Trusted Publishing both build on Sigstore under the hood — it made signing something a CI pipeline does automatically rather than something a human does manually and inevitably skips. Safeguard's own attestation pipeline signs build artifacts through Sigstore Fulcio by default and publishes to Rekor, with an X.509/Notation path available for regulated environments that require traditional PKI instead — the same tradeoff Sigstore was built to make optional rather than mandatory.
How should a team sequence adoption without a rewrite?
Start with SBOM generation wired into CI, because it's the lowest-friction step and every other initiative depends on having accurate component data to work from — Safeguard generates CycloneDX SBOMs automatically from source, containers, and manifests via a single safeguard sbom generate command, with daily continuous scanning layered on top so new CVEs get matched against your existing inventory instead of triggering a fresh scan. Next, run Scorecard against your dependency tree to find the specific packages with weak maintenance signals — unpinned releases, no branch protection, single maintainer — and treat that as a prioritized replacement or pinning list, not a blocking gate on day one. Only then move to signing: retrofitting Sigstore into an existing release pipeline is a config change to the CI workflow, not an architecture change, and it's the step that turns "we have an SBOM" into "we can prove this SBOM matches this exact build." Doing these in reverse order — signing artifacts you can't yet enumerate the contents of — is how supply-chain programs stall before they start.
How Safeguard fits into this stack
Safeguard doesn't ask a team to adopt OpenSSF's priorities as three separate tools bolted together — SBOM generation, EO 14028 / NTIA minimum-element validation, and Sigstore-backed signing run as one connected pipeline. SBOMs generate automatically on every build in CycloneDX or SPDX format and are validated against NTIA's minimum elements and SSDF alignment out of the box, so compliance status is a live dashboard rather than a report someone assembles before an audit. Every artifact gets a SLSA provenance attestation — Levels 1 through 4 depending on build environment — signed via Sigstore Fulcio with Rekor transparency logging by default, or through X.509/Notation where a regulated environment requires it. That means the SBOM, the vulnerability snapshot at build time, and the signed provenance travel together as one verifiable bundle, which is the actual end state OpenSSF's SBOM, Sigstore, and SLSA priorities are all pointing toward — just without the integration work of stitching three separate open-source tools into a pipeline yourself.