Although software is significantly changing our work, home, and personal lives, many don’t realize that today’s software is made up of numerous ingredients. Some of the software we use daily contains pieces of custom code that’s developed internally by an organization, while other pieces of code come from community-driven open source projects that end up being baked-in to the final applications we utilize. Therefore, a combination of custom and open source code is employed by organizations who deliver the software products and services we often take for granted The adoption of open source by software development teams has dramatically changed the software industry overall. Instead of building all software “from scratch”, organizations use open-source components to their advantage, providing common or repetitive features and functionalities. This primarily limits the use of custom code to proprietary features and functionality, while also being the shoestring that ties everything together. Subsequently, developers spend much of their time on key differentiators, rather than recreating common features. Today’s modern applications are made up of a significant percentage of open source and over 30M developers contribute to community-based platforms like GitHub, accelerating open source software’s acceptance and usage. In fact, analysts report that 95% of organizations consume open source software within their own mission-critical IT portfolios. As a result, organizations must recognize, accept, and oversee how and where open source is used in the products and services they deliver to the industry as a whole.
Addressing the ChallengesThe practice of using open source components, libraries, and packages during software development does allow organizations to accelerate time to delivery, but it can also expose organizations to heightened levels of risk. For example, organizations that use open source are exposed to new security risks that materialize as a result of attackers taking advantage of the broad usage and open nature of open source. In addition, organizations are exposed to license risk, since open source components are governed by licenses (e.g., GPL, Apache) that set terms for the use of the components. And finally, organizations are exposed to operational risk (e.g., technical debt), because the open source support model depends on a community of contributors. Unfortunately, a community can abandon a particular component, version, or fork, and then the organizations using it in their software are left to patch it or evolve it. That’s the technical debt, effectively. By using open source, organizations and development teams are trusting the open source community to update and maintain the components, release patches, and monitor for security issues. Diminishing community contributions, outdated component versions, and other similar factors increase exposure to operational risks and can increase the cost of support for a software component in use within an organization’s codebase. This can increase the potential that an organization’s developers need to spend time and resources performing new development to ensure the security and functionality of a component. Although organizations acknowledge a heightened level of risk, unfortunately, most don’t effectively track or manage open source throughout their entire codebase and cannot easily address the widening hazards they face. Today’s organizations often lack automated, repeatable processes for open source usage, risk management, and remediation. For example, organizations may have no process in place for:
- Open source selection and approval as it enters a codebase
- Inventory and tracking of open source components in codebases
- Identification and monitoring for vulnerabilities
- Prioritization of security risks and automated workflows to accelerate remediation
- Assessment of risk to intellectual property, and of potential litigation from license non-compliance
- Creation and enforcement of policies, and integration of policies into developer workflows