It's been a while since I've shared an update on the work Sonatype is doing in the open source ecosystem, so I'm excited to share an update on a few things we're doing in the space — and how it led to the creation of a new security standard in the Open Source Security Foundation (OpenSSF).
The Open Source Project Security (OSPS) Baseline is a set of criteria that help open source maintainers who want to improve their project's security hygiene. It's the culmination of focused effort from folks across the ecosystem, reflected in a strong team of maintainers from four different organizations collaborating almost daily for nearly a year.
The context that shaped the work includes insight from the widely adopted Best Practices Badge, Scorecard, and CLOMonitor.
But the origin story — in a way — is quite a bit longer.
Bridging open source communities
When I first started working at Sonatype in our Developer Relations program, I was a maintainer for an emerging Fintech Open Source Foundation (FINOS) project related to the creation of cybersecurity policies and tooling for financial services. At the same time, I was asked to support Cloud Native Computing Foundation (CNCF) projects by overseeing a Sonatype-hosted event designed to improve project security.
As I transitioned into the Office of the CTO to lead our small Open Source Program Office, my engagement with the open source community became a core part of my role. I was soon invited to steer the FINOS Common Cloud Controls project and appointed as co-chair of CNCF's Technical Advisory Group for Security, on top of my other Sonatype open source responsibilities.
In early 2024, the open source world was understandably concerned about the development of the European Union's Cyber Resilience Act (CRA) — which stood ready to transform the face of how open source software is created and used.
Fortunately, many of our friends at the Eclipse Foundation, Linux Foundation Europe, and OpenSSF were actively involved in providing feedback to shape the formation of the CRA. Sonatype's CTO Brian Fox and my teammate Jeff Wayman have been at the center of many such discussions, such as the Atlantic Council's recommendations for open source policy and OpenSSF's response to efforts from the United States federal government.
The birth of the idea
With these concepts in mind, I watched as the FINOS and CNCF Technical Oversight Committees (TOC) both began to raise issues around project security hygiene requirements. Drawing on my recent experience leading the 2023 CNCF Security Slam followed by a special "Lightning Round" for Kubernetes sub-projects, I was effectively an evangelist for CLOMonitor — the project analysis platform at the heart of the Slam events.
Although CLOMonitor is primarily tailored for CNCF projects, I was intoxicated by the idea of rapid visibility to any project's status on a shortlist of best security practices. I would walk around conference floors with the CLOMonitor dashboard open on my phone — in just three clicks I could show you how any CNCF project's security compared to others using a few core metrics.
But it wasn't just me getting excited about this. Every maintainer I recall speaking with was instantly enthralled when they saw a dashboard with their project logo beside a security score that they could easily improve.
At this point, things began to culminate — my experience writing security controls in FINOS, evangelizing security standards in CNCF, and observing the rise of open source regulations through efforts from my team at Sonatype.
I was chatting with friends on the conference floor of the 2024 CloudNativeSecurityCon in Seattle when I heard about an effort to create a security baseline for all OpenSSF projects.
After the conference while travelling to visit family, I had an introductory call with Dana Wong, then Chief Architect for OpenSSF. I remember standing in my cousin's little kitchen when I floated the idea:
"What if the security baseline isn't specific to a single foundation like CNCF's CLOMonitor or this new initiative from OpenSSF? What if we had one set of controls that apply to FINOS, CNCF, OpenSSF, and every other open source project in the world?"
It was a lofty goal. How could we align the needs of all three foundations, not to mention everyone in the world?
But Dana accepted the challenge. She took the idea back to propose an OpenSSF project to host the work, while I worked to garner support from FINOS and CNCF.
Establishing the OSPS Baseline
In less than a month, we launched the first strategy session with representatives from all three of those foundations and beyond. I was soon joined by the multi-talented Christopher "CRob" Robinson, the incoming Chief Security Architect at OpenSSF.
After consolidating suggestions from OpenJS Foundation, feedback from CNCF's TOC, requests from the FINOS Governing Board, and contributions from across OpenSSF, a core maintainer team emerged.
Among countless other skills, CRob brought years of professional experience examining and mapping controls to security frameworks. Adolfo "Puerco" Veytia Garcia brought nearly a decade of insight as the release lead for Kubernetes. David Wheeler carried the context of a thousand debates behind the creation of the Best Practices Badge. And Ben Cotton brought the drive and tenacity corresponding to years of experience contributing open source projects.
Our GitHub history, meeting notes, and personal trauma bear the marks of close collaboration to hone our shared vision, build proposals, refine content, and incorporate community feedback. The resulting document is a three-tiered set of testable controls with background context and recommended implementations for each.
We believe that this detailed but system-agnostic approach will be useful for maintainers looking to make everyday improvements as well as stewards or open source manufacturers looking to improve compliance with regulatory requirements such as those set forth in the Cyber Resilience Act.
Each criteria is assigned a maturity level, enabling maintainers or stewards (such as a parent foundation) to determine the appropriate controls for each project:
-
Level 1: for any code or non-code project with any number of maintainers or users
-
Level 2: for any code project that has at least 2 maintainers and a small number of consistent users
-
Level 3: for any code project that has a large number of consistent users
Examples of the criteria include obviously security-related elements such as multi-factor authentication, but also less obvious elements such as a requirement for user guides. The first type of criteria are focused on the project's role in a user's supply chain. The second type is intended to ensure that users are equipped to safely use the project, take advantage of its security features, and understand its security posture.
We are excited to see pilot adoption from several OpenSSF projects, which has resulted in additional changes and improvements prior to the full release.
The road ahead
Following the release, we anticipate adoption by the aforementioned participating organizations, as well as other open source stewards and regulatory actors who have helped us bring the OSPS Baseline to life.
We will also continue to make regular updates to improve the OSPS Baseline over time.
I absolutely expect constructive criticism from you, our community, especially in areas related to clarity and documentation. Those are always the most important but most difficult elements for project maintainers to get right on the first try.
Thank you so much for joining us on this journey, and I look forward to seeing you in the project repo or on a community call soon!
Written by Eddie Knight
Eddie Knight is a Software and Cloud Engineer on Sonatype's Developer Relations team. With a background in fintech, he regularly works on open source software, including contributions to CNCF projects and working as a maintainer for the Compliant Financial Services project in FINOS. He also enjoys ...
