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.

Look, every time a new technology, process, or technique comes along there are some 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 made that last one up. 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. 

RELATED CONTENT: 
4 best practices to build more perfect software, faster
Report: Organizations fail to remediate app security vulnerabilities

SCA is Software Composition Analysis, and is certainly a valuable part of your toolkit for securing your software systems. 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. 

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.

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 CVE and NVD databases, you should. Such sources keep track of real attacks happening and what patches and other remediations are available. OWASP has been 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.

 Supply chain assurance
I must admit that not too many years back, software supply chain was a mostly overlooked topic. 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 U.S. 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.

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.