Under Pressure: Managing The Competing Demands of Development Velocity and Application Security

INDUSTRY.co.id - The first software development team I worked on operated on the follow mantra:

Make it work.

Then, make it fast.

Then, make it elegant (maybe).

Meaning, don’t worry about performance optimisations until your code actually does what it’s supposed to do, and don’t worry about code maintainability until after you know it both works and performs well. Users generally have no idea how maintainable the code is, but they do know if the application is broken or slow. So more often than not, we’d never get around to refactoring the code — at least not until the code debt started to impact application reliability and performance.

Today that developer mantra has two additional lines:

Ship it sooner.

And while you’re at it, make it secure.

As with application performance and reliability, delivering an application on time is easily quantified and observed. Everybody knows when you miss a deadline — something that’s easy to do when your release cycles are measured in weeks, days, or even hours. But the security of an application isn’t so easily observed or quantified, at least not until there’s a security breach.

Why are vulnerabilities overlooked?

It should come as no surprise, then, that nearly half of the respondents to the modern application development security survey, conducted by Enterprise Strategy Group (ESG), state that their organisations regularly push vulnerable code to production. It’s also not surprising that for over half of those teams, tight delivery schedules and critical deadlines are the main contributing factor. In the presence of a deadline, what can be measured is what’s going to get done, and what can’t be (or at least isn’t) measured often doesn’t.

However, “we don’t have time to do it” doesn’t really cut it when it comes to application security. This is demonstrated by the 60% of respondents who reported that their applications have suffered OWASP Top 10 exploits during the past 12 months. The competing demands of short release cycles and improved application security are a real challenge for development and security teams.

You actually can build secure, high-quality software faster

It doesn’t have to be this way, and other findings in the survey report point to opportunities that teams have to both maintain development velocity and improve application security. Here are just a few:

Reject silver bullets. Gone are the days of security teams simply running DAST and penetration tests at the end of development. A consistent trend shown in the report is that teams are leveraging multiple types of security testing tools across the SDLC to address different forms of risk in both proprietary and open source code.

Integrate and automate. Software development is increasingly automated, and application security testing needs to be as well. Over half the respondents indicated that their security controls are highly integrated into their DevOps processes, with another 38% saying they are heading down that same path.

Train the team. Most developers lack sufficient application security knowledge to ensure their code isn’t vulnerable. Survey respondents indicated that developer knowledge is a challenge, as is consistent training. Without sufficient software security training, developers struggle to address the findings of application security tests. An effective way to remedy this is to provide “just-in-time” security training delivered through the IDE with a solution like Code Sight.

Keep score. If what gets measured gets done, then it’s important to measure the progress of both your AppSec testing and security training programs. This includes tracking the introduction and mitigation of security bugs as well as improvements to both of these metrics over time,  i.e., who is writing secure code and who isn’t, and are they improving?