Continuous integration and continuous delivery has changed software engineering. Teams are shipping small change sets often and automation has made the life of an engineer a lot simpler. Automation throughout the CI/CD pipeline has touched nearly everything, with integrations and tooling for linting, unit testing, integration testing, deployment, and more.
Application security, however, has been left behind.
While there are a few exceptions, most application security products are dated technology built for an era before DevOps, CI/CD, and modern software engineering products. These products are also built for the security teams instead of the developers who are close to the code. This is obviously a problem.
It goes without saying that building secure applications is imperative for any engineering team today. Without baking security into your application, your company opens itself up to leaking sensitive data, degrading user experience, or allowing account takeover. As most companies in the world shift to be software-first, application security will only become increasingly important.
While clearly vitally important, current AppSec models are broken. The traditional approaches to application security prioritize training over tooling and finding over fixing. InfoSec teams are holding onto dated practices of periodic, point in time scans of production. Vulnerabilities are kicked back to the engineering team in long lists or large Jira backlogs, which then sit deprioritized over feature development. If the work is pulled into a sprint, it requires the developer to jump back into code that they likely haven’t touched for weeks or months.
Adding to this problem is the fact that the majority of the security products on the market are legacy enterprise tools. They are built for a different era of software development and continue to serve the technology dinosaurs that have yet to adopt modern DevOps workflow. Features are built for security teams and favor long approval chains and reports rather than enabling the developers who will fix the security bugs to get to the job of fixing found issues.
A shift is needed in both culture, workflows, and tooling.
There is a better way 👇.
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 codebase 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.
To add application security testing to the CI/CD pipeline, the right tools are needed. As mentioned, the traditional security products on the market are heavy on enterprise sales and light on features for the modern dev shop. Luckily, new tools are hitting the market that are built for developer-first security.
As you look at potential tools, here are a few things to consider:
Adding application security tests to your CI/CD pipeline can feel like a daunting task, but it is actually easy to get started. Here’s how:
At StackHawk, we’re obviously super passionate about this topic. If you want to talk shop, get technical support, or learn more about how we can help here, shoot us a note at firstname.lastname@example.org.
(Disclaimer: The author is the co-Founder and COO at StackHawk)