The world increasingly relies on open source -- here's how to control its risks
Open source software’s hold on the IT sector has deepened in the last five years. An estimated 96 percent of applications use open source components, and big players like Microsoft, IBM and even the U.S. government now embrace open source projects for their software needs. But while open source has transformed organizations’ ability to use proven and maintained code in the development of new software, it’s not untouchable in terms of security. Using code that’s readable by anyone brings risks -- and issues have occurred in the past.
It’s true that open source makes security efforts more transparent since it’s happening out in the open. If there are flaws in the code, they’re often resolved quickly by committed members of the open source community. Additionally, many open source projects have security scans built into their build processes, so contributions that introduce vulnerabilities directly or through dependencies are few and far between. But leaving the code in the open also allows bad actors to write attacks specific to unpatched vulnerabilities or to unrealized vulnerabilities in libraries that products actively depend on. As a result, teams using open source need to take steps to remain secure.
A growing embrace of open source
It’s clear why organizations use open source. Would you rather build a tool on proprietary code from the ground up or use blocks of code that are proven effective and maintained by other trustworthy users out in the open?
Most organizations prefer the latter and open source code delivers it to thousands of companies. According to Red Hat, 69 percent of IT leaders said open source is very or extremely important to their organizations’ infrastructure plans.
Over the past decade, the business world has embraced open source as the new normal for building software. At SPR, we work with more than 300 clients, and I can’t name one that doesn’t use open source software in some form.
Open source adoption by some of the most powerful tech players has been key to its growing influence. For example, Microsoft now offers many development tools for free and allows users to run them on all operating systems, not just Windows. In 2018, it even acquired GitHub, the well-known open source software development platform.
The ethos of the open source community is to further what’s possible with software and share innovations with the rest of the world. When members develop useful code or software, they share it back to the community. But it’s not a perfect system. Cybersecurity risks often accompany open source projects, and IT teams must proactively respond to those risks.
Managing open source risks
While open source projects tend to be in good hands out in the open, the right sequence of events can lead to attacks from malicious actors. They may inject harmful code into an open source package or write an attack specifically targeting applications that use certain (potentially outdated) versions of tools.
For example, in January 2018, nefarious individuals inserted malicious code into multiple core JavaScript packages that other projects depended on. After a manual operations professional accidentally deleted a certified username, several packages associated with it immediately disappeared. The mistake cleared the way for a bad actor to quickly upload malicious packages that used the same names. As a result, teams accidentally injected these packages into their applications without scanning them. In the end, hundreds of products were likely affected.
With such consequences in mind, your team must have an established policy operating in the background to protect your tools from ever-changing vulnerabilities -- or more rarely, malicious code.
Above all, you should define a policy for using open source and enforce it through automation. Automate the retrieval and scanning of dependencies so your deployments are halted or your builds are broken when new vulnerabilities are detected in packages that your software depends on. If an organization had this type of process during the JavaScript snafu, the malicious code may never have made it into the software because the scanning tool would have picked it up.
This measure goes back to continuous delivery best practices. Whenever I pull code from my repository for a build, it should be automatically tested -- both to ensure correct functionality and to check for known security vulnerabilities, either directly or through one of its dependencies. Your process should have a security scan built into the delivery pipeline so when your build is happening, you’ll know what could affect your app. Dependency management tools like Node Package Manager (NPM) provide warnings when a project’s dependencies contain vulnerabilities -- and you shouldn’t ignore them.
Additionally, IT leaders should monitor vulnerabilities by subscribing to the security bulletin mailing list accompanying the software license. Monitoring a security bulletin, like Common Vulnerabilities and Exposures (CVE) -- which is run by an open consortium -- keeps you informed about published vulnerabilities and scheduled fixes. Make sure you’re paying attention to bulletins like CVE for all the tools you use.
For all the good open source software has brought to the world, there will always be vulnerabilities and malicious actors intent on wreaking havoc. By implementing the right measures into software delivery timelines, you can position your teams to reap the benefits that open source offers, while confidently minimizing risks.
Photo Credit: Olivier Le Moal / Shutterstock
Justin Rodenbostel is a polyglot software engineer, architect, and lead one of the custom application development practices at SPR Consulting, a digital technology consultancy, where he focuses on building solutions for our clients using open source technology. His team’s broad expertise enables them to build their customers, not the most convenient solution or the solution someone’s most comfortable with -- but the right solution. Throughout his career, he's worked on large, mission-critical enterprise apps, small internal apps, and everything in between -- for clients as small as a 3-person startup and as large as a global Fortune 50.