Mitigating the Risks of Open-source Software in DevOps

Speed matters when it comes to developing and releasing a new software title—nearly two-thirds of software companies report a development backlog. So, it should come as no surprise to hear that developers have been increasingly relying on open-source software (OSS) components. A given application today might be built from as much as 90% open-source code. OSS libraries and frameworks offer a significant competitive advantage by reducing DevOps costs and accelerating time to market. But the benefits of OSS also bring some risks.

First, OSS components are favorite targets of cyber criminals. Open-source code is no more or less secure than custom code—but, as with any software, it can include vulnerabilities. Hackers understand that organizations often are unaware of the open-source components (and accompanying vulnerabilities) used within their applications. Rather than spending months trying to hack custom code, criminals can use publicly available exploits to automatically hunt for systems with OSS vulnerabilities. These attacks can be just as effective as other approaches—and with far less effort.

Second, the “free” nature of OSS can carry complicated licensing limits which can subsequently impact intellectual property (IP) rights. Components with undeclared or restrictive licenses may cause proprietary code to be defined as derivative works. This licensing complexity may also extend into other aspects of software commercialization (e.g., patent rights,) and could require legal expertise to untangle.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Because of these risks, manually managing open-source components can present DevOps workflow challenges, which can degrade some of the intended benefits by bottlenecking continuous integration/continuous development (CI/CD) pipelines and impacting delivery. Traditional application security that relies on static, fixed-moment-in-time scanning cannot provide these protections. Organizations need modern security with a few key capabilities to sidestep the common pitfalls associated with OSS in DevOps environments.

Using Automated Discovery to Build a Software Bill of Materials

According to Gartner, one of the first steps to improve software security is to ensure that a software bill of materials (SBoM) exists for every software application. An application security solution that provides automated discovery offers a perfect tool for this job. The SBoM delivers a definitive inventory of all the components (including OSS) used in an application—and it can provide an easy way for developers to locate vulnerable components when necessary.

SBoMs have the additional benefit of helping to standardize components. A rollup of the various SBoMs provides an overall inventory of all OSS elements used across the organization. This process typically reveals multiple versions of the same component (often in the same application) and multiple libraries with similar functionality. Standardizing on a limited set of components helps the development team simplify software maintenance.

Prioritizing Which OSS Libraries Pose the Biggest Risks

Beyond automating SBoM creation, another critical aspect of maintaining an effective inventory is to ensure that it accurately and dynamically represents the relationships between components, applications, and servers—so that developers always know what is deployed, where each open-source component resides, and which vulnerabilities need repair or protection.

To achieve this at a solution level, organizations need application security that understands which OSS libraries are being called at runtime. Runtime visibility of OSS components not only helps reduce false-positive alerts (probes against vulnerabilities that are not present in the code) but it also helps prioritize which vulnerabilities that are actually present pose the biggest risk.

Tracking Dependencies

Developers routinely use open-source libraries to introduce functionality to their applications at speed. What many developers do not know, however, is that for the top-level library to deliver on its functionality, it must call on directly dependent libraries. These libraries, in turn, may be linked to transitive dependent libraries—creating dependencies of dependencies. Because these dependent libraries may include vulnerabilities, this structure creates layers of unaccounted risk. Developers and security teams typically have no insight into which of these libraries actually get used when the application is running.

Developers should also embed controls into the CI/CD build process to track underlying dependencies, detect risks, and automatically enforce predefined policies. An effective open-source management solution can automatically analyze all the different licensing and security dependencies in a project. If a risky component is detected in a build, an automated policy check can trigger a post-build action failing or mark the build as unstable based on set parameters. Regardless of the specific processes in place, the goal should always be to deliver immediate and accurate feedback so that developers can quickly take action to maintain the security and functionality of the application.

Building Scalable Policies

Organizations also need scalable policies that can account for security vulnerabilities and license compliance risks. This often requires replacing any problematic open-source components with those that offer similar functionality issued under an approved license.

But once an application has been released, these repairs can take months to apply and push into production. With cyber criminals often launching attacks on newly exposed vulnerabilities in hours or days, applications also need continuous protection of OSS vulnerabilities in production. This buys time for development teams to safely resolve issues based on prioritized risk. This requires two key security capabilities:

• Runtime usage analysis. With potentially hundreds of open-source components in any application, tracking potential OSS vulnerabilities can easily overwhelm developers. To accurately manage any and all actual open-source risks, organizations must be able to directly observe and measure the behavior of the application when it is running. Runtime analysis enables effective prioritization of vulnerable components that are actually used by the application, and deprioritization of those that are not.
• Runtime protection. Application security must continuously monitor production applications and automatically block attacks on vulnerable OSS components to prevent exploitation at runtime. This is achievable with runtime application self-protection (RASP), which acts as an immediate compensating control by detecting and blocking attacks against any actual vulnerabilities (including OSS) from within the application itself.

Open-source Risks Require Modern Security Tools

Outdated application security assesses open-source risks at a fixed moment in time. To track and protect the widespread use of OSS components, developers need security tools that work when applications are actually running. Internal runtime visibility detects which open-source libraries are in use, if they are vulnerable, and if they present risks due to open-source licensing complications. 

To discover how to tackle open-source risks, download our eBook, “The DevSecOps Guide to Managing Open-source Risk,” Contrast Security, May 2020.