If you were to protect your home against thieves, wouldn’t you first close the main door? Vulnerabilities in open source components are the widest openings calling hackers to come in. Among all alternatives, detecting and fixing these vulnerabilities is easiest, and provides the highest ROI and fastest time-to-value.
In the past few years, it became clear that most dangerous breaches are made possible through security vulnerabilities in the application layer. (See for example reports by Verizon, Akamai, and Veracode). As a result, many CISOs turn their focus to securing their applications.
There are many steps that need to be taken to prevent, or at least reduce the number and severity of security vulnerabilities in applications. It is, of course, best if vulnerabilities can be detected early on in the software development lifecycle (“shift left”) because then the cost is the least. Education and code review play a key role here. However, since not all issues can be detected during the application development phase, it is common to run an application through a variety of application security testing gates before it is released (e.g., SAST, DAST, IAST), and possibly to wrap and protect it in a variety of ways (e.g., RASP, obfuscation). Post-release, one may further protect the application be verifying its inputs, protecting it against devastating surges, etc. (e.g., using WAFs, data filters, restricted communication, etc.)
But out of all approaches, there is one that is easiest, fastest, and provides the highest return, and that is Software Composition Analysis (SCA).
SCA is about identifying and fixing vulnerabilities in the open source libraries that are used in an application. Today’s applications are essentially composed of hundreds of open source libraries that make up as much as 80% of the total code in the application. The rest is, of course, proprietary code that is developed specifically for the application at hand. As such, every vulnerability in an open source library that your developers use is de facto a vulnerability in your application.
So why should SCA be the first AppSec project to tackle? Here are some points to consider:
- Vulnerabilities in open source components are public, in some cases, it is easy to also find code that can exploit them. Therefore, exploiting open source vulnerabilities is the easiest way in for a hacker. Just like walking through the main door.
- Vulnerabilities in open source components are often fixed immediately by the community, and therefore are often the easiest to fix. Just like closing the door, mind you.
- SCA tools, such as WhiteSource, automatically and accurately identify and alert about known vulnerabilities in open source libraries, and in most cases will also provide a remediation path. Fast, and easy.
- SCA does not disrupt developers and the development process. SCA tools are precise, make fewer alerts, and unlike code analysis (SAST/DAST) techniques do not produce false positives that developers need to sift through. These are confirmed vulnerabilities, and a concrete fix is often already available. As such, they require the least effort, and only to the extent necessary.
- SCA tools make it easy to prioritize alerts based on severity and the nature of the affected application. WhiteSource adds Effective Usage Analysis, allowing you to postpone treatment of vulnerabilities that are not actually reachable from your code and focus on what really matters.
- SCA shifts left treatment of vulnerabilities, as well as other compliance and quality issues. For example, WhiteSource provides a tool that would alert a developer that a particular open source library is faulty even before it was first downloaded and effort was invested in integrating it.
So when considering how to best secure your applications, make sure to first close the door. Do yourself a favor and start with SCA. It's just the most logical thing to do.