In AppSec, ‘Fast’ Is Everything

Development organizations interpret delays as damage and route around them. Yet the application security program in most organizations is a centralized team that attempts to force software projects through a series of “gates.” A few brave organizations are stepping away from the bottleneck model to something better.

It’s easy for organizations to fall into the trap of thinking that AppSec is too burdensome to undertake over and over throughout the lifecycle. So they wait until the end of the development process and attempt one big application security review. And that’s the problem. Waiting until the end has disastrous consequences for security.

Using Brakeman at DevOps speed
What if the burden of application security verification could be lowered to almost zero? There would be no reason not to conduct reviews continuously throughout the software development lifecycle.

Justin Collins at Twitter created a static analysis tool for Ruby on Rails called Brakeman that significantly reduces the burden of static analysis. Despite the name, Brakeman was designed to accelerate software development, not slow it down. It calls to mind the old saying, “Why do cars have brakes? So they can drive fast!” And it’s actually Brakeman’s speed that allows it to be cleanly integrated within the software development process and not get bypassed.

We know that the cost of application security defects increases the longer they are allowed to stay in a software baseline. But it takes a really fast and accurate AppSec tool to be used early in the lifecycle to truly reduce the cost and complexity of finding and fixing vulnerabilities. Otherwise, organizations will just save up the burden until the last possible minute.

So what does it mean for an application security tool to be “fast?”

Instant feedback. Of course, fast means that results are produced immediately, not the next day, and certainly not in two weeks. Developers are used to getting instant feedback from their compiler, and security needs to work the same way. The best and simplest feedback leverages and relies on existing channels of communication, like bug trackers, IDE warnings, and email alerts.

No experts. Anyone can install and use Brakeman without being an application security expert. This is absolutely critical for speed, because centralized application security teams are always a bottleneck. They have to be as the demand for their expertise far outweighs their available time and budget.

Run continuously. You don’t have to remember to run a Brakeman scan. A related tool called Guard::Brakeman takes care of running Brakeman automatically every time you save a file. A fast tool can’t expect any changes in the software development process. It must be completely compatible and run without requiring any additional configuration or tuning.

Run everywhere. Brakeman can be used easily and at any stage of the software development lifecycle. It can be used during development, on an integration server, during testing, or even as a part of deployment. Having double-checks throughout the lifecycle ensures that mistakes are caught even when running at high speed.

Accuracy. False alarms are a huge time waster, so being fast requires accuracy. Spending time proving that a security warning is a false alarm produces no value and undermines the credibility of every other warning, so accuracy is critical.

IAST -- beyond static (SAST) and dynamic (DAST)
Fortunately, there is a new approach to application security automation that leverages the power of instrumentation to go fast. Really fast. Instrumentation means that security information is gathered directly from an application as it runs. Software instrumentation is similar to the instrumentation in your car that continuously monitors the engine temperature, washer fluid levels, tire pressure, and so on. Gartner calls this technique IAST for “Interactive Application Security Testing” and named it one of their Top 10 Technologies for Information Security in 2014.

IAST tools can analyze the code like a static tool and examine HTTP traffic like a dynamic tool. But they can also access the runtime data flow, the libraries and frameworks in an application, all the configuration files, and even the actual backend connections made by an application. All this information leads to broad coverage and high accuracy.

The beauty of IAST is that it takes advantage of all the context available in the running application so that it can run insanely fast. It’s easy to set up an IAST tool to run in development, integration, test, and even production all at the same time. IAST doesn’t require experts and can run continuously without any extra hardware. At Gartner's 2014 Security & Risk Management summit, Joseph Feiman called IAST a “breakthrough technology” and urged organizations to start evaluating and deploying IAST solutions.

The world’s first free IAST tool
Just recently, Contrast Security released the world’s first free IAST tool. It’s a plugin for Eclipse and you can find it for simple installation in the Eclipse Marketplace. Any developer can be up and running with Contrast for Eclipse in a matter of minutes. Click “Start with Contrast” on your application server and watch the vulnerabilities roll in as you browse your application. The plugin finds almost all of the OWASP Top Ten with excellent results.

Rolling Contrast for Eclipse out to your development team means that they will be able to find their own vulnerabilities and solve them immediately. This is the most satisfying and cost-effective way to do security as it saves all the downstream work of finding, triaging, fixing, testing, and releasing vulnerabilities.

The Future of AppSec tools
It might be possible to force development organizations to use slow tools, but they won’t like it. In fact, they’ll probably go out of their way to prevent these automation efforts from interfering with their software development, especially if those tools cause them to perform unnatural acts to use them, or when they start to regularly miss their launch windows.

The world has shifted. The SAST and DAST tools that were invented over a decade ago are no longer viable approaches to application security. Being “fast” is now what it takes to be successful as a security technology in the fast-paced world of software development. Being “fast” doesn’t only mean speed and scale. Fast application security tools are culturally compatible with the way modern software is developed, which turns out to be critical.

The future is unquestionably going to demand better application security, and that means that software development organizations must cultivate a culture and technology stack that encourages developers and security specialists to work together to build great software. And that means tools must be “fast.”