Software Engineering has Changed with CI/CD
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.
Application Security: Super Important and Super Broken
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. ⬇️
The AppSec Future: Application Security Tests in Every CI/CD Build
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.
A New Breed of AppSec Tooling
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:
How is The App Scanned: Are your DAST scans scheduled against a production environment, or does the tool assume ephemeral environments and pipeline runs? Does the SAST tool want you to zip up your code and ship it off to them, or does it integrate deeply into your source code repository?
Support for Modern Applications: Does the tool support modern development paradigms, such as single page applications, GraphQL, or JAM stack applications? Can it work with OpenAPI spec, or does it simply rely on an HTML spider? Does it simply scan publicly available sites, or can it work with multiple forms of authentication?
Noise Management: Traditional security tools are noisy with false positives and assume that fixing *all* findings is a priority over all else. Does the tool support quieting of noise to ensure that your workflows are not blown up by the addition of your security tool?
Getting Started
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:
Pick Your Tools: Select SAST and DAST tools that you can easily try out and add to your pipeline. Make sure they hit on the new breed criteria above. (Hint: if they don’t let you test without first seeing a demo, they probably aren’t built for developers). I’m a little biased, but StackHawk is really the only DAST tool built for developers. And here at StackHawk, we are big fans of Snyk for SAST.
Instrument in Pipeline: After configuring your tooling, add it to your CI/CD pipeline. We recommend starting with non-blocking runs at first while you triage any existing backlog of security issues. Now every build will include application security tests. For more examples of configuring pipeline instrumentation with StackHawk, check out our docs or this blog on instrumenting StackHawk with CircleCI.
Roll Out Across Engineering: Application security works best when distributed, with engineers fixing their own security bugs as they build software. This happens with a cultural shift first, but a cultural shift happens a lot easier when the right tooling is in place. One thing that helps drive the culture shift is visibility. At StackHawk, we are big fans of pushing the StackHawk results from a pipeline run into Slack. Another thing that helps the culture shift is putting the fix of new issues in the hands of each engineer, while managing the fix of the existing backlog through a different workstream.
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 hello@stackhawk.com.
