Home » Cybersecurity » Application Security » How to Accurately and Continuously Identify and Remediate OSS Library Risks
How to Accurately and Continuously Identify and Remediate OSS Library Risks
As organizations accelerate time to market of web applications, open-source software (OSS) enables developers to push more releases faster. OSS framework and library dependencies, however, create visibility issues and risks that organizations often overlook. Legacy software composition analysis (SCA) tools only provide a point-in-time assessment of open-source components and cannot continuously assess application security (AppSec) throughout the software development life cycle (SDLC). Plus, security and development teams often have no insight if libraries are being used in runtime. Contrast OSS provides continuous observability of OSS frameworks and libraries, pinpointing those that are—and are not—exercised in runtime. This enables organizations to identify OSS risks and remediate them accordingly.
Nearly All Software Is Built with Open-source Code
Open source has nearly become ubiquitous in modern software development environments. Due to the never-ending need for rapid development and innovation, it isn’t feasible for developers to create feature-rich applications from scratch. Agile and DevOps are predicated on releasing new features multiple times a day, which puts a tremendous strain on development teams to move faster toward innovation.
For these reasons, software today is often built from as much as 90% open-source code—including hundreds of discrete libraries in a single application. Open-source frameworks and libraries save time and allow developers to release more code faster.
OSS Library Dependencies Create Blind Spots
What many developers do not know, however, is that for a top-level library to deliver on its functionality, it must call on directly dependent libraries. These libraries may be linked to transitive dependent libraries—creating dependencies of dependencies. And because these dependent libraries may include vulnerabilities, this structure creates layers and layers of unknown risk.
A recent report finds that over 70% of applications have an open-source vulnerability, and 46% of those are transitive. That means many vulnerabilities reach code without being noticed, mainly because many organizations do not have accurate inventories of software dependencies used by different applications. Due to the distributed nature of OSS, with thousands of open-source projects distributed across organizations, there is no central authority to ensure the quality or maintenance of libraries. This means organizations that are creating software could include errors that result in critical security issues.
Visibility problems with OSS libraries during application runtime
Development and security teams often have little insight into which of these libraries get used when an application is running. This lack of visibility creates confusion when it comes to prioritizing vulnerability remediation—especially since any vulnerable libraries that get used when an application is running should garner the most immediate attention for remediation. Indeed, it costs six times more to fix a bug found during implementation than to fix one identified during design; 15 times more if it is identified in testing; and 100 times more during regular maintenance once the code is in production.
SCA and SAST tools incur inefficiencies and risk
Identifying and remediating vulnerabilities in applications that use third-party frameworks and libraries can also be problematic for teams using legacy application security tools. Software composition analysis (SCA) typically relies on static application security testing (SAST) to do so. However, SAST tools are known to generate false positives that can result in a dramatic efficiency drain in triaging and diagnosing each of them. And because it is often almost impossible for security and development teams to sift through these piles of false positives, many organizations elect to triage and diagnose only select ones. This produces missed vulnerabilities (or false negatives) that can pose a serious risk to an organization.
Overlooked licensing issues can cause development headaches
Another concern around open source is licensing of OSS libraries. In 2020, 67% of open-source components have permissive licenses—a 3% increase from last year’s 64% ratio. While open-source libraries are free, many have a licensing obligation associated with them, something that many organizations may not want to disclose (e.g., devalues the IP of the software—which is particularly problematic for software companies).
But without full visibility into the dependencies of third-party libraries, organizations could inadvertently reach deployment and discover their release contains libraries they cannot have included. Releases are delayed while developers write new code or integrate alternative open-source libraries—and then application security testing must be redone before the code can be released into production. The repercussions often come in the form of lost productivity and revenue.
Contrast OSS Enables DevOps to Focus on Critical Library Vulnerabilities
To accurately determine the usage of OSS libraries, security and development teams need the ability to continuously identify vulnerable open-source components, determine how they are used by the application, and directly observe and measure the behavior to prevent exploitation at runtime. By assessing the application while it is running, teams can observe which top-level libraries and which dependencies are accessed to properly prioritize remediation efforts.
In a nutshell, Contrast OSS allows organizations to:
- Prioritize and focus developer remediation on critical vulnerabilities by accurately identifying whether vulnerable open-source components are used by the application
- Automatically perform SCA for precompiled code using the Contrast command line interface (CLI) that seamlessly integrates into the continuous integration/continuous deployment (CI/CD) pipeline to identify dependencies between open-source libraries, including where vulnerabilities have been introduced
- Automatically perform SCA during application runtime, with real-time correlation of vulnerabilities, OSS license information, and additional library metadata
- Continuously assess open-source components for known and unknown vulnerabilities
- Continuously evaluate open-source components for license compliance and intellectual property risk
- Automatically enforce custom policies and provide real-time feedback to security, compliance, and development teams
- Continuously monitor production applications and block attacks on vulnerable open source to prevent runtime exploitation
- Maintain centralized visibility and point of control for all customer and open-source software risk, portfolio-wide, through a single automated platform
Following are specific ways Contrast OSS can help organizations with visibility into potential risks of OSS libraries:
Identify the extent to which each library is used
To report on the extent to which each library is used, Contrast OSS details the total number of available library components and the total called at runtime. Further, in the near future, Contrast OSS will be able to detail specific classes, files, and modules used by the application. CVE details and usage information help security teams prioritize which libraries to remediate and pinpoint areas where they are at the most risk. This information gives security teams what they need to prioritize remediation of libraries, ensuring the most critical and potentially high-risk libraries are prioritized first.
Assess applications at earliest stages of the SDLC
Contrast OSS also provides developers with a method to assess their applications at the earliest stages of the software development life cycle (SDLC). Using Contrast’s CLI, Contrast OSS integrates into CI/CD workflows to test precompiled code and to populate the dependency tree. It also performs runtime analysis to accurately identify whether components are used by the application. This intelligence enables development and security teams to prioritize and focus remediation efforts on the vulnerabilities that have the most risk. But to remediate, they need to know where the vulnerabilities were introduced in the library.
Know which library needs to be updated
Contrast’s command line interface (CLI) performs SCA on applications to show the dependencies between open-source libraries, including where vulnerabilities were introduced. By supplementing existing runtime instrumentation from Contrast agents, Contrast can provide a more detailed and comprehensive view of which library needs to be updated. Unlike SCA that can consume significant time, Contrast OSS slashes the amount of time required to identify which libraries require remediation.
Identify Runtime Vulnerabilities in Open Source with a Single Assessment Process
Lack of insight into all the different dependent OSS libraries that are pulled into an application during the CI/CD pipeline creates enormous blind spots in the application layer. As part of Contrast’s instrumentation-based Application Security Platform, Contrast OSS helps organizations prioritize critical vulnerabilities by tracking the libraries that are used by applications during runtime operation.
Further, Contrast OSS provides the observability that security and development teams require to identify the specific open-source libraries that are vulnerable. They also potentially expose the organization to unnecessary security risks or legal problems due to open-source licensing complications.
For more information on Contrast OSS, check out our “Contrast OSS Helps DevOps Manage and Triage Hidden OSS Library Risk” solution brief.
*** This is a Security Bloggers Network syndicated blog from Security Influencers Blog authored by Joe Coletta. Read the original post at: https://www.contrastsecurity.com/security-influencers/how-to-identify-remediate-oss-library-risks