The use of open source code in applications has increased dramatically over the years, with open source components now comprising as much as 50 percent (or more) of any given application.
While the benefits of using open source are clear – faster time-to-market, greater opportunities to innovate, lower development costs, the support of a global community – the security challenges related to open source use can’t be overlooked.
More than 80 percent of all cyber-attacks target software applications. Attackers see open source components used in those applications as a target-rich environment. With information on open source vulnerability exploits widely available, attackers can potentially compromise thousands of applications with minimal effort.
Make no mistake, open source is just as secure as commercial code. The “more or less secure?” debate is a red herring that fuels many a message board flame war but misses the crux of the matter. The truth is most companies remain in the dark when it comes to the open source used in their applications, and as a result are susceptible to vulnerabilities that may be in that open source.
Although it is foundational to their application development, few organizations have rigorous processes in place to identify, track, and manage the open source components they use. Black Duck audits of customer codebases consistently show that most organizations are using twice as much open source as they believe they have in their applications. With that issue in mind, here are some recommended steps organizations should follow to better manage open source security risks.
Inventory Your Open Source
You can’t secure what you don’t track. To be successful, you need a complete and accurate inventory of all open source components in your codebase. A complete open source inventory should include all open source components, the version(s) in use, and download locations for each application in development and production. You’ll need to include all dependencies – the components your code is accessing as well as the components those dependencies are linked to – in your inventory.
For an accurate inventory, take into account the size of your development team(s), and whether they’ve been educated on the need for open source security and license compliance. If you’re using third-party developers, you’ll need to be confident that they will be as diligent about code inventory as an internal team. The larger the team and the more teams you have can quickly make the inventory process unwieldy and more prone to errors and omissions.
Map to Known Vulnerabilities
Compile a list of known vulnerabilities that have been reported against the open source components you’ve inventoried. Your primary resource will likely be the National Vulnerability Database (https://nvd.nist.gov). But be aware that not all vulnerabilities are reported to the NVD, and that the format of NVD records often makes it difficult to determine which versions of a given open source component are affected by a vulnerability.
Other useful sources of information include project distribution sites, security blogs, and message boards. All should also be part of your daily vulnerability research. “Daily” is the key word here. Mapping your open source against known vulnerabilities must be a continuous process in order to be effective.
Identify Possible License and Code Quality Risks
If you build packaged, embedded, or commercial SaaS software, open source license compliance is also a key concern – particularly to your legal team. Regardless of how your apps are deployed, you’ll also want to verify that you are using high-quality open source components, current and stable versions of those components, and that they are actively maintained by a robust community.
Manage Risk
Once you’ve identified vulnerability, licensing, or component quality risks in your open source, it’s time to prioritize those risks and address them. Determine what remediation needs to be done, assign the remediation work to the appropriate people, and track the remediation process: what’s being reviewed; what’s been reviewed; what’s been fixed; what fixes have been deferred; and what has been patched. If that sounds like a lot of work, it is, and that work doesn’t stop when an application ships.
You’ll need to continue to monitor for risks as long as the application is in use. Open source vulnerabilities are usually discovered and reported long after they are introduced in the code, meaning apps that were considered secure when they shipped may now be at risk of breach.
Manual v. Automated Open Source Security Management
Can you create an effective manual process to manage open source use? It’s possible, but
while it’s also possible to wear a toilet bowl as a hat, that doesn’t make it a desirable fashion statement. The odds are that without significant investments of time, resources, and budget, a manual open source security management process will never be completely effective and will potentially impact both developer productivity and the overall SDLC.
Many organizations turn to an automated solution to simplify and automate open source risk management, enabling them to effectively inventory open source in their code, protect against security and other open source risks, and enforce open source use policies.
Whatever your choice, while it may seem easier to just keep doing what you’re doing and hope for the best, you must put some type of open source security management process in place. Application vulnerabilities are the #1 security threat to your organization. Without inventorying, managing, and securing the open source components used in your applications, you’re providing attackers with an easy target.