The Open Source Project Security Baseline, or OSPS Baseline for short, is a new initiative by OpenSSF in an attempt to bolster the security posture of open source software projects.

In other words, the baseline is a framework comprising of the best security practices aligned with international cybersecurity frameworks, standards, and regulations. Having a solid foundation to base on is something important since open source security is a serious matter, covered here at IProgrammer again and again. First, because open source software powers just about anything as we've explored in "European Union Will Pay For Finding Bugs In Open Source Software":

Open Source Software powers everything, from modern servers, to IoT, to the desktops at work and, as it seems, is at the heart of European Union systems too. The European Commission's Open Source Programme Office has decided to offer bug bounties on popular open source software. What better way of acknowledging OSS's importance than by a state-driven sponsorship?

particularly focusing on OpenSSL and the Heartbleed bug.

Second, getting application security right is not easy, as we explored in "The State Of Secure Software Development - Three OpenSSF Courses":

But how do you, as a library or framework or application developer, come up with secure coding rules? Education is what matters and no tool, however powerful, can replace it. Knowing how to write secure code minimizes the exposure and can mitigate the limitations of the tools. The complexity of today's software doesn't just require writing the core code with security in mind. It requires security not as an aftermath of the development process, but as an integral part of the CI/CD pipelines. There's even a new principle out there on that very subject; the intersection of DevOps and Security in DevSecOps. which principle led the Linux Foundation to set up the Open Source Security Foundation (OpenSSF), with the aim of educating developers in:

• Vulnerability Disclosures
• Security Tooling
• Security Best Practices
• Identifying Security Threats to Open Source Projects
• Securing Critical Projects

The new baseline attempt reinforces OpenSSF's vision for secure open source software by helping developers
begin from a common ground set with sensible defaults. Sensible defaults is of course something already employed by tools like Semgrep.

In a 2020 blog post, The future of AppSec and why I joined r2c, cybersec expert, Clint Gibler suggests that:

It’s impossible to find every bug, no matter how advanced your tools are.

Instead he argues the way forward is:

to build secure-by-default libraries and tools that developers can use to prevent entire classes of vulnerabilities by construction, and then make sure developers use them.This is what forward-thinking security teams at companies like Google, Microsoft, Facebook, Netflix, Dropbox, and more believe and have been investing in for years.

For example, modern web frameworks like Django, Ruby on Rails, and others have a number of secure defaults and built-in guardrails that make potentially dangerous tasks safe by default, including context sensitive output encoding (prevent XSS), tight integration with object relational mappers (prevent SQL injection), and more. In my and many others’ opinions, this is why overall web security has improved, not all of the fancy bug finding tools we’ve built.

Chainguard went one step ahead in applying this sensible defaults principle to its container images build with Wolfi, Chainguard’s Linux (un)distribution and build toolchain. As such Wolfi produces container images that meet the requirements of the secure software supply chain; that is images already provided with signing and sensible defaults.

But back to the Baseline's sensible defaults in the form of guidelines. The baseline instead of looking at security practices aligned to coding, it looks at them from a project logistics perspective. That is, it doesn't set the rules for writing bug free secure code or how to avoid bugs, but it revolves around guidelines for version control, the ci/cd pipeline, maintenance and managing. For instance:

Access Control
Access Control focuses on the mechanisms and policies that control access to the project's version control system and CI/CD pipelines. These controls help ensure that only authorized users can access sensitive data, modify repository settings, or execute build and release processes.

• OSPS-AC-01.01

Requirement: When a user attempts to access a sensitive resource in the project's version control system, the system MUST require the user to complete a multi-factor authentication process.

Recommendation: Enforce multi-factor authentication for the project's version control system, requiring collaborators to provide a second form of authentication when accessing sensitive data or modifying repository settings. Passkeys are acceptable for this control.

External Framework Mappings
BPB: CC-G-1
CRA: 1.2d, 1.2e, 1.2f
SSDF: PO3.2, PS1
CSF: PR.A-02
OCRE: 486-813, 124-564, 347-352, 333-858, 152-725, 201-246

As you can see the baseline draws and shares comon ground with other frameworks likse NIST's SSDF, the the European Cyber Resilience Act (CRA) etc.

Build and Release
Build and Release focuses on the processes and tools used to compile, package, and distribute the project's software. These controls help ensure that the project's build and release pipelines are secure, consistent, and reliable, reducing the risk of vulnerabilities or errors in the software distribution process.

• OSPS-BR-01.02

Requirement: When a CI/CD pipeline uses a branch name in its functionality, that name value MUST be sanitized and validated prior to use in the pipeline.

Security Assessment

• OSPS-SA-02.01

Requirement: When the project has made a release, the project documentation MUST include descriptions of all external software interfaces of the released software assets.

Recommendation: Document all software interfaces (APIs) of the released software assets, explaining how users can interact with the software and what data is expected or produced. Ensure this is updated for new features or breaking changes.

Vulnerability Management
Vulnerability Management focuses on the processes and practices used to identify and address security vulnerabilities in the project's software dependencies. These controls help ensure that the project is well positioned to respond to security threats and vulnerabilities in the software.

• OSPS-VM-03 - The project MUST provide a means for reporting security vulnerabilities privately to the security contacts within the project.

Security vulnerabilities should not be shared with the public until such time the project has been provided time to analyze and prepare remediations to protect users of the project.

• OSPS-VM-03.01

Requirement: While active, the project documentation MUST provide a means for reporting security vulnerabilities privately to the security contacts within the project.

Recommendation: Provide a means for security researchers to report vulnerabilities privately to the project. This may be a dedicated email address, a web form, VSC specialized tools, email addresses for security contacts, or other methods.

That's just a few guidelines per category. The rest of the categories include Documentation, Governance, Legal and Quality.

While the framework does not have an obligatory character, i.e required by Goverments for the software to be used in its applications, it's important for projects to adopt it so that they can showcase that they're taking security seriously in employing proactive measures to reduce risk, hence setting themselves considerable for adoption by third parties the likes of Enterprises.

More Information

Open Source Project Security Baseline 

Related Articles

European Union Will Pay For Finding Bugs In Open Source Software

The State Of Secure Software Development - Three OpenSSF Courses

Semgrep - More Than Just a Glorified Grep

Wolfi Linux (Un)Distribution Secures The Software Supply Chain 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info