While shifting security left has been a trade show booth tagline for years now, we are at the advent of that truly becoming a reality. In the same way that many engineers now define and monitor their own infrastructure, developers are learning that they can take security testing into their own hands. Proper tooling and pipeline automation will drive this shift.
So what does application security tests in every build look like?
You’ll want to instrument two types of security testing, commonly known as SAST and DAST. SAST (Static Analysis Security Testing) scans your code base and its associated dependencies for known vulnerabilities. DAST (Dynamic Analysis Security Testing) runs tests against a running version of your application to find externally exploitable security bugs. Both are important, and both can be added to your CI builds.
Then, on every merge, your pipeline can run security testing. When a developer adds a security bug, they will be alerted and can quickly fix. Tests should be instrumented later in the pipeline as well to ensure that new bugs are not introduced – think of it as security integration testing. When a bug is found, fixes can be tested locally before kicking off a new build.
Comments are closed.