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 the favorite targets of cybercriminals. 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.
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.
#open source #security #devops #cybersecurity #rasp
