Most Organizations Lack Visibility Into Application Dependencies
For most of an organization’s applications, the code developed in-house is only the tip of the iceberg. The average JavaScript web application contains at least 1,000 dependencies, each of which can contain additional dependencies of their own. Focusing on the top level of an application means that the organization is missing the majority of the code that an application is using.
While most developers would agree that their code has external dependencies, they rarely take the steps required to achieve visibility into it. In fact, only 60% of organizations perform software composition analysis (SCA), which identifies open-source dependencies within an application’s code. This means that many organizations have little or no insight into the code that their applications are actually running.
A Lack of Application Visibility Creates Risk
This lack of application visibility can create a number of risks. One of the simplest is that a particular dependency breaks or is no longer maintained, and the application no longer works, forcing a complete overhaul. However, this is not the only potential risk that unmanaged dependencies can carry.
Unpatched Vulnerabilities
One of the biggest risks of the use of third-party code is unpatched vulnerabilities. Like the code developed in-house, libraries and other dependencies can contain design or implementation errors that leave them vulnerable to exploitation. These vulnerabilities are inherited by the application using the code, leaving it open to attack as well.
The scope of the threat of unpatched dependencies is significant. The average web application contains 22 vulnerabilities. However, not all of these vulnerabilities are easy to detect and remediate. In fact, 78% of vulnerabilities within an application are contained within indirect dependencies (dependencies of dependencies).
License Agreements
Exploitable code is not the only risk associated with the blind use of libraries and other dependencies. The use of third-party code can also carry legal ramifications and place an organization’s intellectual property at risk.
Most software is made available with a licensing agreement that describes acceptable use of it, and several different types of licenses exist. Some of these licenses may be very restrictive, allowing no modification of the code or requiring the payment of royalties or fees for its use. Others are designed to be very open, allowing anyone to use or modify the code without restriction or with a simple credit to the original author.
One type of license that an organization should be aware of is the GNU General Public License (GPL), also known as a copyleft license. This license states that an organization can freely modify or use a library as long as the derivative software is distributed under the same license.
This means that any application using libraries that are open source and freely available under GPL must also be made open source and freely available. The use of such a library in proprietary software places an organization’s intellectual property at risk and may leave it open to legal action due to a violation of the licensing terms.
Generating a Software “Bill of Materials”
The blind use of libraries and other dependencies creates cybersecurity and legal risks. To minimize these risks, an organization needs to gain full visibility into its use of third-party code and take appropriate action.
This can be accomplished by creating a software “bill of materials.” This can be generated by a number of different tools and lists all of the external dependencies used by an application. Based upon this list, it is possible to identify components that may contain unpatched vulnerabilities and to determine if any dependencies contain restrictive or undesirable licenses and must be replaced.
How MorganFranklin Can Help
MorganFranklin has deep experience in application security testing and can help an organization to gain the required visibility into their application’s dependencies and use of third-party code. This includes support for every stage of the process from identifying the best tool for generating a software “bill of materials” to taking action to remediate any identified issues.
