Skip to main content
July 24, 2015

The Scalability Challenge, Part Two: Maintaining Both Speed and Security in the Software Development Lifecycle

The Scalability Challenge, Part Two: Maintaining Both Speed and Security in the Software Development LifecycleSpeed kills, but so does slowness. Those six words go a long way in explaining the complicated relationship between speed and security, not to mention a classic trade-off problem in the development world: Every organization needs to secure the software it's developing, but none can risk slowing its software development lifecycle in the process.

In a lot of ways, however, this problem is as old as the era that spawned it — one that didn't have anything resembling the tools or level of automation we do today. Back then, more testing really did mean missed time-to-market deadlines. When your tools consist largely of in-house or vendor-supplied solutions that must be run locally and by manual testing personnel, work-arounds are in short supply, and redos, "baked-in" wait times and other problems inherent to the old way of doing things run rampant.

In my first article highlighting Veracode's "Addressing the Scalability Challenge with Cloud-Based Application Security" white paper, I provided an overview of five common application security challenges that global organizations confront. Now, I'll look at the first challenge more in depth, and how the combination of philosophical change, technological change and a little expert advice can help firms scale security in a lifecycle-friendly way. Here's a high-level look at some of the white paper's takeaways.

Speedy Iterations: Secure by Definition

In the old days, security was handled at a set point, which was a necessity given the number one rule of dealing with bugs and errors: the longer they go unchecked, the harder and more expensive they are to fix. A bug that isn't caught until just before a product goes live could mean scrapping substantial amounts of workable code. This makes frequent, automated testing an attractive alternative.

The same logic applies to rapid deployment. When the next iteration is never far away, the next fix is never far away, either. That methodology makes sense, considering the way people and organizations order and consume their software.

This idea becomes even stronger in practice when security personnel with a working knowledge of development practices are brought in from the onset, giving them voice in the architectural/design portion of the software development lifecycle, as well as the actual coding. Compared to bringing these experts in at a set time, the enhanced focus on security ensures bugs are caught when it's cheaper and easier to fix them.

Automation and the Cloud . . .

Popular methodologies such as Agile and DevOps place huge emphasis on automation — and specifically off-site automation — when it comes to security testing. That's because no product is at its most secure at any given point in the lifecycle without it.

Many of automation's security advantages are self-evident: The less you use your employees and local hardware on security testing, the more time both have to spend on tasks better suited to their strengths. Beyond that, with automation, in-house code and third-party contributions are continually checked (instead of undergoing ad-hoc or set-point security monitoring), which results in a more secure product and bugs that are easier to fix when they're caught.

Putting the tools that perform these checks in a cloud-based platform is the next step. Consistency is key in security, yet distributed offices and outsourcing are prevalent. Instead of relying on vendors to effectively handle their own security, cloud-based security speeds up software development, checking code and enforcing policy in a centralized, specialized, off-site environment.

. . . And Third Parties

That last point's especially important when first parties don't have direct control over third parties. Often, vendors are reluctant to hand source code over to the companies hiring them, necessitating custom tools in the place of stronger security measures.

SAST provides a work-around by doing deep security scans without requiring access to source code, giving both parties in the vendor relationship peace of mind relative to their concerns. Without source code as a sticking point, first parties can apply the same standards to all contributors from the very beginning, providing tools that work across a broad number of development environments. It isn't direct control, but when supply chain management is one of the hottest issues facing security today, automated solutions are the perfect response.

You can scale your security without inflating your software development lifecycle along the way. In fact, in an industry beset with breaches and time-to-market obsessions, you can't afford not to.

To learn more about how to integrate both into your software development lifecycle, check out Veracode's white paper. There, you'll find solutions to a number of increasingly common development problems, including tips on hardening your SDLC without lengthening it as well.

Photo Source: Wikimedia Commons

Evan Wade is a professional freelance writer, author, and editor from Indianapolis. His time as a sales consultant with AT&T, combined with his current work as a tech reporter, give him unique insight into the world of mobile/Web security and the steps needed to properly secure software products. Follow him on Twitter.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.