Open-source code in commercial network software can mean that when flaws are found by open-source project teams, fixes don’t make it to the commercial products.
The continuous influx of open-source software (OSS) into enterprise IT departments is, in many ways, an enormous boon to both vendors and users. For the former, the ability to use open source components means getting rid of a great deal of duplicative effort—rather than having to design every part of, say, an IoT sensor and monitoring product from scratch, a vendor can adopt a well-understood, well-supported open source library for its networking stack, and focus more of its attention on the sensing and data analysis features that will set the product apart from its competitors.
For end-users, one of the chief advantages is—at least in theory—the improved security that’s part of the usual sales pitch for open source software. The idea here is that the open nature of a piece of software—and the fact that anyone can look at it to discover and correct security flaws—means that it’s generally going to be more secure than a proprietary equivalent.
That’s only partially true, however, according to Gartner research vice president Mark Driver, who said that there’s a countervailing idea that openness can work against software, by allowing bad actors to add things into important code.
“The reality falls somewhere between the two – the reality is that OSS is no more or less secure than proprietary software,” he said. “It all comes down to how the project is run.”
The theory behind open source software being more secure is all well and good, but, in practice, everything depends on how active and skillful a given set of contributors is that is working on a particular project. Dimitrios Pavlakis, senior analyst for IoT and cybersecurity at ABI Research, said that there’s sometimes a disparity between bug-hunting efforts on the part of open source project teams and the thorough picking apart of the same code by bad actors.
“Open source communities are going duck hunting as a hobby,” he said. “But the attackers are doing this for a living.”
Hence, it’s critical for enterprises that use software with open source components to dig deeply into how well-supported those components actually are. Some open-source projects are not professionally supported, which means that the people maintaining them—if they’re maintaining the project at all—are doing the work in their spare time.
And even if those projects are being actively maintained, it’s no guarantee that the vendors who are using the code in their commercial software are patching in a timely fashion.
“The problem we find most widespread with open source software is the under-management of open source assets,” said Driver. Security problems may be fixed by the open-source teams, but that doesn’t mean the code gets fixed in products that incorporate it. “People will download and use it, but won’t go back and check [for patches],” he said.
So what’s a responsible business supposed to do about the potential for open source vulnerabilities in its software stacks? Part of the solution is technological. Software that can automatically analyze a given stack for open-source components and cross-reference it against known CVEs can be a big help for businesses looking to protect themselves. Vendors like Checkmarx, Vericode, and Whitesource, among others, have offerings of this type, generally known as software composition analysis (SCA).
But it’s also important to note that SCA software isn’t a complete solution, according to IDC research director Jim Mercer. Some open source software will only be used in part, so vulnerabilities in an unused part of the project or library, which would still be spotted by an automated SCA tool, might create false positives.
“The SCA tool will give priorities based on how the CVE was prioritized to start with, but not all of them will understand how you use the software,” he said. “You need to look at it yourself.”
Hence, the other and arguably more important part of the solution for enterprises is contractual, given the difficulty of manual, static analysis of a complex software stack and the potential impossibility of having in-house engineers fix open source software problems that they might not be familiar with.
This means that service level agreements that place responsibility for security analysis and problem-solving squarely on the vendor could be a business’ best available tool for avoiding potential open-source software problems.
“The solution is establishing an SLA that supports the value of whatever the business process is,” said Driver. “If it’s business-critical, you need that SLA to be rock-solid.”
This article originally appeared on NetworkWorld.