The Open Source Security Foundation (OpenSSF) has launched an initiative to provide maintainers of open source software projects with a set of baseline security requirements that can be realistically attained and maintained by small teams.
The Open Source Project Security Baseline (OSPS Baseline) provides a structured set of security requirements based on recognized international cybersecurity frameworks, standards, and regulations.
Ben Cotton, an OSPS co-maintainer and open source community lead for Kusari, said, unlike existing frameworks designed for large enterprise the OSPS Baseline provides open source maintainers with a more streamlined set of best practices that can be implemented by small teams. The OpenSSF plans to regularly update this framework as the tactics and techniques used by cybercriminals to compromise software supply chains continue to evolve, he added.
That approach will have a more meaningful impact on improving the overall security of open source software, which today can be found in nearly every enterprise IT environment, said Cotton.
The overall goal is to increase the level of confidence enterprise IT organizations have in open source software, especially when it was developed by a small team that doesn’t have the resources of, for example, the community that works on the Linux operating system, he noted.
That’s critical, because much of the innovation that occurs in software stems from the efforts of small teams that are initially experimenting with a new use case that is later adopted by larger enterprises, he added.
It’s not clear to what degree large enterprises in the wake of Heartbleed, Log4j and XZ incidents are pulling back on reliance on open source software that isn’t developed by a large community capable of reviewing security and, when needed, promptly developing a patch. The OSPS Baseline is intended to alleviate the concerns by enabling maintainers to self-attest that certain best practices have been followed, said Cotton,
Of course, the alacrity at which maintainers of open source software will develop a patch when a new vulnerability is discovered is naturally going to vary, especially if they are not being compensated for those efforts. However, most open source maintainers are trying to responsibly develop software with the OSPS Baseline now providing a core set of guidelines, said Cotton.
There is no silver bullet when it comes to resolving open source vulnerability issues, but, going forward, there is an opportunity through education to reduce the number being created. There may even come a day soon when contributors to open source projects are regularly using artificial intelligence (AI) tools to review code that they wrote or may have been generated by a machine. The issue, of course, is the amount of flawed open source code being generated might exponentially increase because many of the AI tools created code were trained using software that already contained vulnerable code.
Ultimately, enterprise IT organizations need to assume there are known and unknown vulnerabilities in the open source software that has already been deployed. The challenge, of course, is finding vulnerable code in a sea of open source software that has been distributed across an entire enterprise, remains all too exceedingly difficult.
