OpenSSF Explained: Structure, Working Groups, Projects and Guidance

The Open Source Security Foundation (OpenSSF) is a Linux Foundation project, announced on 3 August 2020, that brings companies, maintainers and security people together to make open source software easier to secure. A member-funded Governing Board controls the budget, an elected Technical Advisory Council (TAC) oversees the technical work, and open working groups and projects produce the outputs most teams actually use: SLSA, Sigstore, Scorecard, the OSV schema, the Best Practices badge and a shelf of practical guides.

This guide goes one level deeper than our posts on open source foundation governance models and how the Linux Foundation and Apache approach governance. It is a sister piece to our explainers on the Eclipse Foundation, the Python Software Foundation and the OpenJS Foundation. We read the OpenSSF charter (the version with membership fees effective 1 January 2026), the TAC repository and its project lifecycle process, the Linux Foundation's formation announcement, the Alpha-Omega launch release, and the official documentation for each project we describe. Every rule, stage and date below comes from those sources unless we say otherwise, and where two official sources disagree we say so.

Key takeaways

• OpenSSF was announced by the Linux Foundation on 3 August 2020. It combined the Linux Foundation's Core Infrastructure Initiative (founded after the 2014 Heartbleed bug), the Open Source Security Coalition (founded in 2019) and other open source security work from its founding members.
• It is not a separate legal entity with its own tax status. The charter says OpenSSF operates under the guidance of its Governing Board and the Linux Foundation, and every OpenSSF member must also be a corporate member of the Linux Foundation.
• Money and technical direction are split. The Governing Board approves the budget and can never commit to spend more than has been raised. The TAC (six members elected by contributors, three appointed by the board) approves, structures and archives the technical work.
• Neither the board nor the TAC runs individual projects. OpenSSF's own FAQ says maintainers manage their projects and that membership level never affects project decisions.
• Work happens in working groups (ten listed by the TAC today, one of them archived) and in projects that move through Sandbox, Incubating and Graduated stages. Sigstore, SLSA and the Best Practices badge are Graduated; Scorecard, GUAC, gittuf and Repository Service for TUF are Incubating; model signing and the OSPS Baseline are in Sandbox.
• The guidance you can use without joining anything includes the Concise Guide for Developing More Secure Software, the Compiler Options Hardening Guide for C and C++, the free LFD121 secure development course, the Best Practices badge self-assessment, the OSPS Baseline control catalog and Scorecard.
• Alpha-Omega, launched on 1 February 2022 with an initial $5 million, is the main funding channel tied to OpenSSF. It describes itself today as an associated project of the OpenSSF with an annual budget of over $7 million.
• Participation is open. You do not need to be a member to join a working group, attend a TAC call or contribute to a project.

What is the Open Source Security Foundation?

OpenSSF's about page states its aim plainly: to make it easier to sustainably secure the development, maintenance, release and consumption of open source software. The charter's mission line is shorter: "to inspire and enable the community to secure the open source software we all depend on."

The about page sets out a vision in which producers of open source, at every skill level, can deal with existing and new threats through low friction tooling, education and clear guidance, and consumers get "clear, consistent, and trusted signals" about the security of the open source they pull in. Its strategy has three parts, which it calls being a Catalyst for Change (pushing secure by design and secure by default practices into the tools developers already use), Educate and Empower the Modern Developer (guides and training), and Ecosystem Leader (taking part in standards, frameworks and public policy).

In practice OpenSSF is three things at once:

1. A funding and membership body. Companies pay membership fees, the Governing Board decides how that money is spent, and some of it supports projects, audits, infrastructure and staff.
2. A home for technical work. Working groups, special interest groups and projects produce specifications (SLSA, the OSV schema, Security Insights), tools (Scorecard, Sigstore clients, GUAC) and services (the Sigstore public good instance, the Scorecard weekly scan, the Best Practices badge site).
3. A policy voice. OpenSSF runs a Global Cyber Policy working group and has public policy pages, including one on the EU Cyber Resilience Act.

When was OpenSSF formed, and from which earlier efforts?

The Linux Foundation announced OpenSSF on 3 August 2020 in San Francisco. Its press release described a "cross-industry collaboration" that combined efforts from the Core Infrastructure Initiative (CII), the Open Source Security Coalition and other open source security work from the founding governing board members. The founding board members included large technology and cloud companies, a global bank, a security consultancy and the OWASP Foundation, with more organisations joining as founding members beyond the board.

Two predecessors matter for understanding what OpenSSF inherited:

• The Core Infrastructure Initiative. The press release says the Linux Foundation founded CII "in response to the 2014 Heartbleed bug." CII funded work on critical, under-resourced projects. The CII Best Practices badge is the direct ancestor of today's OpenSSF Best Practices badge, which is why the Scorecard documentation still calls its badge check "CII-Best-Practices" and why the badge code lives in a repository under the coreinfrastructure GitHub organisation.
• The Open Source Security Coalition. Founded in 2019 by a code hosting platform's security research lab, the coalition brought industry people together around threats to the open source ecosystem. Its working documents, including a paper on threats, risks and mitigations in the open source ecosystem, fed into the early OpenSSF working groups.

The same release set up the governance that still exists: a Governing Board, a Technical Advisory Council, and "separate oversight for each working group and project," with the technical work done in the open on GitHub.

OpenSSF timeline

How is OpenSSF governed?

The charter is the source of truth. OpenSSF's about page says so directly, and its strategy "builds on the charter." The charter can be amended by a simple majority of the Governing Board, subject to approval by the Linux Foundation.

Membership tiers and fees

The charter defines three membership classes. All OpenSSF members must be current corporate members of the Linux Foundation at any level, so an OpenSSF membership is always on top of a Linux Foundation membership.

All members may take part in OpenSSF general meetings, initiatives and events, and may display their membership. The charter adds that if an Associate member is itself a membership organisation, its own members get no rights through it.

The Governing Board

Under section 3 of the charter, the Governing Board consists of:

• one primary representative appointed by each Premier member;
• the elected General member representative or representatives;
• one TAC Representative, who is the TAC chair;
• one Associate Member Representative, elected by the board; and
• one Security Community Individual Representative (SCIR), elected by contributors to OpenSSF technical initiatives.

The SCIR seat is the one that gives individual contributors, rather than companies, a direct vote at board level. The Associate and SCIR representatives serve renewable one year terms.

The board's powers include approving election procedures, setting criteria for Associate membership, electing officers and, most importantly, approving a budget for the use of all funds OpenSSF raises. Section 11 says the board "will approve an annual budget and never commit to spend in excess of funds raised," and that the budget must be consistent with the Linux Foundation's non-profit mission. The board may also create committees, which report to it.

The Technical Advisory Council

Section 5 of the charter sets the TAC at nine voting members:

• Six elected annually by all active contributors to technical initiatives, for two year terms in two staggered groups, so three terms expire each year. The charter explains that in the first year of this arrangement (2024), three members were randomly picked to serve a single year so the stagger could begin.
• Three appointed by the Governing Board, for one year terms.

Members that belong to a group of related companies may hold no more than two voting TAC seats between them, which stops a single corporate family from dominating technical oversight.

The charter lists the TAC's responsibilities: develop the technical vision; approve, establish, structure and archive technical initiatives; maintain the onboarding and communication procedures; identify resource and funding needs and recommend priorities to the board; help with crowdfunding for initiatives; elect a chair who also sits on the board; and coordinate other technical community matters.

When we fetched the TAC repository, it listed nine members, three of them marked as appointed by the Governing Board and six elected by the community, with terms ending in December 2026 or December 2027. The TAC repository also says any community member may join TAC discussions, which take place on the TAC mailing list, in a Slack channel and in recorded meetings that are posted publicly. Agenda items are requested through GitHub issues on the ossf/tac repository.

Who actually controls the projects?

This is the question most people get wrong. OpenSSF's FAQ answers it directly: neither the Governing Board nor the TAC manages working groups or projects directly. Maintainers manage them, including how their own governance works. The board is responsible for the budget and the TAC for overall technical strategy.

A second FAQ answer matters for anyone worried about pay to play: membership or sponsorship level does not affect project decisions. "All project-related decisions are made by the project maintainers," and maintainership is decided by the projects "without regard to OpenSSF membership." Participation in technical initiatives is open to anyone, members or not, which the charter also states in its first section.

Governance at a glance

What are the OpenSSF working groups?

Working groups (WGs) are the main unit of OpenSSF's technical work. They meet in public, keep notes in shared documents, and use GitHub repositories under the ossf organisation. The working groups page says they are "open to everyone." Working groups go through their own lifecycle (Sandbox, Incubating, Graduated, Archived), recorded in the TAC repository.

When we fetched it, the TAC repository listed these working groups:

The public working groups page also lists a Japan working group focused on awareness, education and localisation in Japan, which did not appear in the TAC table we fetched. That kind of drift between the website and the TAC repository is normal; treat the TAC repository as the authoritative list of approved initiatives.

What do the working groups actually produce?

A few concrete examples show the range:

• Best Practices publishes the guides at best.openssf.org, including the Concise Guide for Developing More Secure Software, the Concise Guide for Evaluating Open Source Software, the Compiler Options Hardening Guide for C and C++, an npm best practices guide and a guide to correctly using regular expressions for input validation.
• Vulnerability Disclosures maintains coordinated vulnerability disclosure guides for maintainers and finders and a Model Outbound Vulnerability Disclosure Policy. OpenSSF's FAQ says it follows a maximum 90 day public disclosure time limit when it reports issues to others.
• Securing Software Repositories works with package registries on shared problems such as authentication, trusted publishing and abuse handling, and sponsors projects that analyse package behaviour.
• Supply Chain Integrity is the home of SLSA and several provenance and policy projects.
• ORBIT maintains the OSPS Baseline and the Security Insights specification, which lets a project publish machine readable facts about its security practices.

Special interest groups

Special interest groups (SIGs) sit inside working groups and, according to the TAC repository, can be created "without formal approval from the TAC." The TAC list includes CVD Guides and OpenVEX under Vulnerability Disclosures, and Education and Memory Safety under Best Practices. The OSPS Baseline is maintained by a Security Baseline SIG.

Which projects does OpenSSF host, and what do the stages mean?

The project lifecycle

The TAC's "Becoming an OpenSSF Project" document defines four stages. New projects, and every move between stages, are approved by the TAC. Each project reports to a sponsoring working group, which advises on technical direction and recommends the project to the TAC.

Every stage also has to meet the matching "Security Baseline" requirements in the TAC repository, and the lifecycle document notes that badge requirements will be revisited once OSPS Baseline conformance is built into the badge program. Sandbox projects dormant for six months, and Incubating or Graduated projects dormant for nine months, are flagged as good candidates for archiving.

The support grows with stage. Sandbox projects get a sponsor, conference consideration, code of conduct support and newsletter space. Incubating projects may also request OpenSSF budget for security audits or time bound contracting, get vulnerability disclosure help from the Vulnerability Disclosures WG, and can post to the OpenSSF blog. Graduated projects may additionally request budget for sustained maintainer stipends.

Read the naming rule carefully when you evaluate a tool. Only a Graduated project may call itself "OpenSSF ProjectName." A Sandbox project that markets itself as an "OpenSSF project" is stretching the rules, and the stage is the real maturity signal, a point our post on what CNCF sandbox, incubating and graduated mean for security makes for the CNCF's similar ladder.

The project list

When we fetched the TAC repository, it listed these projects and stages. "TBD" means the TAC table had not assigned a stage.

A few of these deserve a sentence each, because they are the ones most teams meet first.

• SLSA (Supply chain Levels for Software Artifacts) is a specification for build integrity. Version 1.2 of the spec, marked "Status: Approved" on slsa.dev, has a Build track with levels L0 (no guarantees), L1 (provenance exists), L2 (hosted build platform) and L3 (hardened builds), and a Source track with levels L1 to L4. The point of SLSA is that it tells you what a build platform and a source control system must guarantee, not which tool to buy.
• Sigstore provides free signing and verification. Its documentation explains that a client such as Cosign creates an ephemeral key pair, proves the signer's identity to the Fulcio certificate authority with an OpenID Connect token, receives a short lived certificate, and records the signing event in a tamper resistant public transparency log. Sigstore's graduation document says adopters include Kubernetes, Helm and Python.
• Scorecard runs automated checks against a repository and scores each from 0 to 10. We covered the checks in depth in what OpenSSF Scorecard is and what it measures.
• OSV schema is the open format for vulnerability records used by many ecosystem advisory databases. The schema site listed version 1.9.2, dated 13 October 2026, and the schema itself follows SemVer so that clients built for an older minor version can still read newer records.
• Model signing applies Sigstore signing to machine learning models; see our post on OpenSSF model signing v1.0.
• gittuf adds a security layer for Git repositories; we wrote about its move to Incubating.

What guidance does OpenSSF publish that teams can use directly?

This is where OpenSSF earns its keep for most engineering teams. None of the following needs a membership, a contract or even an account, apart from the badge site.

The Concise Guide for Developing More Secure Software

Published by the Best Practices WG and dated 14 June 2023 on its page (the guide is updated in place), it is a one page checklist. Highlights that translate directly into engineering tickets:

• Require multi-factor authentication for every developer with commit or merge rights.
• Run a combination of tools in CI to detect vulnerabilities, and do not rely on tools alone.
• Evaluate a package before adding it as a direct dependency, double check its name, and make sure it comes from the correct repository.
• Monitor known vulnerabilities in direct and indirect dependencies and update quickly when one appears.
• Keep dependencies reasonably up to date "after a cooldown." The guide suggests a delay of typically about three days before taking updates that have no known vulnerability, because cooldowns counter most malicious package releases.
• Enforce review before changes are accepted, using protected branches or rulesets.
• Publish a security policy and a reporting contact, and prepare for incoming reports.
• Sign important releases with standard tools; the guide points to Sigstore's Cosign.
• Earn at least the passing level of the Best Practices badge, improve your Scorecard score, and raise your SLSA level.
• Publish and consume SBOMs in SPDX or CycloneDX.
• Budget for a third party security audit; the guide says to expect USD 50,000 or more.
• Prefer memory safe languages, and when you cannot, use compiler hardening flags.

There is a companion Concise Guide for Evaluating Open Source Software for the consumer side of the same decisions.

The Compiler Options Hardening Guide for C and C++

This is the most directly actionable thing OpenSSF publishes for native code. The page we fetched carried a 20 August 2026 revision date. Its TL;DR gives a baseline set of flags for GCC and Clang on Linux that turn on compile time warnings and run time protections:

# Baseline from the OpenSSF Compiler Options Hardening Guide (TL;DR section)
CFLAGS="-O2 -Wall -Wformat -Wformat=2 -Wconversion -Wimplicit-fallthrough \
  -Werror=format-security \
  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 \
  -D_GLIBCXX_ASSERTIONS \
  -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_FAST \
  -fstrict-flex-arrays=3 \
  -fstack-clash-protection -fstack-protector-strong"
LDFLAGS="-Wl,-z,nodlopen -Wl,-z,noexecstack \
  -Wl,-z,relro -Wl,-z,now \
  -Wl,--as-needed -Wl,--no-copy-dt-needed-entries"

# Add for executables:        -fPIE -pie
# Add for shared libraries:   -fPIC -shared
# Add on x86_64:              -fcf-protection=full -fzero-call-used-regs=used-gpr
# Add on aarch64:             -mbranch-protection=standard -fzero-call-used-regs=used-gpr
# Add for production code:    -fno-delete-null-pointer-checks -fno-strict-overflow \
#                             -fno-strict-aliasing -ftrivial-auto-var-init=zero

The guide separates options into two tables. Table 1 options only produce warnings and do not change generated code, so they carry no run time cost. Table 2 options enable run time protections and can affect performance, which is why the guide explains each one and its tradeoffs. It also documents known gaps, such as differences in how Clang and glibc implement fortified functions. Read those notes before you turn every flag on in a performance sensitive build.

Free secure development training (LFD121)

"Developing Secure Software" (LFD121) is a free Linux Foundation course that OpenSSF's guides recommend. The course page lists a price of $0, 16 to 20 hours of material and 90 days of access. It covers secure design, implementation and verification for both open and closed source software, plus how to evaluate and use open source components safely. It is a reasonable baseline for a team that has never had formal secure development training.

The Best Practices badge

The Best Practices badge (bestpractices.dev) lets open source projects "voluntarily self-certify, at no cost" against published criteria at passing, silver and gold levels. Automated analysis fills in many answers and rejects obviously wrong ones. Passing criteria are written in MUST, SHOULD and SUGGESTED language and cover basics such as a described project, a public versioned repository, release notes that identify every publicly known fixed vulnerability with a CVE, a bug reporting process, a vulnerability reporting process, a working build system, an automated test suite with a policy of adding tests for new functionality, compiler warnings or a linter with warnings addressed, and HTTPS for project sites. The badge matters inside OpenSSF itself: Sandbox projects must pass, Incubating projects need silver and Graduated projects need gold.

The OSPS Baseline

The Open Source Project Security Baseline is "a set of security controls that projects should meet to demonstrate a strong security posture," organised by maturity level and category and maintained by the Security Baseline SIG. The current version when we fetched it was v2026.08.28, published with a checklist and a crosswalk to other frameworks. The site tells downstream consumers to state compliance against a specific version and to use only the version labelled current for new compliance work. OpenSSF's own project lifecycle now ties stage requirements to Baseline levels, which is a good sign that it is becoming the common reference.

Scorecard, SLSA, Sigstore and OSV as guidance

The projects are also guidance in their own right. Scorecard's check list (Branch-Protection, Code-Review, Dangerous-Workflow, Pinned-Dependencies, Token-Permissions, Signed-Releases, Vulnerabilities and others) reads as a checklist of repository hygiene. SLSA's level requirements are a checklist for build platforms. Sigstore's documentation explains identity based signing. The OSV schema tells you what a well formed vulnerability record contains.

How does OpenSSF fund security work?

There are three channels.

Membership fees and the OpenSSF budget. The Governing Board approves an annual budget from all revenue. Projects at Incubating and Graduated stage may request budget for security audits and contracting, and Graduated projects may request maintainer stipends. OpenSSF also lists a Technical Initiative Funding page in its community section.

Alpha-Omega. OpenSSF announced Alpha-Omega on 1 February 2022, following a meeting with government and industry leaders at the White House, with an initial investment of $5 million from two large technology companies. The launch release described two halves. "Alpha" would work directly with the maintainers of the most critical open source projects on threat modelling, automated testing, source code audits and fixes, with projects chosen using the Securing Critical Projects working group's research, the Criticality Score and Harvard's Census analysis. "Omega" would apply automated analysis to at least 10,000 widely deployed projects, with analysts triaging the findings and confidentially reporting critical issues.

Today Alpha-Omega's own site describes its mission as catalysing "sustainable security improvements across open source" and says it is backed by a group of technology, cloud, AI and financial companies with an annual budget of over $7 million. It calls itself "an associated project of the Open Source Security Foundation" and the TAC repository lists it as an OpenSSF affiliated project. In other words, Alpha-Omega has its own members, leadership and grant process; it is related to OpenSSF but is not run by the TAC like a working group. Recent grant outcomes it publicises include security audits and trusted publishing work for package registries. The PSF's security roles, described in our PSF explainer, are an example of Alpha-Omega funded positions inside another foundation.

The Mobilization Plan. At the Open Source Software Security Summit II in Washington, DC on 12 and 13 May 2022, the Linux Foundation and OpenSSF gathered developers, industry and US federal agency representatives and agreed a plan with 10 streams of investment. The plan is a statement of priorities agreed at the summit rather than a fund in its own right.

How does OpenSSF compare with CNCF TAG Security, OWASP and CISA?

Teams often meet all four and wonder which one to follow. They are complements, not alternatives, and the table below is about purpose, not ranking.

CISA's roadmap lays out four priorities: establishing CISA's role in supporting open source security, driving visibility into open source usage and risks, reducing risks to the federal government, and hardening the open source ecosystem. The OpenSSF concise guide itself recommends applying the CNCF Security TAG's supply chain guide and OWASP's ASVS, which tells you the organisations see themselves as complementary.

Step by step: apply three OpenSSF outputs to one repository

This walkthrough takes one open source repository hosted on GitHub through three OpenSSF outputs: a Best Practices badge self-assessment, a Scorecard check (locally and in CI), and SLSA Build L3 provenance for release artifacts. It assumes you can push workflows to the repository. Pin every third party action to a full commit SHA in your real workflow; the examples show version tags for readability.

Step 1. Run the Best Practices badge self-assessment

1. Sign in at bestpractices.dev with your GitHub account and choose to add a project. Enter the repository URL.
2. Let the automated analysis prefill answers. It detects things like a license file, HTTPS and the repository URL.
3. Work through the passing criteria in order. For each one choose Met, Unmet or N/A and add a justification or URL. Most failures in practice are documentation gaps: no CONTRIBUTING file, no SECURITY.md with a private reporting route, or release notes that do not list fixed CVEs.
4. Turn each Unmet answer into a ticket. Typical ones are adding a security policy, enabling a static analysis tool in CI, adding warning flags to the build, and documenting how to report vulnerabilities privately.
5. Once you reach passing, add the badge to your README. Then read the silver and gold criteria on the same site and plan the gaps; OpenSSF's own lifecycle uses silver and gold as the bar for its Incubating and Graduated projects.

Treat the badge as a forcing function for documentation rather than a certificate. It is self-assessed, so its value is in the answers you publish, which anyone can read and challenge.

Step 2. Run Scorecard locally, then in CI

Install the CLI and run it against your repository. Scorecard needs a GitHub token to call the API.

# macOS or Linux
brew install scorecard

# A fine-grained or classic token with read access to public repositories
export GITHUB_AUTH_TOKEN=<your token>

# Score every check and show why
scorecard --repo=github.com/your-org/your-repo --show-details

# Or a single check, useful while fixing one area
scorecard --repo=github.com/your-org/your-repo --checks Token-Permissions --show-details

# Container alternative
docker run -e GITHUB_AUTH_TOKEN=$GITHUB_AUTH_TOKEN ghcr.io/ossf/scorecard:latest \
  --show-details --repo=https://github.com/your-org/your-repo

Read the per check scores, not the aggregate. Scorecard's own README warns against relying only on the overall number. Start with the checks its documentation rates High or Critical risk: Dangerous-Workflow and Webhooks (Critical), then Branch-Protection, Code-Review, Token-Permissions, Binary-Artifacts, Signed-Releases, Dependency-Update-Tool, Maintained and Vulnerabilities, which uses the OSV service (High). Pinned-Dependencies and Packaging are rated Medium but are usually quick to fix.

Then add the Scorecard Action so the score updates on every push to the default branch and on a schedule. Create .github/workflows/scorecard.yml:

name: Scorecard supply-chain security
on:
  schedule:
    - cron: '30 1 * * 6'
  push:
    branches: [ "main" ]

permissions: read-all

jobs:
  analysis:
    name: Scorecard analysis
    runs-on: ubuntu-latest
    permissions:
      id-token: write          # required for publish_results
      contents: read
      actions: read
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Run analysis
        uses: ossf/scorecard-action@v2.6.0   # pin to the full commit SHA
        with:
          results_file: results.sarif
          results_format: sarif
          publish_results: true

      - name: Upload artifact
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: SARIF file
          path: results.sarif
          retention-days: 5
      # Optionally add a step that uploads results.sarif to your
      # repository's code scanning dashboard (needs security-events: write).

Three rules from the action's README trip people up. First, publish_results: true needs id-token: write on the job, because the action uses the workflow's OIDC token. Second, when publishing, the Scorecard API enforces workflow restrictions: no workflow level write permissions, only the Scorecard job may hold id-token: write, and no run steps in that job. If you need to act on the results, do it in a separate job that reads the action's outputs. Third, publishing replaces the results from the Scorecard team's weekly public scan with your own, which also enables the README badge.

Fix the findings in small pull requests. The quickest wins are usually setting permissions: read-all or narrower at the top of every workflow, pinning actions by SHA, enabling branch protection with required review, and adding a dependency update tool.

Step 3. Generate SLSA Build L3 provenance for releases

The SLSA project publishes free reusable workflows that generate Build L3 provenance for GitHub Actions builds. The generic generator works for any artifact: you build it, hash it, and hand the hashes to a reusable workflow that runs in an isolated job and signs the provenance through Sigstore.

name: Release with SLSA provenance
on:
  push:
    tags: [ "v*" ]

permissions: read-all

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      hashes: ${{ steps.hash.outputs.hashes }}
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Build
        run: make dist          # produces dist/mytool-linux-amd64
      - name: Generate subject hashes
        id: hash
        shell: bash
        run: |
          cd dist
          echo "hashes=$(sha256sum mytool-linux-amd64 | base64 -w0)" >> "$GITHUB_OUTPUT"
      - uses: actions/upload-artifact@v4
        with:
          name: mytool-linux-amd64
          path: dist/mytool-linux-amd64
          if-no-files-found: error

  provenance:
    needs: [build]
    permissions:
      actions: read      # detect the GitHub Actions environment
      id-token: write    # sign provenance via Sigstore
      contents: write    # upload provenance to the release
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: "${{ needs.build.outputs.hashes }}"
      upload-assets: true

Note that the reusable workflow is referenced by tag, not by SHA. The generator's README says its builders and generators must be referenced by a full version tag of the form vX.Y.Z so that slsa-verifier can verify the trusted builder's ref, and that shorter tags such as v2 make the build fail. Pin your other actions by SHA as usual.

Consumers, and your own deployment pipeline, can then verify the artifact against the provenance with slsa-verifier:

go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@v2.7.1

slsa-verifier verify-artifact mytool-linux-amd64 \
  --provenance-path mytool-linux-amd64.intoto.jsonl \
  --source-uri github.com/your-org/your-repo \
  --source-tag v1.4.0

Verification proves the binary was built by that workflow from that repository at that tag, and that it has not changed since. It does not prove the source code is free of bugs. That is why SLSA sits alongside Scorecard and the badge rather than replacing them.

Step 4. Close the loop

Once all three are in place, wire the outputs together:

• Link your badge entry to the provenance: the badge asks about signed releases and reproducible builds, and you can now answer with a URL.
• Watch the Scorecard Signed-Releases and Packaging checks change after your first release with provenance.
• If the repository builds C or C++, add the compiler hardening flags from the guide above and record the change in the badge's warning flags criteria.
• Add a SECURITY.md that follows the Vulnerability Disclosures WG's CVD guide, then enable private vulnerability reporting on the repository.

Which OpenSSF output to adopt first

Common mistakes

• Treating OpenSSF as a certification body. OpenSSF does not certify products or companies. The badge is self-assessed, Scorecard is heuristic, and SLSA levels are claims about build platforms that consumers verify themselves.
• Assuming members control the projects. The FAQ is explicit that membership level does not affect project decisions and that maintainers govern their own projects. Paying for Premier membership buys a board seat that votes on budget, not on Sigstore's release plan.
• Reading "OpenSSF project" as a maturity guarantee. Only Graduated projects may use that phrase. Check the stage in the TAC repository before you put a Sandbox tool on a critical path.
• Chasing the aggregate Scorecard number. A repository can score well overall while failing Dangerous-Workflow or Token-Permissions. Fix the high risk checks first.
• Publishing Scorecard results without reading the workflow restrictions. A run step or workflow level write permission in the Scorecard job makes publishing fail. Keep the job minimal.
• Pinning the SLSA reusable workflow by commit SHA or a short tag. The generator's README requires a full vX.Y.Z tag so the verifier can check the builder's ref.
• Treating provenance as proof of safety. Provenance proves origin and integrity, not the absence of vulnerabilities. Keep scanning and updating dependencies.
• Turning on every compiler flag blindly. The hardening guide explains performance and compatibility tradeoffs for each run time protection, and some flags differ between GCC and Clang.
• Citing an old Baseline or SLSA version. The Baseline site asks consumers to state the version they comply with, and SLSA's tracks changed between versions. Name the version in your policy.
• Waiting for membership before taking part. Working group calls, Slack and GitHub are open to everyone.

FAQ

What does OpenSSF stand for?

Open Source Security Foundation. It is a project of the Linux Foundation, announced on 3 August 2020, focused on making open source software easier to secure.

Is OpenSSF part of the Linux Foundation?

Yes. The charter says OpenSSF operates under the guidance of its Governing Board and the Linux Foundation, consistent with the Linux Foundation's tax-exempt status, and every OpenSSF member must also be a Linux Foundation corporate member. Charter changes need Linux Foundation approval.

How much does OpenSSF membership cost?

Under the fee schedule effective 1 January 2026, Premier membership is $250,000 a year. General membership ranges from $5,000 for organisations under 100 employees to $50,000 for those with 5,000 or more. Associate membership is free and limited to Linux Foundation Associate members. Linux Foundation membership is a separate, additional fee.

Do I need to be a member to join an OpenSSF working group?

No. OpenSSF's FAQ says any technical effort is open to all and does not require funding to take part. You can join calls, Slack channels and GitHub discussions as an individual.

What is the difference between the OpenSSF Governing Board and the TAC?

The Governing Board controls the budget and is made up mostly of member company representatives, plus the TAC chair and an individual representative elected by contributors. The TAC is the technical oversight body: six members elected by contributors and three appointed by the board, which approves, structures and archives technical initiatives and sets technical vision.

What projects does OpenSSF host?

When we checked, the Graduated projects were Sigstore, SLSA and the Best Practices badge. Incubating projects included Scorecard, GUAC, gittuf and Repository Service for TUF. More than twenty Sandbox projects included model signing, the OSPS Baseline, Security Insights, OpenVEX, Protobom and Minder. The OSV schema is also an OpenSSF project with its stage listed as to be decided.

Is SLSA an OpenSSF project?

Yes. SLSA is a Graduated OpenSSF project sponsored by the Supply Chain Integrity working group. Version 1.0 was released on 18 April 2023, and version 1.2 is approved with a Build track (L0 to L3) and a Source track (L1 to L4).

What is Alpha-Omega and how is it related to OpenSSF?

Alpha-Omega is a funding program announced by OpenSSF on 1 February 2022 with an initial $5 million. It now describes itself as an associated project of the OpenSSF with an annual budget of over $7 million, and it funds security work inside open source projects and foundations. It has its own members and leadership rather than being run by the TAC.

How do I report a vulnerability in an OpenSSF project?

OpenSSF asks reporters to use private vulnerability reporting on the project's GitHub repository where it is enabled, and to email security@openssf.org otherwise. OpenSSF itself follows a maximum 90 day public disclosure time limit when it reports issues to others.

Is the OpenSSF Best Practices badge a certification?

No. Projects self-certify at no cost on bestpractices.dev, with automated checks catching obviously wrong answers. The answers are public, so the value is in the transparency, not in an external audit.

Where Safeguard fits

OpenSSF tells maintainers how to build and publish software more safely and gives consumers signals such as Scorecard results, signed releases and SLSA provenance. What it does not do is tell you which open source components are running in your own services, at which versions, and which of your projects need an upgrade when a new advisory lands in an OSV formatted database. That is the gap Safeguard works in. The Safeguard CLI scans repositories, container images and SBOM files (safeguard scan --dir ., --image, --sbom), writes results as JSON, and matches the components it finds against vulnerability databases. The platform shows which projects contain a given component and version, reachability analysis ranks the vulnerable code paths your application actually calls, and policies and gates evaluated in the platform can stop a known vulnerable version from shipping. The fit is indirect for most of this post: Safeguard does not run OpenSSF projects, does not issue Best Practices badges or Scorecard scores, and is not part of OpenSSF's governance.

You can try the CLI from safeguard.sh/download, with setup steps in the CLI documentation.

Supply chain hygiene still matters after you adopt OpenSSF guidance, because a repository with a perfect badge and signed provenance still pulls a fresh tree of third party dependencies on every build. Provenance tells you where an artifact came from; it does not close the time between a fix being published and that fix reaching your builds, which is what the section below is about.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and the advisory, asks before each command, edits the dependency to the fixed version, runs the install and the tests with your approval, prints a summary and pushes nothing. The same flow applies when Scorecard's Vulnerabilities check flags an unfixed advisory in one of your dependencies: you ask for the upgrade, review each step and keep control of what lands.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then runs a scan from the terminal. If you follow OpenSSF's advice to build releases in controlled environments and keep some source off hosted runners, this is how you scan where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If your team already asks an assistant questions such as "which of our services still ship a component version affected by this OSV advisory," this is how the assistant gets access to your Safeguard data, with the tool list set by you.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• OpenSSF: About
• OpenSSF Charter (PDF, membership fees effective 1 January 2026)
• OpenSSF: Governing Board
• OpenSSF: Technical Advisory Council
• OpenSSF: Members
• OpenSSF: Working Groups
• OpenSSF: Projects
• OpenSSF TAC repository README (members, working groups, projects)
• OpenSSF TAC: Becoming an OpenSSF Project (project lifecycle)
• OpenSSF TAC: SLSA graduation stage document
• OpenSSF TAC: Sigstore graduated stage document
• Linux Foundation: Technology and Enterprise Leaders Combine Efforts to Improve Open Source Security (3 August 2020)
• OpenSSF: Alpha-Omega Project announcement (1 February 2022)
• Alpha-Omega
• OpenSSF: The Open Source Software Security Mobilization Plan
• OpenSSF Best Practices WG: Concise Guide for Developing More Secure Software
• OpenSSF Best Practices WG: Compiler Options Hardening Guide for C and C++
• Linux Foundation Education: Developing Secure Software (LFD121)
• OpenSSF Best Practices Badge Program
• OpenSSF Best Practices Badge: passing criteria
• OSPS Baseline
• OpenSSF Scorecard README
• OpenSSF Scorecard Action README
• SLSA v1.1: Security levels
• SLSA v1.2 specification
• SLSA v1.2: Source track requirements
• slsa-github-generator README
• slsa-github-generator: generic generator documentation
• slsa-verifier README
• Sigstore: Overview
• OSV Schema
• CNCF Security TAG README
• OWASP Foundation: About
• CISA: Open Source Software Security Roadmap

Last reviewed: 24 October 2026. OpenSSF's working group and project lists, stages, TAC membership and fee schedule change over time; check the TAC repository and charter for the current status before relying on a specific detail.