SAST stands for Static Application Security Testing. SAST look through application source code for security defects, different issues written into the source code, and how the application is actually programmed to identify vulnerabilities that then have the potential being exploited.
How is SAST different from DAST?
SAST typically takes less time than running DAST, and it’s a little more reliable in the results you’re going to identify. Sometimes in DAST, you find things that are potential vulnerabilities, and you have to perform further testing to really validate that it’s an exploitable vulnerability or if it’s just something that’s not great, but not anything that’s going to be exploited or potentially exploited. You can also run SAST far earlier in the pipeline than DAST. Because DAST requires a running system, you have to build the application, you have to deploy the application, have an environment running, and then you can run DAST. In the spectrum of shifting security left, SAST is a really good tool to do that, because you can run it whenever you need to, even before the application is built and deployed.
How can you get started using SAST?
There are a lot of commercial tools out there, such as Micro Focus Fortify or Hailstorm, that you can integrate into your build pipeline, and that’s the ideal place to put them. So after each commit, when you do a build, it triggers a scan, and you get upfront, quick results about your security posture. You’ll know what you changed, and that it created this vulnerability, which eventually helps developers create better, more secure source code.
What do you do you after you get your SAST results?
It’s great that my oil light comes on and says I needed an oil change, but if I don’t actually change the oil, it doesn’t do my car any good. It’s the same thing with security. If you run scans and all you get is results and you don’t do anything about it, you haven’t moved forward. So it’s really important that you find those vulnerabilities and address them early. They’re typically easier to fix earlier on, and you have better context because you know what you just changed that ended up becoming a vulnerability. By ignoring the SAST results, things will build up into a vulnerability backlog which just becomes that much more of a challenge to try to address down the road.
