Embedding Security in FOSS Projects

Brian Behlendorf, General Manager of the Linux Foundation’s Open Source Security Foundation (OpenSSF) and founding member of the Apache Group (which later became the Apache Software Foundation), has published an important post on how to avoid another Log4Shell type vulnerability.

Log4Shell, as it came to be called, arose out of a vulnerability in an open source Apache logging library, Log4j, developed by the Apache Foundation.

He stresses what many have been aware of for a long time now within the Free and Open Source Software (FOSS) community:

In many cases the security efforts at these organizations are under-resourced and hamstrung in their ability to set standards and requirements that would mitigate the chances of major vulnerabilities, for fear of scaring off new contributors. Too many organizations have failed to apply raised funds or set process standards to improve their security practices, and have unwisely tilted in favor of quantity over quality of code.

He then goes on to reccommend embedding what would effectively be an organisation-wide information security team and secure development processes within such organisations:

• Set up an organization-wide security team to receive and triage vulnerability reports, as well as coordinate responses and disclosures to other affected projects and organizations.
• Perform frequent security scans, through CI tooling, for detecting unknown vulnerabilities in the software and recognizing known vulnerabilities in dependencies.
• Perform occasional outside security audits of critical code, particularly before new major releases.
• Require projects to use test frameworks, and ensure high code coverage, so that features without tests are discouraged and underused features are weeded out proactively.
• Require projects to remove deprecated or vulnerable dependencies.
• Encourage, and then eventually require, the use of SBOM formats like SPDX to help everyone track dependencies more easily and quickly, so that vulnerabilities are easier to find and fix.
• Encourage, and then eventually require, maintainers to demonstrate familiarity with the basics of secure software development practices.

For many years now, the mantra of the FOSS community has been that peer review and more eyes on code meant that bugs (including security bugs) would be more easily picked up. However, it’s clear that this doesn’t go far enough. FOSS code is now heavily used in a wide variety of areas by consumers and businesses alike, so it would be prudent to embrace the same information security and secure development practises that larger commercial organisations have had to adopt to comply with major security standards.

As for where the money should come from, to pay for all of this, he believes that FOSS organisations should fundraise from stakeholders. Given the potential damage that vulnerabilities such as Log4Shell have caused, that might be a lot easier to do now.