When transparency is also obscurity: The conundrum that is open-source security
Open-source software (OSS) has a lot of advocates. After all, why would we continuously try and write code that solves problems that others have already solved? Why not share the knowledge and gradually and incrementally improve existing open-source solutions? These egalitarian ideals are arguably central to civilization itself – never mind software – but also contain underlying tensions that have been a challenge for generations.
The pros and cons of OSS
The challenge of OSS security is that just because everyone can look at the source code, it does not mean anyone will. There are widely used open-source projects that are being maintained by only a small number of engineers, and those engineers cannot be entirely altruistic with their contributions of time and effort – they, too, have bills to pay.
This can be a challenge even for larger open-source projects. For example: the Linux kernel project has 30+ million lines of code, hundreds of bugs that need to be fixed, and almost 2000 active developers working on it. That’s 15,000+ lines of code per active developer!
A recent report from the Linux Foundation found that the average number of outstanding critical vulnerabilities in an application is 5.1, and that 41% of organizations are not confident in their open source software security. Even worse: only 49% of organizations have an open-source security policy.
Even if a security issue is found in open-source software, it does not mean someone will fix it. This is a fact highlighted by the report, which found that the average number of days to fix a vulnerability is currently 97.8 – leaving enterprises running that software open to attacks for many months. This is the often-ignored side of OSS security: while the good guys can hunt for bugs and vulnerabilities in the code to fix them, the bad guys can hunt for those same bugs to exploit them.
Real world security challenges
The reality is that these potential security issues are not a distant, imaginary problem, or industry FUD that can be easily ignored in the real world. Due to the vast amount of OSS code in active use, examples of active security issues with open source are legion. Indeed, 70% of the average program today is made of open-source software, with the number of dependencies varying widely by language: a mere 25 dependencies per project in Python’s case, but a massive 174 per project in the case of JavaScript.
As the situation with the colors.js and faker.js packages demonstrated earlier this year, problems with dependencies can have real-world impact on enterprise software. The two simple JavaScript libraries were baked into thousands of Node Package Manager (NPM) programs, which in turn were downloaded multiple millions of times every week – till their creator, JavaScript developer Marak Squires, deliberately broke them for reasons unknown. The result of Squires adding an infinite loop to colors.js and faker.js was widespread failure of NPMs that included his code, prompting a scramble to roll back the changes to safe versions (colors.js v1.40 and faker.js v5.5.3).
The benefits of professional help
Relying exclusively on a volunteer community to identify vulnerabilities, report and fix them is a bet with long odds. Paying someone to probe the security of your open-source solutions can help plug this gap, while you continue to enjoy the wider benefits of open source.
Another challenge with OSS updates and patches is that they need to be applied to secure systems, a fact that can present specific challenges. If your mission-critical solution relies on a specific software version, updating may mean losing functionality and/or requiring unscheduled downtime. In these business-critical scenarios it is sometimes more elegant to employ an expert to backport the fix and maintain a version for a longer period than the wider community supports.
Security is not free or easy
“It’s open-source, go change it!” is a statement you will hear a lot from the open-source community, and it highlights a key fact: Expecting good security levels for free while others contribute time, effort or money to the equation is not reasonable or sustainable.
Options include either contributing to open source as it was originally intended, by improving the code and publishing it for others, or employing experts to manage the OSS code and debug it as required. But making no contribution at all is an option that the industry can’t afford.