SLAs to protect network apps with open source components

In many ways, the continued arrival of open source software (OSS) in enterprise IT departments is a huge boon for both vendors and users. For the former, the possibility of using open source components avoids a lot of redundant work. So instead of having to design every part of an IoT sensor and monitoring product from scratch, the vendor could for example adopt a well-understood and well-supported open source library for their network stack, and focus more on the detection and data analysis functions that will differentiate its product from that of its competitors. For end users, one of the main benefits is – at least in theory – improved security, a common argument for adopting open source software. The idea being that the open nature of software – and the fact that anyone can examine it to find and fix security holes in it – implies that it will generally be more secure than its proprietary counterpart.

But, according to Mark Driver, vice president of research at Gartner, that claim is only partially true. And he puts forward the opposite point of view on this subject: the open source character can harm software, by allowing bad actors to add elements to the main code. “The reality is somewhere in between, which is that free software is neither more nor less secure than proprietary software,” he added. “It all depends on how the project is managed”. The theory that free software is more secure is valid, but in practice it all depends on the activity and skill of a given set of contributors working on a particular project. According to Dimitrios Pavlakis, senior analyst for IoT and cybersecurity at ABI Research, there is sometimes a disparity between the bug-hunting efforts on the part of open source project teams and the meticulous peeling of that same code by the bad guys. actors. “For open source communities, bug hunting is a hobby, while for attackers it’s a way of making a living,” he said.

Difficult maintenance

It is therefore essential that companies that use software with open source components question the quality of support for these components. Some open source projects do not have professional support, which means that the people responsible for their maintenance – if the code is maintained at all – do this work in their spare time. And even if these projects are actively maintained, vendors who use code in their commercial software cannot be guaranteed to apply patches on time. “The most common problem with free software is the lack of management of free assets,” said Driver. Security problems can be fixed by free software teams, but that does not mean that the code is fixed in products that incorporate it. “People will download and use it, but not go back and check for fixes,” he added.

So what can a responsible company do about the potential vulnerabilities of free software in its software stacks? Part of the answer to this question is technological. Software that can automatically scan a given stack for open source components and compare it to known CVE vulnerabilities can go a long way in helping protection-conscious organizations. Vendors like Checkmarx, Vericode, and Whitesource, among others, offer offerings like this, commonly known as Software Composition Analysis (SCA). These tools allow you to take an inventory of open source components used in an application. But, according to Jim Mercer, research director at IDC, it’s also important to note that SCA software doesn’t offer a complete solution. Some open source software will only be used partially, so vulnerabilities in an unused part of the project or library, which would still be spotted by an automated SCA tool, could create false positives. “The SCA tool will prioritize based on the starting CVE classification, but not all tools will understand how the software is used,” he added. “Which means you will have to examine it yourself.”

Caring support

Therefore, the other part of the solution, and arguably the most important for companies, is contractual, given the difficulty of manual and static analysis of a complex software stack and the potential impossibility for internal engineers. solve open source software problems that they may not be familiar with. In other words, SLA service level agreements that give the vendor responsibility for security analysis and troubleshooting might be the best tool to avoid potential problems with enterprise open source software. . “The solution is to establish a service level agreement that supports the value of any business process,” said Driver. “And if this is a critical business process, better with a concrete service level agreement.”