It used to be that web application security testing was the job of just the security team. Today, it is becoming a much more integrative function, especially for organizations who have adopted DevOps. Development cycles have become shorter and features are released more frequently for companies to stay competitive. Trouble is, with shorter development cycles, security needs a way to keep up. After all, there’s little value in running fast if you can’t also run secure. Today, no company can afford to not be secure, not with the kinds of threats we’re seeing.
To address this, companies are shifting the responsibility of security left, or much earlier in the software development life cycle (SDLC). This can be done by bringing security into DevOps workflows so that as the development environment scales, security testing can, too.
Considering the rate at which DevOps teams like yours are moving today, it’s no longer a question of if, but how, security can be brought into the fold so that companies can run fast and secure. In this post, we’ll break down the three ways your team can bring web application security testing into existing workflows so that security can move at the speed of development.
Automation is the Name of the Game
Prior to DevOps, when the SDLC didn’t move at rapid-fire pace and there wasn’t as much of a need for security to keep up, a tedious and manual testing process could suffice; there weren’t tools to do it any other way, and time wasn’t of the essence. Today, however, a company could get left in the dust if they took that much time for manual security testing.
This is why automation is now critical in bridging the gap between DevOps and security. Automating security testing means that time-consuming yet critical tests can be handled in mere minutes, not hours or days. Even more, tests being able to run on their own means your team doesn’t need to learn an entirely new tools or workflows—they’re embedded into everything you already know.
In this way, automation is the bridge between two traditionally separate teams and disciplines.
So, what does this look like in practice? Take a solution such as AppSpider as an example. A dynamic application security testing (DAST) solution, AppSpider can layer on security testing to just about any DevOps workflow, enabling security to become a natural part of the SDLC. In this way, security can be built into the product from the start, making it easier (and cheaper) to address along the way. In other words, security is no longer the roadblock at the very end of the process. Done right, it can be a seamless process designed to save both time and effort. We’ve written a whitepaper with more guidance on how to do just that.
Integration Brings DevSecOps to Life
DevSecOps, or the embedding of security into the DevOps cycle, can be brought to life when security is integrated with everyday DevOps tools. This includes your continuous integration tools like Jenkins or Hudson, test automation tools like Selenium, and issue tracking tools like Jira. Solutions like AppSpider are built to integrate with all of these tools, making it a cinch to bring security into the equation even if your team doesn’t have serious security chops.
When security is integrated into the SDLC, bugs and vulnerabilities can be spotted as the product is being built, not after the fact. Once you integrate a DAST solution like AppSpider with your continuous integration, testing, and reporting tools, you can begin automatically scanning web applications in their running state to find vulnerabilities that require remediation.
Here’s what this can look like in practice:
Once the development team commits source code changes, Jenkins will compile code and run functional tests, Selenium will check for web browser functionality, and your DAST solution will run a dynamic scan to detect new vulnerabilities that may have been introduced. Then, when issues are detected at any point along the way, your DAST solution should notify you and be able to send them directly to Jira to be flagged for remediation. Done right, all of this will happen in parallel to other development work, and run continuously in the background with little to no impact on the team’s velocity. In this way, security enables speed.
Baseline and Periodic Monitoring Saves Time
Once security testing has been integrated with your tools and processes, there is still another opportunity to gain efficiencies. Not only do you want to test for security issues at the outset, but also at regular intervals every day or week. However, if you’re making changes to and releasing code multiple times a day, there’s no need to scan the entire code base every single time, especially if changes only affect a fraction of the code.
That’s why we recommend that once a DAST is in place, a cursory scan of the application is run to detect preliminary issues and get a baseline of activity, then every time a change is made in the code, only scan those changes. AppSpider makes it easy to define the scope of a scan so that only specific areas are tested instead of the entire application. This can go a long way towards reducing the time it takes to test an app and get it out the door. Whereas a full security scan could take hours or even days (depending on how large the code base is), scanning only the pieces that have been changed could take seconds or minutes. This is another way to accelerate the SDLC without leaving security behind.
Achieving Security at the Speed of Development
Just a handful of years ago, it would seem like a pipe dream that security could actually be built into a product and keep up with the speed of development. Today, with automation and limitless integrations, it’s entirely possible, and companies as big as Microsoft and as small as the latest tech startups are getting on board. By shifting security left in the development process itself, web applications stand to become more secure by default, companies can practice true DevSecOps, and all teams can finally work together towards similar goals. It’s a rare win-win for everyone, and at Rapid7, we’re excited to see more companies make this important and necessary shift.