The amount of open-source code being used in modern applications has exploded. According to multiple surveys, a large majority of enterprises are reporting that open-source components and third-party libraries are being implanted into their applications, both internal and outward-facing. Developers acknowledge that utilizing open source allows them to both speed up software development and focus more on unique code attributes instead of recreating what’s already been successfully established.

But the question of whether or not open source is as secure as proprietary code has come to the fore with this uptake in usage. In its defense, open source is vulnerable to hackers because they can see the code, but because of the large number of contributors to many open-source projects, more people can quickly respond to vulnerabilities in the code and remediate them when discovered.

Or Chen, director of R&D and manager of the software composition analysis (SCA) group at software security solutions provider Checkmarx, said open-source developers have a higher awareness than they did before about security and vulnerabilities, but many don’t follow enterprise standards of secure coding practices.

Among those standards, he said, are ensuring code is being reviewed throughout all software development stages, that there are gatekeepers to the repository, and that you notify your customers and consumers about newly discovered vulnerabilities. Most importantly, he noted, are ensuring the developers using open source in their applications understand the components, who the maintainers of that code are, and that repositories are being scanned on an ongoing basis. 

RELATED CONTENT: How to Effectively Manage the Modern Risks of Open-Source Code

“Developers should continue to upgrade their packages even if there is no new vulnerability or new functionality they need. Just make sure you’re up to date,” Chen said. “It will make your life easier when you have to update it because of a vulnerability.”

Another key standard developers using open source should follow is scanning the repositories with security tools similar to how they’re already using static code analysis. But in this case, software composition analysis is also needed to quickly scan your codebase to detect open-source libraries including direct and transitive dependencies, identify the specific versions in use, and identify any associated vulnerabilities and licenses risks you need to know about. The ideal scenario is finding a solution that offers both static and open-source scanning capabilities so developers can take a one-stop-shop approach.

Chen did note that there are differences between using open-source components or frameworks that are backed by organizations such as the Linux Foundation or commercial providers of open source such as Red Hat and many others, vs. using open source built by a small community of developers who may not have enterprise standards in place.

Vulnerabilities could be found in those smaller projects, yet it might take a longer time to remediate the vulnerability because there might not be anyone checking the board for newly discovered issues, and the community supporting the project might not have strong practices in place for remediation, he said.

Modern security risks
The big frameworks, web servers, and languages such as React, Angular, Django, and Spring are backed by big vendors who use industry standards. But small packages that Chen said are used for specific needs such as a math calculation or connection to a database, may not have that same kind of backing. “I do see, based on our customer usage, that every big enterprise might find itself with an open-source component developed by [small communities], and those packages might have been abandoned and no longer being maintained.

“So, when you find a security vulnerability in a smaller package, there may not be anyone available to immediately resolve it,” he continued. “This is part of what we call the modern risks of open source and the technical debt one may inherit from packages that are no longer being supported by the community. This liability also increases risk beyond just vulnerabilities and licenses issues.”

Currently, hackers look for packages that are not backed by Linux and all of those big vendors, but they’re popular. In this case, hackers often try to open the pull requests, inject some kind of malicious code inside that no one will notice, and a company might find itself with a Bitcoin miner in production, for example,” Chen explained. “As this ecosystem evolves, we’re starting to see increasingly sophisticated and modern risks in open-source areas.”

Another big risk to companies comes from legacy projects that might use outdated open-source packages. In those, he said, there might not be the kind of governance and monitoring of what gets in and what gets out of those packages. 

Further, there are some vulnerabilities that are not exploitable right now but in the next version of the application, new attacks might evolve that can exploit those vulnerabilities within methods and functions. “My recommendation there is to keep your code as clean as possible and as safe as possible all the times. Don’t leave any vulnerabilities inside.” 

“In legacy projects,” he said, “trying to have all dependencies upgraded to the latest ones is going to be an almost impossible mission. Upgrading them is no small effort, but by doing triage on the most exploitable vulnerabilities, and focusing on the packages you’re using the most, will make that task less ominous.” 

Newer environments are a challenge
Chen pointed out that organizations experiencing an uptick in digital transformation are working with microservices and are consuming a lot of open source to help them bootstrap their efforts to get their projects production-ready as quickly as possible. The lack of best practices in some of these cases, he said, will hurt them in the long run. “Hackers are creating all kinds of fake packages, typosquatting packages on bogus sites, or just injecting vulnerable code into existing packages. In addition, hackers often use open source for their own financial advantage, so when you run your application in production, they just want you to run their Bitcoin miner.”

 Finally, hackers are now looking to detect repositories on GitHub that don’t have any kind of security gate, he said, so hackers are “just free to put whatever they want inside it, and just wait for someone to consume it.”

Bottom line
At the end of the day, open source is here to stay. It brings immense benefits to developers in enabling them to build applications faster and at-scale. However, as malicious actors increasingly target these components to access sensitive and valuable data, leveraging SCA solutions that not only detect vulnerabilities earlier in development cycles, but also help prioritize and remediate issues more effectively and efficiently, are essential. Only then will developers be able to reap the true benefits of open source in a secure manner. 

 

Content provided by SD Times and Checkmarx