Instead of building all software “from scratch” today, developers use open source to their advantage when needing to provide common or repetitive elements. Doing so primarily limits the use of the homegrown code they develop for proprietary features and functionality, while also being the adhesive that binds everything together. Consequently, developers spend much of their time on key differentiators, rather than recreating common features.
The measurable benefits of open source have aided the rapid evolution of application development and curtailed development cycles. However, as with any new advancement in technology, there can be risks associated with open source that organizations must identify, prioritize, and address. There is little doubt that open-source vulnerabilities can leave sensitive data exposed to a breach; however, complex license requirements can also jeopardize intellectual property, and outdated libraries can place unnecessary support and maintenance burdens on development teams.
RELATED CONTENT: The modern risks of open-source code
In the context of risk, license risk can be clearly addressed in most cases, but can vary depending on how an application is deployed — as an internal application, an external-facing application, or a commercial application. Organizational risk (e.g., technical debt) can also be addressed by avoiding outdated open-source projects that may no longer be adequately supported by the community. However, quantifying security risk is not as easy as it sounds. Therefore, the key to open-source security is to know when you are vulnerable and what exactly the root cause is.
Are we vulnerable?
Most SCA (Software Composition Analysis) tools are designed to detect third-party libraries and versions in use and inform developers of known vulnerabilities. However, it’s important to acknowledge the fact that not all libraries in a project may apply, since some may not be utilized within an application itself. Just because a part of a library is notably vulnerable, does not necessarily mean the vulnerable part is actually in use. In other words, the real key to measuring security risk is to determine the exploitability of a vulnerability within the application itself.
popular method used to determine exploitability is through the Common Vulnerability Scoring System (CVSS), which is a score given to a vulnerability — based on the impact, how easy it is to exploit, etc. Every vulnerability that has been made public has this score. However, this methodology is too simplistic because exploitability is the most important characteristic to truly measure risk.
For example, developers today can use an entire library for a single API method out of dozens of APIs. Also, libraries they use have their own third-party libraries, with only a partial use of available APIs. This means that if a vulnerability is in one of the dependencies, the probability of exploiting it can often be below 5%. This can often pose serious implications.
The reason why is due to the way organizations currently prioritize vulnerabilities. Instead of fixing truly exploitable vulnerabilities first, developers may be addressing issues that can be completely irrelevant by not posing a viable threat. Most believe that a critical vulnerability should be a top priority, but if the vulnerable code can’t be reached in the application flow, there’s no need to prioritize that vulnerability, since it’s not actually exploitable in almost all cases.
Remedying security vulnerabilities can be a time consuming task, which directly opposes developers’ ongoing efforts of developing new and improved features and services. Managing security vulnerabilities of third-party packages should not be a one-time thing, but rather an on-going process, so it’s important for an SCA tool to be fully capable of prioritizing security risks. This way, developers know what the most critical vulnerabilities are to address and what alleged vulnerabilities can be disregarded. In many cases, the true number of vulnerabilities are in fact much lower than assumed, and that’s good news for developers. Fewer vulnerabilities mean far less effort to remediate them.
Understanding exploitable path
Although prioritizing vulnerabilities in open-source dependencies is challenging, developers and security teams must first understand what it means for a vulnerability to be exploitable. For example, a vulnerable method in a library needs to be called directly or indirectly from a user’s code and/or an attacker needs a carefully crafted input to reach the method to trigger the vulnerability.
The real key to understanding exploitability is to create an abstraction layer to statically detect vulnerabilities that are exploitable by understanding the exploitable path. Developers and security teams need the ability to determine if they are really at risk from an open-source vulnerability based upon how that code is used in their application. To solve this issue, organizations need a method to break down the code of every major language into an Abstract Syntax Tree (AST), which can provide much of the needed abstraction. Imports, call graphs, method definitions and invocations can all become a tree.
To learn more, read this blog.
Content provided by SD Times and Checkmarx
