Open Source and the Visibility Problem
With so much open source software, it can become more difficult than ever to effectively locate and fix an issue without proper documentation and knowledge sharing.
Join the DZone community and get the full member experience.Join For Free
The world runs on software, and as any developer knows, software runs on open source. In fact, as much as 90% of the code base of any application built today is open source code, allowing organizations to innovate faster than ever.
But open source has some key visibility challenges:
- Who worked on/has domain knowledge about which application? Knowledge can be lost as team members come and go as projects age or get moved into maintenance mode.
- Which production applications use which open source libraries? Finding all instances of a library in production can be like searching for a needle in a haystack because of the lack of an up-to-date index of third-party code for all applications.
- How are third-party libraries licensed? Organizations can be faced with legal risks because GPL or LGPL libraries are accidentally deployed to production.
As a result, when a vulnerability occurs, it can be difficult to find which applications are affected, let alone locate the personnel that have the knowledge to recreate the original build environment so that the application can be upgraded, along with any new dependencies.
The Equifax Impact
For example, the Equifax breach that was discovered in July 2017 demonstrated once again the risk to businesses that fail to act in a timely manner when vulnerabilities are discovered. And yet 33% of organizations hadn’t patched the open source vulnerability at the root of the breach, more than 6 months after the breach was first found as per BlackDuck’s 2018 Open Source Security and Risk Analysis Report.
Is that just due to laziness? Given the tremendous loss in equity Equifax suffered both monetarily and in terms of their brand, it’s not likely. More likely are the myriad of problems that make finding and updating a vulnerable application difficult, including:
- Gaps in inventory: The existing inventory of what’s running (scripts, services, applications, etc.) where (on-premise, in the cloud, etc.) is out of date, leading to lengthy exploratory initiatives to update it.
- Loss in historical knowledge: Once the affected software is found, the original team that worked on it may have been disbanded, leaving large know-how gaps unless processes were extensively documented.
- Lack of reproducibility: Even if the team is re-convened or extensive documentation is available, reproducing an environment in which the software can be updated may pose issues (i.e. libraries may have been updated, dependencies may have shifted, etc.)
Reproducibility, Build Pinning and More
While there are multiple tools that can address one or two of the problems, it really requires an ecosystem of platforms, tools and best practices to resolve, including:
- Build pinning + environment replication so you can ensure reproducible builds
- Software Composition Analysis (SCA) tools so you can identify licensing, out of date libraries and vulnerabilities
- Team management, so you can associate members with applications, releases and builds
- Application “Bill of Materials” so you can determine which libraries are running where
Published at DZone with permission of Dana Crane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.