When Does Software Composition Analysis (SCA) replace SAST or DAST?
By Arthur Hicken
August 22, 2019
3 min read
The short answer is never. There, I just saved you enough time that you can go and do the right thing and run SAST and DAST and work on hardening your code instead of trying to test security into your application.
Does this sound like the beginnings of a rant? Maybe. But look, every time a new technology, process, or technique comes along, there are people that think that it’s the answer to everything. It’ll solve software security, save development and testing time, and maybe even eliminate world hunger while it’s at it. Ok, I’m getting dramatic. But saying that SCA is eventually going to replace SAST is essentially saying that because you’re looking for known vulnerabilities in other people’s code, you no longer have to check your own.
What is Software Composition Analysis (SCA)?
SCA is Software Composition Analysis. Theoretically it works hand-in-hand with a software bill-of-materials (something that currently mostly doesn’t exist) and keeps track of the other libraries and components that are used in your application. Currently these tools mostly just scan the open-source components for your application and don’t necessarily work with a bill-of-materials. (NOTE: some of these tools also perform other functions, like look for cut-paste snippets from OSS projects, or identify and manage OSS license issues. Both are interesting and important, but still not a replacement for what SAST is doing.)
One main function of SCA is to check components in your application for known vulnerabilities. This is important so you can avoid zero-day issues, as well as to address the problem that you might not have source for some components and therefore you’re unable to utilize SAST for them.
OWASP Provides Tools for Supply Chain Security
I must say that SCA is certainly a valuable part of your toolkit for securing your software systems. The popular and useful security organization known as the Open Web Application Security Project (OWASP) has even added this concept to the latest iteration of the popular OWASP Top 10 list of the most critical security risks today. It appears as item A9 – Using Components with Known Vulnerabilities. If you’re not using OWASP, you probably should. If you’re not checking your application for known vulnerabilities against the CVEand NVD databases, you should. Such sources keep track of real attacks happening and what patches and other remediations are available.
OWASP has even built a tool called OWASP Dependency Check that can do this work for you. Like all that OWASP has to offer, it comes without cost. Dependency-Check is a software composition analysis utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities.
Software Supply Chain Security is a Critical Part of Application Security
I must admit that not too many years back, software supply chain was a mostly overlooked toopic. Some key individuals, many of them part of the Software Supply Chain Assurance Forum (SSCA) worked hard to highlight this weakness in application security by focusing not just on your code, but on your supply chain. In fact, SSCA forum, which is hosted by the US Department of Defense (DoD), Department of Homeland Security (DHS), General Services Administration (GSA), and the National Institute of Standards and Technology (NIST), was formerly called the Software Assurance Forum (SwA) and they changed the name to help put more focus on the supply chain. But the intent was to expand the focus, not move it from your code to someone else’s.
The Software and Supply Chain Assurance Forum (SSCA) provides a venue for government, industry, and academic participants from around the world to share their knowledge and expertise regarding software and supply chain risks, effective practices and mitigation strategies, tools and technologies, and any gaps related to the people, processes, or technologies involved.
In practice, SCA is a testing activity – making sure that your application is checked against a list and is in conformance with that list (such as known vulnerabilities like NVD). Conversely, SAST is primarily NOT a testing function (heresy, I know…) but rather an engineering function. The smallest value of SAST is to find a weakness or vulnerability earlier than pen-testing would. The greatest value of SAST is to guide you to harden your code in the first place. Stop trying to plug leaks and build code that won’t leak in the first place. It’s the only way to get ahead of the curve in application security. If you do it perfectly, you’ll still need SCA, because you still have the problem of all those components in your application, as well as other programs it interacts with and the OS itself. If you do SCA well, you still need SAST because while you’ve fixed problems in other people’s code, you’ve done nothing for your own. The purposes complement each other, not replace each other.
In summary, SCA is great, you want it, in fact you need it. I’m happy that it’s getting more attention than it has in the past. But saying it will replace DAST or SAST is like saying you have a hammer and don’t need a screwdriver.