If you are using appsec tools in your pipeline you are probably asking what their benefits are. Typically, Static Application Security Testing (SAST) tools are prone to identifying false positives, which creates a lot of noise. The leadership questions why your tools, which were meant to reduce the number of vulnerabilities is reporting more vulnerabilities than ever. Furthermore, your Software Composition Analysis (SCA) tools appear to lack accuracy by reporting that all your code is at risk because you used a single dependency in one part of your application software. On the other hand, if you are scanning container images, you are faced with choosing whether to fix the image or push the vulnerable image into production even though the newly discovered vulnerability has always existed in production. Worse still, your organisation’s blocking policies prevent you from pushing vulnerable images to production which means that your containers, which have a lifespan, will be destroyed and not replaced!
In order to overcome these issues, you start to focus on process. You look to reduce the number of vulnerabilities in your application using a number of different techniques such as a concentrated campaign to fix all the issues (maybe you target the higher risk vulnerabilities first), you switch off the policies that generate the most false positives, you ignore the results of the dependency scans, after all, patching them is a pain! You either scan images and ignore the results if a version already exists in production, or you simply turn scans off for production container images. Obviously, these are not viable solutions to the problem. So what should you do?
Firstly, if you are using SAST tools, you should look for what types of vulnerabilities are being discovered and target the engineers with a campaign to learn how to avoid coding these vulnerabilities in the first place. You should ensure engineers are writing unit tests that validate the code against such vulnerabilities. Your goal is to improve the value of your unit tests, using the SAST tools to guide engineers to the areas of the code that need protecting with specific tests. The value with the SAST tools is not to identify vulnerabilities, but improve the tools you already use to test your code. The value of using a tool to identify defects within your dependencies is to reduce your exposure to vulnerable code that your engineers port into your organisation’s applications. Again, why types of application dependencies are your teams using? You may see value in creating a centralised interface for the most common libraries that your engineers use rather than having them call the dependent libraries directly. This will reduce your attack surface and give your engineers the tools they need to continue delivering value to your customers. What about those pesky container images? Okay, I do them a disservice, they have demonstrated their value already and the key is to use their advantages to your benefit. The idea of using ‘cattle’ rather than ‘pets’ means you can test many containers in production-like environments to see how a fix affects the application. Your security policies should provide informational feedback to help your engineers fix issues within the images rather than use them to block releases. This is what provides value to your customers.
The secret to the successful use of appsec testing tools is to ensure you gain value from them to understand your security posture and not as a yardstick of how many vulnerabilities you have. Thus you should avoid focusing on process, such as how to reduce the number of vulnerabilities or how to improve the accuracy of your scans. Instead, use the tools to understand your application’s weak points and integrate tried and tested methods, such as unit tests and clean architectural patterns, to improve the quality of your applications. Only when you understand the value of these tools in the context of your applications will you be in a position to use them effectively.