OpenSSF Launches Open Source Project Security Baseline to Strengthen Software Supply Chain

The Open Source Security Foundation (OpenSSF) announced the initial release of the Open Source Project Security Baseline (OSPS Baseline) this week. This is a new tiered framework designed to help open source projects implement appropriate security measures without drowning in complexity.

Think of the OSPS Baseline as the security equivalent of a home security checklist – but for code. It's a straightforward list of security practices organized into different levels based on project maturity. Baseline answers the question: "What are the minimum security steps I need to take so my project doesn't become tomorrow's cautionary tale?"

The baseline provides:

• Concrete tasks and processes that actually enhance security
• Different requirements based on project size and maturity
• A foundation that aligns with major regulations like the EU Cyber Resilience Act and U.S. National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF)

A Tiered Approach to Security#

The OSPS Baseline provides a tiered approach to security, with each level building upon the previous one:

• Level 1: The universal security floor recommended for any code or non-code project regardless of size or user base
• Level 2: For code projects with at least 2 maintainers and a small number of consistent users
• Level 3: For code projects with a large number of consistent users

Level 1 Requirements: The Universal Security Floor#

The Level 1 baseline includes a set of fundamental security requirements that all open source projects should aim to implement:

Access Control

• Multi-factor authentication for accessing sensitive resources in the project's version control system
• Lowest privilege by default when new collaborators are added
• Primary branch protection to prevent direct commits and branch deletion without enforcement mechanisms and confirmation

Build and Release

• Input parameter validation in CI/CD pipelines
• Encrypted channels for all official project URIs (like using HTTPS instead of HTTP)

Documentation

• User guides for all basic functionality
• Defect reporting guide for users to report issues

Governance

• Public discussion mechanisms for proposed changes and usage obstacles
• Contribution process explanation for potential contributors

Legal

• Open source license that meets the OSI Open Source Definition or FSF Free Software Definition
• License file placement in standard locations (like LICENSE or COPYING files)

Quality

• Public source code repository at a static URL
• Publicly readable change history showing who made changes and when
• Dependency tracking for direct language dependencies
• No executable artifacts in version control system

Vulnerability Management

• Published security contacts for reporting vulnerabilities

Acknowledging the interconnectedness of the open source software supply chain, OpenSSF is recommending that all projects meet Baseline level 1 as a minimum:

All projects are encouraged to adhere to Baseline level 1 at minimum because it establishes a “universal security floor” for all open source, capturing many modern-day expectations for software development in an internationally connected ecosystem amidst modern-day online threats (refer to CNCF’s software supply chain compromise catalog for examples of successful attacks). If you are a foundation that has some level or maturity criteria, we recommend you evaluate your lowest criteria tier for security and adjust to match (where reasonable and appropriate) the level 1 baseline.

Stacey Potter, Independent Open Source Community Manager who helped lead the OSPS Baseline pilot efforts, noted: "We know it can be tough to navigate all the security standards out there, so we built a framework that grows with your project."

How Is This Different from Existing OpenSSF Security Frameworks?#

The introduction of new Baseline requirements may be confusing to those who are already familiar with OpenSSF’s existing Scorecard and the Best Practices Badge initiatives. The new OSPS Baseline initiative attempts to bridge some gaps:

• Unlike Scorecard: It's not just an automated grading tool that might miss context-specific security measures
• Unlike Best Practices Badge: It focuses specifically on security rather than being a general health check
• Unlike many frameworks: It was built by and for open source contributors who understand the realities of maintaining projects.

Adoption and Implementation#

Several projects have already committed to adoption during the pilot phase, including GUAC, OpenVEX, bomctl, and Open Telemetry. Projects can self-attest their compliance with the baseline, with the compliance status being point-in-time.

Ben Cotton, Open Source Community Lead at Kusari & OSPS Baseline co-maintainer, stated: "This effort provides actionable, practical guidance to help developers achieve appropriate security levels for their projects. Too often, security advice is vague or impractical, but Baseline aims to change that."

Balancing Security Standards with Solo Maintainers' Realities#

It is important to note that adoption of the OSPS Baseline is voluntary for open source projects, unless specifically required by a sponsoring organization. The baseline is not intended to be used as a security comparison tool between projects or as a scoring mechanism.

The Level 1 requirements, while designed to establish a "universal security floor," may present implementation challenges for solo maintainers with limited time and resources. This demographic represents the vast majority of open source projects. Multi-factor authentication requirements, branch protection mechanisms, and comprehensive documentation expectations all demand additional effort beyond core development work.

Solo maintainers often operate with significant constraints—many maintain projects as side endeavors alongside full-time employment or other responsibilities. The baseline requirements at Level 1, while security-enhancing, represent administrative overhead that could detract from feature development or bug fixes.

The formalization of security practices through this baseline creates a potential stratification in the open source ecosystem. Projects with organizational backing or multiple contributors can more easily distribute compliance work, while solo maintainers may struggle to meet all requirements. The voluntary nature of the baseline is key here - solo maintainers can implement these practices incrementally as their projects grow in importance and adoption, rather than feeling pressured to comply with all requirements immediately.

For the broader ecosystem, this initiative represents a continuation of the trend toward greater professionalization of open source development. If OSPS gains adoption it could set a new standard for security practices across projects of all sizes, contributing to a more resilient software supply chain.