Open Source: Enterprise-Grade Security with Open Code?

Organizations rely more and more on open source code solutions, even if they are not aware of it. But is open source code security handled reliably? Large organizations rightly place a strong focus on utilizing dependable, secure software solutions. Oftentimes the most capable and indeed the most secure software solutions are free, open-source software.

Even where organizations always pay for software, commercially licensed software often depends on open-source libraries for some functionality – this XKCD comic strip is a potent summary of how these dependencies work.

But there are valid concerns around the security of open-source software, not least because there often is no party ultimately responsible for the security of an open-source solution.

It is little surprise then that a 2020 Linux Foundation survey made an effort to examine open-source software security. In this article we look at some of the results from that survey. We’ll examine these results in the context of an important question: whether open-source solutions can deliver secure operations in the enterprise environment.

Content:
1. What Drives Open-Source Development?
2. Commercial Imperatives Behind Open-Source Development
3. Incentives Matter, But There May Not Be Anyone to Incentivize…
4. Does Open-Source Matter For Enterprise?
5. Open-Source Prevalence in The Enterprise Environment
6. Security Is Not Determined by Source Model
7. Filling the Open-Source Security Gap
8. Practical Methods to Improve Software Security
9. Consider Live, Automated Patching To Boost Open-Source Security
10. Handle Open-Source Code Just Like Any Other Code

What Drives Open-Source Development?

We know what drives the development of commercial, closed-source software. It’s profit, pure and simple. In theory, commercial software vendors will invest time and effort in securing their software on release.

Vendors also usually rapidly respond to IT security concerns found after the release of code. Again, the motivation is simple. Secure software is profitable software, and no commercial vendor would want to take liberties with software security because it will quickly lead to reputational damage – and a drop in profits.

Matters are a bit more complicated when it comes to open-source software. Open-source software development is generally not driven by coordinated commercial imperatives and submissions to open-source repositories do not usually result in a direct payment for the submission.

The motivations behind contributions matter because it points to the level of care taken around software security. The Linux Foundation’s report suggested three typical reasons why developers contribute to open-source code:

•         A developer discovered a problem they needed to fix in an open-source solution they depended on. Or a developer needed to add a specific feature to the open-source solution that they use.
•         As a learning exercise, developers contribute to open-source code to practice their competencies and to learn more about an open-source project.
•         For some developers, contributing to open-source projects has the simple allure of being challenging, fulfilling programming work.

Contributing to open-source software security doesn’t feature prominently on the list. In fact, contributors suggested that they found working on open-source code security issues to be a tiring and thankless task.

Commercial Imperatives Behind Open-Source Development

The Linux Foundation survey also highlighted another important driver of open-source development: commercial requirements. According to the survey, it is common for the developers that contribute to open-source code to be paid to do so; with 52% of the developers responding to the survey stating that they were paid to contribute to an open-source project.

In other words, about half of those surveyed suggested that an employer of some nature – either an institution or a commercial enterprise – was paying for the work to be completed. It’s a large proportion of respondents, and it reflects the fact that sometimes it is a commercial need that drives open-source contributions.

This need may be a new feature – but it can also happen that a commercial organization noticed a flaw in open-source code and is paying a developer to fix it.

That bodes well for open-source security, but it also suggests that unless a commercial operator finds a flaw and has the incentive to fix it, the flaw may never be fixed – given that open-source developers are not that motivated to work on open-source software security.

Incentives Matter, But There May Not Be Anyone to Incentivize…

We do not mean to rush to judgement. There are billions of lines of open-source code, much of which was written without any remuneration whatsoever as many developers analyze, code and fix purely for the love of the open source model.

Nonetheless, it’s clear that incentives – commercial or otherwise – are useful in accelerating the detection and remediation of security bugs. But even incentives might not be enough.

We know that some open-source flaws can be found in very old code – the recently discovered bug in libcurl for example is decades old. The problem is that even with the right incentives to repair the code, finding the developers to do it can be challenging.

Open-source projects mature and fade into the background over time, even if the code behind the project is still in daily use. It creates a problem with finding developers, as the original developers have moved on to other projects – leaving behind a limited number of developers who are still able to gauge the correctness and value of the code contributed to the project.

It’s a common issue with many high profile projects struggling to find developers with the qualifications that can contribute – it’s a problem when it comes to the Linux kernel too. It’s meant that some projects have relied increasingly on paid developers to progress key aspects of a project – including security concerns.

Does Open-Source Matter For Enterprise?

Clearly there is a fair degree of nuance around open-source software security, but does it really matter for enterprise users? After all, large organizations can afford to pay for secure software.

Again, it’s complicated. For starters, the capabilities of open-source software can exceed the capabilities of commercial software and for that reason enterprises may choose an open-source solution, even if that solution is provided on commercial terms.

It is also true that commercial software often contains elements of open-source software – in libraries, for example. Think about PuTTy, a commonly used tool that’s often included in commercial solutions, but which in itself was a victim of a bug that was discovered recently.

Or OpenSSL, the open SSL solution that caused big waves when a security flaw was discovered – a security flaw that is refusing to go away.

Open-Source Prevalence in The Enterprise Environment

The point is that even companies that rely purely on commercially licensed software are more likely than not reliant on open-source code somewhere.

It’s not just an assertion. A widely quoted Gartner study suggested that 95% of enterprise operations are using open-source software for some part of their critical operations. There are a mix of reasons for this, but it is rarely down to an effort to save money.

Yes, open-source software is free in principle, but enterprise-grade solutions are rarely free as large organizations usually depend on open-source solutions as part of intensive development efforts – and often tie open-source software into expensive support contracts.

The reason why enterprises sometimes explicitly choose “free” open-source software is that in many instances open-source code can deliver the most capable solutions.

Finally, as we outlined in the previous section, open-source code is ingrained even in a commercial, closed source solution. In fact, it can be argued that open-source code is pervasive enough that organizations can essentially assume that open code is used in a solution no matter the source of the solution that’s deployed.

Security Is Not Determined by Source Model

Open-source code is public, so in theory, more people can and will be looking at this code, and therefore there are more opportunities to spot flaws. The reality can be different however as flaws such as the OpenSSL bug we pointed to above take years before they are found.

And, as we explained, there may be limited motivation for open-source developers to look for and to find flaws in open-source code.

At the same time, just because closed-source commercial software is driven by a profit motive does not mean it is more secure than open-source code. There is no guarantee that a vendor will deploy security researchers to examine code for flaws and there is always a risk that project teams will rush through coding to try and finish a project by a deadline. Besides, once completed, the code may never be reviewed.

So, while open-source code is in theory more open to scrutiny and therefore safer, there are no guarantees that the right people are looking at it. On the flip side, there is no guarantee that commercial software vendors take their security responsibility seriously.

Above all, developers always overlook things and always make mistakes, irrespective of whether they are paid or not and irrespective of the party that pays the developer.

Filling the Open-Source Security Gap

It does not matter whether your organization sees open-source security as worse or better than the security of commercially licensed software. The fact is that there are gaps in open-source software security and that most organizations are dependent on open-source software in some way. Therefore, open-source software security matters, period.

Yes, software security is your organization’s responsibility, and we will cover some tried and tested methods in the next section. But the open-source community and users of open-source software must take the first steps in open-source security. The Linux Foundation report made a few important suggestions in this respect:

•         Funding should be given priority so that developers have an incentive to work on open-source software security, including in regular audits of the most critical open-source code.
•         The Linux Foundation also suggests that open-source code that has repeatedly shown to be vulnerable should be rewritten from the ground up. For example, by converting the code from a memory unsafe language (think C or C++) to a memory-safe language – think Python or JavaScript.
•         In addition to funding, developers should be incentivized by badging programs and through mentorship to help boost the importance of software security in the open-source community.
•         Finally, the Linux Foundation suggested that commercial vendors should make software security knowledge a prerequisite when hiring open-source developers, while also providing ongoing education to train their developers to provide a base of support for secure software development.

In the long run, the only way that open-source software will be more secure than it currently is will be if all parties re-focus on security, while also providing the right incentives for the developers that work on code. Incentives, as they stand, are not sufficient.

Practical Methods to Improve Software Security

There are gaps in open-source software security, but there are a number of tools available to help address these gaps. Besides, ultimately, software security is the responsibility of your organization. We suggest the following points:

•         Consistently apply good practices including multi-factor authentication (MFA) and strong password security. Credentials management and tight permissions management is critical too.
•         Monitoring and testing will help identify intruders and flaws in your security profile so that you can stop intrusions before these lead to serious consequences.
•         Understand what tools you are relying on – and try to get a grip on the underlying building blocks too, including libraries and dependencies as often the real risks are out of sight.

However, arguably the most important element of software security is patching. Persistent, comprehensive patching protects your solutions against known vulnerabilities and is equally effective whether you are using free software, or commercially licensed software.

That said, patching consistently simply is not easy. Patching can be extremely time-consuming and often teams simply patch the highest priority vulnerabilities – leave many other flaws exposed. The fact that patching often requires a restart or reboot does not help, in the interest of availability teams often decide not to patch on schedule – only patching if there is a critical vulnerability.

Consider Live, Automated Patching To Boost Open-Source Security

Patching is critical but often not as effective as it should be. Live, automated kernel patching from TuxCare will plug a large gap in open-source security by ensuring that your servers are consistently patched against vulnerabilities – without the associated disruption to services.

Open-source development teams and individual contributions lack motivation and incentive to fully secure the software that they contribute to. And, as we know, to err is human – mistakes will always be made.

The Linux Foundation made several solid recommendations which is likely to improve matters for open source security, but for the foreseeable future flaws will continue to be written into code – only to be found, and patched. Patching matters.

Handle Open-Source Code Just Like Any Other Code

To conclude, enterprise users are almost always reliant on open-source code, whether directly or indirectly via libraries. While open-source code is not inherently insecure, there are unique security considerations when it comes to open-source code.

Awareness is the first step – and live patching can be a helpful supportive action. In other words, open-source code can be highly secure – as secure as closed-source code from a commercial vendor. It all depends on your organization’s security posture.