29.1: The Open Source Security Foundation (OpenSSF)¶

Disclaimer: This chapter provides general information about industry initiatives and collaborative efforts to improve open source security. It does not constitute endorsement of specific organizations, projects, or approaches, nor does it constitute professional advice regarding which initiatives to join or support. Organizations should evaluate participation in industry initiatives based on their specific business objectives, resource constraints, and strategic priorities. Participation in industry groups does not substitute for implementing appropriate security controls within your organization.

The discovery of the Log4Shell vulnerability in December 2021 demonstrated a painful truth: the security of the world's software infrastructure depends on projects maintained by small teams with limited resources. While organizations across every industry relied on Log4j for critical applications, the project itself had only a handful of maintainers working largely as volunteers. This disconnect—between the immense value open source provides and the minimal investment in its security—demanded a coordinated response.

The Open Source Security Foundation (OpenSSF) emerged to address exactly this challenge. Launched in August 2020² under the Linux Foundation umbrella, OpenSSF brought together technology leaders, open source communities, and security experts to systematically improve the security of open source software. What began as a coalition of concerned organizations has grown into the most significant coordinated effort to secure the open source ecosystem, producing tools, standards, and programs that benefit projects and consumers alike.

For organizations using open source software—which is to say, virtually all organizations—understanding OpenSSF's work is increasingly essential. OpenSSF projects like Sigstore and SLSA are becoming baseline expectations for supply chain security. OpenSSF guidance shapes emerging regulatory requirements. Engagement with OpenSSF provides opportunities to influence the direction of open source security and to contribute resources where they matter most.

Origins and Governance¶

OpenSSF consolidated several earlier initiatives addressing open source security:

• Core Infrastructure Initiative (CII): Launched after Heartbleed to fund security improvements in critical projects
• Open Source Security Coalition: Industry collaboration on security tooling and practices

By bringing these efforts together, OpenSSF created a more coherent and impactful organization than the fragmented predecessor initiatives could achieve.

Governance structure:

OpenSSF operates as a project under the Linux Foundation, benefiting from established legal, financial, and operational infrastructure. Governance includes:

• Governing Board: Sets strategic direction and budget priorities; composed of premier member representatives and elected community representatives
• Technical Advisory Council (TAC): Oversees technical direction, working group formation, and project lifecycle
• Working Groups: Drive specific technical initiatives with open participation
• Staff: Linux Foundation staff provide operational support

Membership tiers:

Organizations participate through membership at varying levels:

• Premier Members: Major technology companies with board representation (Google, Microsoft, Amazon, Intel, IBM, and others)
• General Members: Organizations committed to open source security with TAC representation
• Associate Members: Non-profit and government organizations
• Individual Contributors: Participate in working groups without organizational membership

OpenSSF emphasizes that technical work is open to all, regardless of membership status. Working groups, mailing lists, and project contributions welcome community participation independent of organizational affiliation.

Working Groups¶

OpenSSF organizes technical work through Working Groups focused on specific problem areas. These groups develop specifications, build tools, produce guidance, and coordinate community efforts.

Active Working Groups include:

Securing Critical Projects: Identifies and prioritizes security improvements for the most critical open source projects. This group develops methodology for assessing project criticality and coordinates resources for high-priority improvements.

Best Practices: Develops guidance and criteria for secure open source development. Produces the Best Practices Badge program, secure development guides, and educational materials.

Vulnerability Disclosures: Improves vulnerability reporting, handling, and disclosure across the ecosystem. Works on standardizing disclosure processes and tools.

Security Tooling: Develops and promotes security tools for open source projects, including Scorecard, Allstar, and other analysis capabilities.

Supply Chain Integrity: Focuses on supply chain security controls including SLSA, Sigstore, and related specifications.

The working group also hosts the Secure Supply Chain Consumption Framework (S2C2F), which provides practices and a maturity model for organizations securely consuming open source dependencies.

Securing Software Repositories: Addresses security of package registries and repositories, working with npm, PyPI, Maven Central, and others.

End User: Represents the perspective of organizations consuming open source software, developing consumption guidance and advocating for end-user needs.

Participating in working groups:

Anyone can participate in OpenSSF working groups:

1. Find working groups of interest on the OpenSSF website
2. Join relevant mailing lists and Slack channels
3. Attend public meetings (schedules published on the OpenSSF calendar)
4. Contribute to working group deliverables through GitHub repositories

Organizations benefit from working group participation through early visibility into emerging standards, influence over direction, and connections with peer organizations addressing similar challenges.

Scorecard¶

OpenSSF Scorecard automates security health assessment for open source projects, evaluating repositories against a set of security-relevant criteria. Scorecard helps both maintainers identify improvements and consumers assess project security posture.

What Scorecard evaluates:

Scorecard runs automated checks against GitHub repositories, scoring projects on a 0-10 scale for each check. Checks include:

Using Scorecard:

# Install Scorecard
go install github.com/ossf/scorecard/v4/cmd/scorecard@latest

# Run against a repository
scorecard --repo=github.com/owner/repo

# Run specific checks
scorecard --repo=github.com/owner/repo --checks=Code-Review,Branch-Protection

Scorecard for maintainers:

Project maintainers use Scorecard to:

• Identify security improvement opportunities
• Track security posture over time
• Demonstrate security practices to users
• Prioritize security investments

Scorecard for consumers:

Organizations evaluating dependencies use Scorecard to:

• Assess project security before adoption
• Compare alternatives on security criteria
• Monitor portfolio projects for security changes
• Incorporate security into selection criteria

Scorecard at scale:

OpenSSF runs Scorecard weekly against the top one million most critical open source projects, publishing results publicly. This data enables ecosystem-wide analysis and powers other tools like deps.dev.

Sigstore¶

Sigstore provides free, easy-to-use tooling for signing, verifying, and protecting software. Sigstore addresses a fundamental supply chain security challenge: verifying that software artifacts come from claimed sources and haven't been tampered with.

Traditional code signing requires managing cryptographic keys—generating them securely, protecting them from compromise, rotating them periodically, and handling revocation when necessary. This complexity has limited adoption of signing, particularly among open source projects with limited resources.

Sigstore components:

Cosign: Signs and verifies container images and other artifacts. Cosign supports "keyless" signing using short-lived certificates tied to identity providers (GitHub, Google, Microsoft), eliminating key management burden.

# Sign a container image (keyless)
cosign sign ghcr.io/owner/image:tag

# Verify a signed image
cosign verify ghcr.io/owner/image:tag

Fulcio: A certificate authority that issues short-lived signing certificates based on OIDC identity. When you sign with Cosign using keyless mode, Fulcio provides the certificate.

Rekor: A transparency log recording all signing events. Rekor provides an immutable, publicly auditable record of signatures, enabling detection of unauthorized signing.

Gitsign: Extends Sigstore to Git commits, enabling keyless commit signing with the same model Cosign uses for artifacts.

Sigstore adoption:

Sigstore has achieved remarkable adoption:

• npm uses Sigstore for provenance attestations
• PyPI implemented Sigstore-based attestations
• Kubernetes signs releases with Sigstore
• GitHub Actions integrates Sigstore for artifact attestation
• Major Linux distributions are exploring Sigstore integration

For organizations building software, Sigstore enables signing artifacts without the overhead of key management. For organizations consuming software, Sigstore verification provides confidence in artifact provenance.

SLSA Framework¶

SLSA (Supply-chain Levels for Software Artifacts), pronounced "salsa," is a security framework establishing progressive levels of supply chain integrity. SLSA provides a common vocabulary for describing supply chain security and a roadmap for improvement.

SLSA Build Track levels (v1.0):

Note: SLSA v1.0 defines three levels for the Build Track. Earlier versions (v0.1) included a Level 4 with two-person review requirements.

SLSA provenance:

SLSA's core artifact is the provenance attestation—a signed statement describing how an artifact was produced:

• What source repository was used
• What commit was built
• What build platform was used
• What build commands were executed
• What dependencies were used

Provenance enables consumers to verify that artifacts match claimed sources and were produced through expected processes.

SLSA implementation:

GitHub Actions, Google Cloud Build, and other platforms provide SLSA provenance generation:

# GitHub Actions workflow with SLSA provenance
jobs:
  build:
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:

      - uses: actions/attest-build-provenance@v1

        with:
          subject-path: 'dist/*'

SLSA's relationship to regulation:

SLSA increasingly appears in regulatory and compliance contexts:

• EU CRA references supply chain integrity controls aligned with SLSA concepts
• U.S. federal guidance references SLSA as implementation framework
• Enterprise procurement increasingly requests SLSA compliance

Organizations adopting SLSA position themselves for emerging compliance requirements while improving actual security.

GUAC and Package Analysis¶

GUAC (Graph for Understanding Artifact Composition) aggregates software security metadata into a queryable knowledge graph. GUAC addresses a fundamental challenge: security metadata exists in many forms (SBOMs, vulnerability data, Scorecard results, SLSA attestations) that are difficult to correlate and query together.

GUAC capabilities:

• Ingests SBOMs, SLSA attestations, Scorecard data, and vulnerability information
• Creates a unified graph connecting artifacts, packages, sources, and vulnerabilities
• Enables queries like "what vulnerabilities affect my software?" or "which artifacts depend on this package?"
• Supports policy evaluation across aggregated metadata

Package Analysis:

The OpenSSF Package Analysis project automatically analyzes packages published to open source registries, detecting malicious behavior. Package Analysis:

• Monitors npm, PyPI, and other registries for new packages
• Runs packages in sandboxed environments
• Detects suspicious behaviors (network connections, file access, credential access)
• Reports findings to registries for action

Package Analysis has identified thousands of malicious packages (with over 15,000 reports in the OpenSSF Malicious Packages repository³), enabling rapid removal before widespread impact. The project demonstrates proactive ecosystem defense at scale.

Alpha-Omega Program¶

Alpha-Omega directly funds security improvements in critical open source projects. Launched in February 2022 with initial backing from Google and Microsoft (later joined by Amazon and Citi), the program addresses the resource gap that leaves critical infrastructure under-maintained. As of 2024, Alpha-Omega has raised approximately $23 million in total funding.⁷ In 2023, Alpha-Omega formalized its governance by becoming a directed fund with an oversight board and defined leadership team, establishing durable accountability structures.

Program structure:

Alpha track: Engages directly with the most critical projects—those that infrastructure everywhere depends on—selected using expert input and data including OpenSSF Criticality Score and Harvard's Census work on critical OSS. Alpha provides dedicated security expertise to work alongside project maintainers through public engagement charters⁴ that specify scope, timeline, named contacts, and bi-monthly progress updates.

Alpha engagements have included:

• Python Software Foundation: Dedicated security staff positions (Security Developer-in-Residence, PyPI Safety & Security Engineer)
• OpenJS Foundation: Security infrastructure, Node.js security improvements, and broader JavaScript ecosystem security
• Ruby Central: Comprehensive security audit by Trail of Bits, trusted publishing implementation
• FreeBSD Foundation: Security audits ($137,500 grant), infrastructure modernization
• Rust Foundation: Secure implementations (Rust TLS), TUF RFC, provenance tracking for top 5,000 crates
• Internet Security Research Group (Prossimo): Memory-safe implementations of critical software
• Linux kernel and Homebrew: Infrastructure hardening, clang hardening work
• Eclipse Foundation: Vulnerability management across 400+ projects, MFA adoption, Sigstore integration
• Apache Software Foundation: Trusted releases platform with attestations and SBOMs

Omega track: Takes a broader approach, using the Omega Analyzer toolchain⁵ (20+ integrated security tools) to analyze thousands of projects and identify vulnerabilities at scale. Omega combines automated analysis, security analysts, and confidential vulnerability reporting to systematically improve security across the long tail of widely-deployed projects.

Strategic approach:

Alpha-Omega's approach has evolved through experience. Early efforts focused on the top 100 most critical projects, but the team found these projects often didn't lack resources or money—their challenges were more fundamental. This led to a shift toward identifying "points of leverage" where targeted investment can catalyze lasting change:⁷

• Making security someone's job: As co-founder Michael Winser notes, "When security is everybody's job, it's no one's job." Funding dedicated security roles within ecosystems—like the Security Developer-in-Residence at Python Software Foundation—brings focus and drives significant progress.

• Starting with audits: Security audits serve dual purposes: identifying vulnerabilities and revealing a project's willingness to engage with security. A project's receptiveness to an audit indicates its security posture more than the findings themselves.

• "Cleaning the beach" rather than the Pacific garbage patch: Early attempts at automated analysis across thousands of projects proved costly and not actionable. The refined approach focuses on specific communities, helping them secure their project and its dependency graph, then encouraging upstream engagement.

• Prioritizing "shovel-ready" work: Alpha-Omega favors projects with clear plans, personnel in place, and short-term measurable impact over funding open-ended research.

• Cross-pollination through roundtables: Quarterly gatherings connect grant recipients—Python, Ruby, Rust, Eclipse, and others—enabling them to learn from each other. The trusted publishing specification, for example, spread from Python to Ruby and Rust through these connections.

The 3Fs framework for dependency management:

Alpha-Omega developed a framework for organizations managing upstream dependencies:

1. Fix it: Engage with upstream projects, contribute patches, or fund vendors to address issues
2. Fork it: Maintain your own version if the original cannot be fixed or maintained securely (recognizing that unmaintained dependencies are essentially hard forks already)
3. Forgo it: Stop using unnecessary or unmanageable packages entirely

For organizations depending on open source, Alpha-Omega funding represents direct investment in the security of your supply chain—and the strategic lessons from three years of operation offer a model for effective ecosystem investment.

Secure Open Source (SOS) Rewards¶

The SOS Rewards program incentivized security improvements in open source projects through financial rewards. Unlike traditional bug bounties that reward vulnerability discovery, SOS Rewards compensated for proactive security improvements.

Eligible improvements include:

• Enabling branch protection and code review requirements
• Implementing continuous integration security testing
• Adding fuzzing coverage
• Improving dependency management
• Enhancing security documentation

Reward structure:

Rewards range from $505 to $10,000+ depending on improvement significance and project criticality. The program focuses on improvements that measurably enhance security posture—the kinds of changes Scorecard evaluates.

Participation:

Developers submit improvement proposals through the SOS Rewards portal, describing the security enhancement and targeted project. Accepted proposals receive funding upon completion verification.

Best Practices Badge¶

The OpenSSF Best Practices Badge (originally CII Best Practices) provides a certification program for open source projects demonstrating security best practices. Projects complete a self-assessment questionnaire covering security-relevant practices, earning badge levels based on their responses.

Badge levels:

• Passing: Meets basic security criteria
• Silver: Meets enhanced security requirements
• Gold: Meets comprehensive security requirements

Assessment areas:

The badge questionnaire evaluates:

• Basic project information and documentation
• Change control practices
• Reporting and vulnerability handling
• Quality and testing practices
• Security practices and coding standards
• Analysis tools and techniques

Badge value:

For maintainers, the badge:

• Provides structured improvement guidance
• Demonstrates security commitment to users
• May be referenced by funding programs and procurement processes

For consumers, the badge:

• Indicates project security maturity
• Enables comparison between projects
• Signals maintainer investment in security

Thousands of projects have participated in the badge program, with a growing number achieving Passing, Silver, and Gold status.

Open Source Project Security (OSPS) Baseline¶

The OSPS Baseline provides a comprehensive set of security requirements for open source projects, organized by maturity level and security domain. Unlike the Best Practices Badge's self-assessment approach, the Baseline defines specific, verifiable controls that projects should implement—and that tools can automatically check.

Baseline Structure:

The Baseline organizes requirements across three maturity levels and eight categories:

Maturity Levels:

• Level 1: Any project with any number of maintainers or users
• Level 2: Code projects with at least 2 maintainers and consistent users
• Level 3: Code projects with large numbers of consistent users

Higher levels require more stringent controls. For example, Level 1 requires a documented security contact, while Level 3 requires private vulnerability reporting mechanisms and VEX documents for known vulnerabilities.

Relationship to Other Frameworks:

A key strength of the OSPS Baseline is its mapping to external regulatory and security frameworks:

Organizations subject to multiple compliance frameworks can use the Baseline as a unified implementation guide, satisfying overlapping requirements through consistent controls.

Automated Verification:

The OSPS Baseline Scanner⁶ enables automated checking of projects against Baseline requirements. Unlike Scorecard's heuristic scoring, the Baseline Scanner evaluates specific, defined criteria—providing clear pass/fail results for each control.

# Example: Running baseline checks against a repository
osps-baseline-scan --repo github.com/owner/project --level 2

Baseline vs. Best Practices Badge:

The two programs are complementary. The Badge provides comprehensive guidance for projects seeking holistic improvement, while the Baseline offers precise, verifiable requirements suited for compliance and automated enforcement.

Adopting the Baseline:

1. Assess current state: Run the Baseline Scanner to identify gaps
2. Target appropriate level: Start with Level 1 requirements for all projects
3. Address high-impact controls: MFA, security contacts, and branch protection provide immediate value
4. Progress incrementally: Advance to higher levels as project maturity and user base grow
5. Leverage framework mappings: Use Baseline compliance to satisfy multiple regulatory requirements

Engaging with OpenSSF¶

Organizations can engage with OpenSSF at various levels:

For all organizations:

1. Use OpenSSF tools: Adopt Scorecard, Sigstore, SLSA, and other tools in your development process
2. Join working groups: Participate in working groups relevant to your interests
3. Contribute to projects: OpenSSF projects welcome contributions of all sizes
4. Provide feedback: Share experiences with OpenSSF tools and standards

For organizations with resources to contribute:

1. Consider membership: Formal membership provides governance participation and supports OpenSSF operations
2. Fund Alpha-Omega: Direct funding improves security of projects you depend on
3. Contribute engineering time: Staff participation in OpenSSF projects amplifies impact
4. Sponsor events and programs: Support community engagement and education

For open source maintainers:

1. Run Scorecard: Assess your project and address findings
2. Pursue Best Practices Badge: Use the badge program as an improvement roadmap
3. Adopt Sigstore: Sign releases to provide artifact integrity
4. Implement SLSA: Generate provenance attestations for your build process
5. Apply for Alpha-Omega engagement: Critical projects may receive direct support

Recommendations¶

We recommend organizations engage with OpenSSF based on their context:

1. Integrate Scorecard into dependency evaluation processes, using scores as input to component selection decisions

2. Adopt Sigstore for artifact signing, taking advantage of keyless signing to enable adoption without key management burden

3. Implement SLSA progressively, starting with Level 1 provenance and advancing as capabilities mature

4. Participate in working groups relevant to your organization's interests and expertise

5. Contribute financially or through engineering time to OpenSSF programs, recognizing that ecosystem security benefits your organization directly

6. Track OpenSSF developments as outputs increasingly inform regulatory requirements and industry expectations

7. Encourage your dependencies to pursue Best Practices Badge and adopt OpenSSF tools

OpenSSF represents the open source community's coordinated response to supply chain security challenges. Organizations that engage with OpenSSF—adopting its tools, contributing to its programs, and participating in its governance—both benefit from and strengthen the ecosystem security that all software depends on.