SCA stands for Software Composition Analysis. It’s a technique where you try to analyze the dependencies that your application includes to make sure that they don’t have any known vulnerabilities. In fact, up to 80% of the components that we include in our applications have some known vulnerability in them which can expose our applications to risk. So it’s important to use an approach like SCA to fully understand what dependencies we have, what issues are with those dependencies, and then how much of a risk those issues present to our application.
How is SCA different from other types of application security?
DAST and IAST are mainly focused on understanding your application and not the code that you are including in your application from third-party vendors. The unique perspective that SCA takes is that it’s looking at third party components to include as opposed to scanning your own code. Now, scanning your own code is certainly important, but we use so many open source components and third party components, that it’s just as important, if not more important, to scan those as well.
How can you get started using SCA?
There’s a free tool called OWASP Dependency-Check, which I recommend you start with. Run it to see what dependencies you have in your application and what vulnerabilities exist. It gives you a good starting point to see what your risk profile is and what sort of work you might need to do to resolve any security issues. Then if you get used to using that, or you find that it’s not giving you everything you need, you can look into paid tools like Nexus Lifecycle. Lifecycle provides other nice features like IDE integration, where developers can see issues in real time and avoid introducing the vulnerabilities in the first place.
Is SCA best for greenfield or legacy applications?
Given the Agile methodology and the approach of building things in on a continuous basis, it’s best to use SCA from the beginning of your project because then you won’t have many vulnerable components down the road. But even if you have a legacy application, you still want to know what the vulnerabilities are, and you can still resolve at least the highest risk vulnerabilities to make your application at least a little more secure than it is right now.
