The Open Source Security Foundation (OpenSSF) has created a Project Security Baseline that helps open source projects of all sizes ensure that their efforts are secure.
The baseline defines a minimum set of requirements for application security that developers can do to enforce secure development practices, such as how they need to configure their tools and infrastructure to ensure the integrity, confidentiality and availability of their work.
According to Chris “CRob” Robinson, chief security architect at OpenSSF, there are three tiers to the baseline, depending on the number of contributors and maintainers. “Dozens of open source projects, when you think of things like Kubernetes and OpenStack, or the Linux kernel, have strong security teams,” he said. “There’s a mid-tier with thousands of projects with 2 to 100 maintainers participating, and then you have 16 million projects with a single maintainer.”
Developers are scouring the internet for code that can solve a problem, and without thinking or doing due diligence they’ll grab it and integrate that code into enterprise operations or a commercial product, without understanding what the consequences of using the project can be down the road.
So what OpenSSF has done is to create a compliance crosswalk, which Robinson explained “that if a manufacturer or a downstream enterprise had a regulatory obligation or they followed the NIST cybersecurity framework, we’ve mapped the baseline to all those other regulatory regimes and frameworks to show if your developers or the software you’re using follows these baseline practices, to showing where you have a great case to show support to an auditor or regulator that you have done some due diligence.”
Each level of the baseline maturity model lists requirements for the minimum set of security requirements, covering the areas of access control, build and release, documentation, governance, legal, quality, security assessment and vulnerability.
Using access control as an example, Maturity Level 1 for single maintainers requires that multi-factor authorization be in place for access to the version control system. Level 2 includes that but adds that when a job is assigned permissions in a CI/CD pipeline, the source code or configuration only assigns the minimum privileges necessary for the corresponding activity. And Level 3 adds rules for commits and deletions from the primary code branch. Here is a complete list of requirements for each maturity level.
Robinson went on to add that OpenSSF provides guidance as to where it thinks a persona would fit into the different maturity levels. The next step, he said, is to provide more references and documentation for people to get information and understand the concepts more. “So, when I use a term like least privilege, [developers] may or may not understand that,” Robinson said.
What consumers of open source software fail to take into consideration is that most of these upstream project maintainers aren’t cybersecurity professionals. There are a whole host of reasons why someone writes free software, and very few of them are getting paid to do it. They’re donating their time and expertise. Robinson pointed out that these maintainers “aren’t your employees, and you really can’t make demands” of them.
Robinson noted that the Log4Shell vulnerability led to a rash of commercial enterprises threatening legal action against the upstream maintainers, with demands to fix this. “But if you read the license agreement, most open source software is given with no warranty and no guarantee of support,” he said. “So part of my motivation for trying to get the baseline out there is to encourage good practices with the development community, but also give them the ability to defend themselves when some downstream person comes and starts nagging them, like, ‘Why aren’t you doing THIS?’ “
