The Census II study's preliminary findings strongly suggest that open source initiatives require supporting toolsets, infrastructure, people, and good governance in order to function as a stable and healthy upstream project for your company. It's not nearly as horrible as it sounds, because not all flaws can be exploited.
Wheeler cited a report from Synopsys, a software security and IoT (Internet of Things) company – each application has an average of 528 open source components, 84% of codebases have at least one vulnerability, and that the average number of vulnerabilities per codebase is 158. An audit of 1,546 codebases was conducted, with a codebase being defined as "the code and accompanying libraries that make up an application or service."
"If you're concerned about security, you'll inspect the software." Nonetheless, open-source is possibly safer, because of the long-standing secure software design principle that "the protective method must not rely on attacker ignorance," as outlined in a 1974 work by Jerome Saltzer and Michael Schroeder.
This is a benefit of open-source software. "The many eyes theory works," Wheeler added.
Vulnerable software does not get updated, which is a big part of the problem. Many apps and systems do not update all of the components that they use. This is also true for closed source, although "open source software is used a lot more."
Developers should "learn how to design and acquire secure software," according to the report, which lists a number of free courses, best practices, and tools.
A flaw in test-driven development, according to Wheeler, is that the model of writing a test and then writing the code to make the test pass does not include negative tests, implying that there is a need to test to ensure that things that should not happen do not happen. A failure to include negative tests is one of the major issues in many test suites today. It's how the Apple goto fail vulnerability came to be, according to Wheeler, who was referring to this problem.
Use caution while dealing with software that hasn't been utilized in a long time. "There will very certainly be no reviewers if there are no users. It's not a problem if you don't utilize it " If it is still required, the remedy is to "look at it yourself."
In summation, although the problem is difficult to solve, there are several initiatives that may help. The SPDX project, which specifies the "bill of materials" utilized by a software library or application, and the Open Source Security Metrics (OpenSSF) dashboard, which, though still in its early stages, assists developers and users in assessing the security of specific packages.
