Adoption of OpenSSF's Open Source Project Security Baseline (OSPS Baseline)

[janhalen]

Recommendation

We should consider adopting the Open Source Security Foundation's (OpenSSF) recently released Open Source Project Security Baseline (OSPS Baseline) for our project. This framework provides a structured set of security requirements aligned with international cybersecurity standards and regulations[1][9].

Rationale for Adoption

1. Standardized Best Practices: The OSPS Baseline compiles existing guidance from OpenSSF and other expert groups, outlining tasks, processes, artifacts, and configurations that enhance software development and consumption security[1].

2. Tiered Approach: The framework offers a tiered structure that evolves with project maturity, making it suitable for projects of various sizes and stages[5][8].

3. Alignment with Regulations: Adhering to the Baseline supports compliance with global cybersecurity regulations, such as the EU Cyber Resilience Act (CRA) and NIST Secure Software Development Framework (SSDF)[1][9].

4. Community-Driven: The baseline is defined by open source contributors, maintainers, and technical leaders with decades of experience in open source projects[8].

5. Regular Updates: The OpenSSF plans to update this framework regularly to address evolving cybersecurity threats[5].

Benefits of External Standards

1. Expertise: By leveraging externally maintained standards, we benefit from the collective expertise of security professionals and the open source community[1][9].

2. Resource Efficiency: Adopting an established framework saves us time and resources that would otherwise be spent developing and maintaining our own standards[5].

3. Consistency: Using a widely-recognized baseline ensures consistency with other open source projects, making it easier for contributors and users to understand our security practices[8].

4. Credibility: Adhering to respected external standards enhances our project's credibility and trustworthiness among potential adopters and contributors[3].

Implementation Suggestion

We should review the OSPS Baseline and determine which maturity level (1, 2, or 3) is appropriate for our project based on our current size and user base[7]. Once decided, we can create a plan to implement the required security measures and consider using a self-attestation statement to demonstrate our compliance[8].

By adopting the OSPS Baseline, we can improve our project's security posture, align with industry best practices, and contribute to a more secure open source ecosystem.

Citations:
[1] https://www.helpnetsecurity.com/2025/02/28/osps-baseline-practical-security-best-practices-for-open-source-software-projects/
[2] https://baseline.openssf.org/versions/2025-02-25
[3] https://www.securityweek.com/openssf-releases-security-baseline-for-open-source-projects/
[4] https://media.defense.gov/2023/Dec/11/2003355557/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN%20RECOMMENDED%20PRACTICES%20FOR%20MANAGING%20OPEN%20SOURCE%20SOFTWARE%20AND%20SOFTWARE%20BILL%20OF%20MATERIALS.PDF
[5] https://devops.com/openssf-defines-baseline-for-securing-open-source-software/
[6] https://github.com/ossf/scorecard
[7] https://github.com/ossf/security-baseline
[8] https://www.infoq.com/news/2025/03/openssf-security-baseline/
[9] https://openssf.org/press-release/2025/02/25/openssf-announces-initial-release-of-the-open-source-project-security-baseline/
[10] https://www.youtube.com/watch?v=qXeEl9ZWgj0

[janhalen]

The projects adopting the standard could be branded with a "badge" in the README.

#49

[zorp]

I think the first step could be to make it visible by mentioning it as part of an operationalize guide. This could be something we point at frem the demand F4. That way we will point at a standard already on sandbox level.