This is lousy news. True, open source software is inherently more secure than its proprietary rival. After all, you can look at open source code to see if there are any problems, while proprietary programs are a riddle wrapped in a mystery inside an enigma. But, as recent open source security holes such as Log4J and colors.js, and faker.js have shown, just because the problems can be sought for doesn’t mean they’ll be found – especially if no one’s looking for them. Eric S. Raymond, an open source founder, famously said, “Given enough eyeballs, all bugs are shallow.” But, “Linus’s Law” only works if someone is actually looking. If no one is, then you’re still open to attack. Or, as with Log4j’s vulnerability, we know about the problem, the fix is in, and months later, we still have tens of thousands of vulnerable programs. Why? Because users simply aren’t paying attention. This is just asking for a disaster. As open source software becomes increasingly more important to all programs, its security is becoming ever more important. As the managed open source company Tidelift recently reported that 92% of applications contain open source components. Indeed, the average program today comprises 70% open source software. According to this new report, based on a survey of over 550 respondents in the first quarter of 2022 as well as data from Snyk Open Source, which has scanned over 1.3B open source projects, the average software project has 49 vulnerabilities and 80 direct dependencies, that is open source code called by a project. That’s a lot of potential for trouble. Adding insult to injury, the survey also found that fixing open source project vulnerabilities takes longer than ever. Indeed, the time to fix a bug has more than doubled, from 49 days in 2018 to 110 days in 2021. But, wait! There’s more. According to Synk’s Director of Developer Relations, Matt Jarvis, “Software developers today have their own supply chains – instead of assembling car parts, they are assembling code by patching together existing open source components with their unique code. While this leads to increased productivity and innovation, it has also created significant security concerns.” This method of building programs won’t be changing. It’s essentially how everyone makes software today. As Brian Behlendorf, the Open Source Security Foundation (OpenSSF) General Manager, pointed out, “While open source software undoubtedly makes developers more efficient and accelerates innovation, the way modern applications are assembled also makes them more challenging to secure. Developers and managers must lose their naivete about the state of open source security today. For example, more companies must set up security policies for open source software development or usage. If, as is the case with 30% of organizations without an open source security policy, no one directly addresses open source security, you must fix this. You can’t simply blindly build programs from open source Lego blocks without eventually running into a disaster. In recent years, numerous open source software security initiatives such as the Alpha-Omega Project, Google Open Source Maintenance Crew, SPDX, and OpenChain have taken up the challenge of properly securing open source software But, more still needs to be done. And it starts with open source users recognizing their responsibility to ensure the code they deploy is safe in the first place. Also:
Slim.AI introduces beta software supply chain container security as a serviceSUSE doubles down on security in its latest SUSE Linux Enterprise 15 releaseOpen source security fears are fading away
