Software security is, to a large degree, in the hands of the party that develops the software and it’s usually in the interest of the developers to ensure that software is secure.
But what happens with security for Free and Open-Source Software (FOSS)? The development model is significantly different, and the code is ultimately affected by changes coming from many different developers, some having only contributed once.
Open-source software security is a hotly debated topic. And open-source software security matters to your enterprise even if you do not directly rely on it. Open source can constitute a large proportion of any given piece of software, whether it is free or commercially licensed software. Comic XKCD summed this dependency nicely here.
It’s no wonder, then, that open-source software security featured prominently in this year’s 2020 FOSS contributor survey by the Linux Foundation.
In this article we take a closer look at the responses to the Linux Foundation survey. We consider the motives behind open-source development, how it impacts security, and what enterprises need to think about when it comes to open-source software security.
- The Motivations Behind Open-source Development
- How Reliant Are Enterprises On Open-source Software?
- Open Source Does Not Necessarily Mean More (or Less) Secure
- Solutions to FOSS Security
- Software Security: Tried And Tested Methods Work
The Motivations Behind Open-source Development
Commercial software vendors have a clear goal: profit. Ideally, this goal is what drives security efforts. If you’ve purchased a commercial license for a software, you could reasonably expect that the developers will act responsibly and take its security seriously. History has shown that a commercial enterprise will rapidly pay the costs if it produces software that is a security risk.
When it comes to open-source software, the goals behind ongoing development are less clear and, according to the Linux Foundation survey, somewhat mixed in nature. Understanding the goals behind open-source software development efforts informs how we see open-source software security.
According to the Linux Foundation’s findings, the three most common reasons why developers engage in open-source software development are:
- the developer needed to add a specific feature to the open-source software they are already using, or the developer found a problem that they needed to fix;
- developers who contribute to open-source projects because they enjoy learning; and
- contributions come in simply because it is an opportunity for developers to do challenging, fulfilling work.
As for security? It is hardly a factor in the motivation behind open-source contributions. In fact, open source developers essentially described security improvements as a sole-destroying and thankless task.
Another key driver behind open-source development that emerged from the report is that contributors working on open-source code are commonly paid to do so. The survey found that 52% of respondents said that they are specifically remunerated to contribute to open-source projects. This showed that roughly half of the developers working on open-source code have the backing of an employer/company/institution, and this might alleviate the perceived burden of working on security improvements. The opposite also holds, however, the other half are not remunerated when contributing open-source code, and likely fall on the three categories mentioned earlier (personal problem solving, enjoy learning, fulfilling work).
It is easy to conclude, therefore, that while open-source software will move forward in capability, security aspects are at risk of being left behind simply because many developers are not motivated to contribute to FOSS security.
This might seem like a harsh judgment and obviously not every developer acts this way. Decades of development and millions of lines of code are the best attestation of the fact. But, having the right incentive helps detect and fix security bugs faster.
As projects mature and reach decades of existence, there is the issue of developer turn-around. The original developers may have long abandoned the project and the newcomers are either insufficient in number or lack the overall knowledge of the codebase to adequately gauge the value and impact of code contributions. Several high profile projects suffer from this (see: the long tail of kernel developers, more relevant today than when it was originally written, for example), and its interesting to note that some have been making up this deficit by relying more and more on enterprise-backed, paid, developers.
How Reliant Are Enterprises On Open-source Software?
Does open-source software security really matter to large organizations? Why would a large business choose to use free software? In practice, the extensive capabilities of open-source software mean that many enterprise applications are dependent on open-source software simply because it's the best option -even if it is a commercially licensed version of open-source software.
That said, some organizations rely on closed-source, commercial software for all their applications. But even where enterprises appear fully reliant on commercially developed software, the reality is that the components that make up modern-day commercial software often contain elements of open-source software.
For example, open-source libraries are frequently incorporated into applications that are both free and commercial. Or, take into consideration the simple tools we use every day – such as PuTTy, victim of a decades-old security bug.
While we’re discussing everyday tools – OpenSSL, a commonly used cryptographic library, is widely used by organizations large and small – including big names such as Amazon, Facebook, and Google. But OpenSSL has proven to be vulnerable more than once. Not to mention Heartbleed, an OpenSSL security vulnerability that is six years old and refusing to die.
Even if your enterprise pays for expensive software, odds are that you are relying on open-source software one way or the other. After all, the massive 2017 Equifax breach was traced to a FOSS security vulnerability.
Open Source Does Not Necessarily Mean More (or Less) Secure
The fact that the source is available does not mean someone is actually looking at it, or that they understands it, let alone can fix it with the best interest of the project in mind.
Throughout this article, we have pointed to the security issues surrounding open-source software, but it is worth highlighting that software security challenges are not unique to FOSS implementations.
While there may be a lack of motivation to work on the security aspects of open-source software, the same can be true for closed-source software. Commercial software is developed behind closed doors and without the scrutiny of the wider development community.
Commercial developers should take security seriously, but during development, they may not do so. It could be down to a need for rapid go-live, a lack of teamwork, or a lack of a security culture. Any security gaps may never be uncovered, or only uncovered when it is too late, in part because closed-source software is not open to scrutiny in the way that open-source software is.
There is also the simple fact that software development is an incredibly complex environment. No matter how hard developers try, errors will be made. And even in the absence of glaring errors, exploits can still be found.
Solutions to FOSS Security
Whatever your opinion is on FOSS security vs. commercial software security, the fact remains that your applications will depend on open-source software to some degree.
This wide-spread dependency on open-source software demands a firm response to the concerns around open-source software. Sure, enterprise users can run their own security regimes – taking measures to monitor and guard against vulnerabilities.
But persistent open-source software security will need to be a community effort, with support from commercial interests. In the survey report, the Linux Foundation made a few key suggestions:
- Security efforts should be funded – in particular, the Linux Foundation suggests funding audits of critical open-source code.
- Increasing the use of mentorship and badging programs in order to motivate developers to take software security seriously as they contribute to open source development projects.
The Foundation also said that commercial operations should consider making software security training a key requirement when they hire open-source software developers and offer ongoing professional training that supports secure software development.
Open-source software security will only move forward if the right incentives are in place. Bug bounty programs are an obvious example. There may be a case, as it stands, incentives are insufficient.
Software Security: Tried And Tested Methods Work
While much can and should be done to improve open-source software security, the fact remains that software security will always leave something to be desired. There will always be room for improvement, it doesn’t matter whether software is open, or closed in nature.
Ultimately, security is an enterprise responsibility. There are known, established ways to safeguard enterprise software. To name just a few:
- Always understand what software you are relying on, what role these software tools play in your organization, and where the potential security risks lie.
- Essential security good practice should be consistently applied – strong passwords, MFA, tight credentials management, etc.
- Take advantage of telemetry and monitoring to identify unusual behavior and to catch intrusions early on, allowing for rapid reaction.
Regular patching is another obvious, tried, and tested element of enterprise software security. As we suggested, vulnerabilities are common to both free and commercially licensed software. In both cases, patches will emerge that resolve the vulnerabilities.
However, there are two problems with patching: patching is resource-intensive, and patching can be disruptive. Updating the open-source Linux kernel, for example, typically implies a restart of the server and the associated service disruptions. That is if the patch ever gets applied – tech teams are typically too busy to consistently patch.
When thinking about security good practice, it’s also worth considering supporting tools. When it comes to patching, for example, KernelCare makes life a lot easier by automating patching, and by reducing the need to restart patched servers.
There is a question as to whether open-source development teams are sufficiently motivated to avoid and address potential software security problems.
The Linux Foundation’s recommendation may well lead to a much-needed change in the long run. But software security will remain a persistent issue, even with commercially licensed and closed-source software.
It is up to enterprise users to be fully aware of the security risks. Enterprise users cannot rely solely on the efforts of developers. Applying persistent software security good practice can help mitigate even the most severe software vulnerabilities.