Developers have always had a conflicted relationship with security. While they don't want to produce software with security flaws, they don't want to be security experts either. With that in mind, the Open Source Security Foundation (OpenSSF) has released the Open Source Project Security Baseline.
The new guidelines for the use of open-source software (OSS) in development provide a structured set of security requirements aligned with international cybersecurity frameworks, standards, and regulations. They are designed to bolster the security posture of OSS projects.
Ben Cotton, baseline co-maintainer and open-source community lead at Kusari, said that while a lot of supply chain compromises via open-source projects happen because maintainers are overwhelmed and don't have time to catch everything, sometimes it's just because maintainers don't necessarily know the best steps to take. That's where the OpenSSF's guidelines fill a gap.
"Open-source project maintainers are the backbone of modern software, whether or not they intend to be."
—Ben Cotton
Here's what you need to know about OpenSSF's Open Source Project Security Baseline guidelines.
[ Download Today: 2025 Software Supply Chain Security Report | Join the SSCS Report Webinar ]
A new baseline for OSS security is born
OpenSSF said the guidelines represent a baseline via a tiered framework of security practices that evolve with project maturity. The guidelines compile existing guidance from the OpenSSF and other expert groups, outlining tasks, processes, artifacts, and configurations that enhance the security of software development and consumption.
By adhering to the baseline, the OpenSSF noted, developers can lay a foundation that supports compliance with global cybersecurity regulations, such as the EU Cyber Resilience Act (CRA) and the Secure Software Development Framework (SSDF) from the U.S. National Institute of Standards and Technology (NIST).
Stacey Potter, an open-source community manager at Stacklok, said in a statement about the guidelines that it can be tough to navigate security standards, but the guidelines provide a framework that grows with your project.
"Our goal is to take the guesswork out of it and help maintainers feel confident about where they stand, without adding extra stress. It’s all about empowering the community and making open source more secure for everyone!”
—Stacey Potter
Cotton asserted that maintainers of open-source projects — many working on a volunteer basis — are being pressured to tighten their security by corporations that make millions or billions of dollars off a developer's work. "Maintainers shouldn't have to sit there and learn the general concepts behind a bunch of security things," he said.
"Obviously, the more security knowledge they have, the better. But we wanted our baseline to be something where a maintainer of an open-source project who wants to meet level one of the baseline can sit down for just a little bit of time and make sure these various settings are enabled."
—Ben Cotton
The more maintainers have to figure out on their own, the harder it's going to be to get them to adopt secure practices, Cotton said. "We recognize that you can't just place demands on these communities. There has to be a tangible benefit for them and a minimal burden because so many maintainers are overworked already," he said.
Recognizing OSS diversity is key
The baseline's tiered system of guidance is meant to be a recognition of the diversity of open-source projects that avoids the one-size-fits-all approach of tools such as the SecurityScorecard, Cotton said. With the baseline, the best practices for a project with a small number of maintainers are tailored for that project's size, while other tiers have best practices practical for larger projects with a broader reach and large contributor base.
"We should give [maintainers] very focused and directly actionable guidance."
—Ben Cotton
Cotton said that, while it would be great if every project produced a software bill of materials (SBOM) and every developer did some threat modeling of their software, "we can't expect a group of five people working on this little hobby project of theirs to necessarily have the time or the interest in taking those steps."
One of the criticisms of the scorecard from maintainers is that it's being used by consumers of software — whether it's companies or downstream projects — to evaluate their upstreams and basically say, "Fix this or fix that." "With the baseline, we're very explicitly intending for it to be used by the project maintainers for their project, to give them the tools that they need to take the security steps that are going to benefit the ecosystem more broadly," Cotton said.
Why the baseline is key to securing commercial software
While praising the open-source community's efforts to produce quality code, Mike McGuire, senior security solutions manager at Black Duck Software, warned that those efforts will be blunted if users don't fulfill their role when using OSS.
"No matter what is done by project owners, no commercial application will be made any more secure if development organizations don’t invest more in managing the open source that they leverage. If development organizations aren’t tracking the open-source projects that they leverage and are not evaluating them for risk or their adherence to frameworks like the OSPS Baseline, then they will continue to struggle with lingering vulnerabilities."
—Mike McGuire
Black Duck's 2025 Open Source Security and Risk Analysis (OSSRA) report found that 81% of commercial codebases contain critical open-source vulnerabilities, with the average age of those vulnerabilities being 2.8 years old. "The overwhelming majority of these vulnerabilities have fixes available, which signals issues on the open-source consumer’s side with managing their dependencies and not an issue on the open-source project side with patching issues," McGuire said.
Could compliance breed complacency?
Jason Soroko, senior vice president of product at Sectigo, appreciates that the new OpenSSF baseline sets a clear and necessary floor for open-source security. "It forces projects to implement essential controls such as MFA and secure versioning that have been long overdue," Soroko said.
However, he warned that compliance could translate into complacency. "This potentially creates a fixed checklist that risks turning security compliance into a destination rather than a journey. Static baselines may lull projects into a false sense of safety as threat landscapes evolve," he said.
The real danger is not the floor itself but the complacency it may breed, Soroko said.
"Many developers might stop at level one, meeting only minimum sponsor requirements without advancing their practices. The baseline’s tiered model is meant to spur continuous improvement, but its success hinges on an industry culture that prizes proactive, adaptive security over checkbox compliance. In this light, true security demands innovation beyond static minimums."
—Jason Soroko
