Software tools are constantly offering new ways of working which enable organisations to compete. Patrick Carey, Director of Product Marketing at Synopsys, says that as the shape of software development continues to evolve, so too must the mechanisms to secure it.
The first software development team I worked on operated on the follow mantra:
- Make it work.
- Make it fast.
- 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 — the security of an application isn’t so easily observed or quantified, at least not until there’s a security breach.
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 get done.
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.
It doesn’t have to be this way, and other findings in the survey 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 too. 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 integrated development environment (IDE).
Keep score
If what gets measured gets done, then it’s important to measure the progress of both your AppSec testing and security training programmes. 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?
We must also recognise that there can be too much of a good thing in terms of security tooling. ESG reported over a year ago that organisations, on average run 25 to 49 security tools from up to 10 different vendors. Some of these are monitoring tools for IT infrastructure, such as network, endpoint, wireless, identities and so on. But it applies to software development as well.
Analysts like Forrester and 451 Research have reported on security tool sprawl in the past year, noting that as many as 40% of organisations admit that their development teams are so overwhelmed by security alerts that they can’t respond to at least 25% of them. Indeed, when security alerts are so constant, they become background noise and are ignored — the exact opposite of the intent.
It shouldn’t be this way. The right combination of tools that run the right tests at the right time can help security keep pace with development, which has moved into hyperdrive over the past few years. And still, there is a persistent perception that if some tools improve your security, more will improve it even more. Unfortunately, it could be just the opposite. If you pile too many tools on your development team, especially if you can’t coordinate them on a single platform, your developers are more likely to ignore critical alerts.
Too many tools can even expand your attack surface if they don’t communicate securely or aren’t updated regularly. So what can you do?
Take an inventory of your security tools
Eliminate tool sprawl by taking a rigorous inventory and evaluating it. Know what you have and what it’s intended to do. It’s of great importance also to make sure your tools are properly configured, deployed and are up to date. And then evaluate: are they doing what they’re supposed to? Is any tool doing the same thing that another tool might be doing better? If a security tool is inferior or redundant, get rid of it. Security clutter is the last thing you want.
Make sure tools complement one another
Be sure your tools can work together. It doesn’t matter that a single tool is considered best in class if it can’t play nice with all the others. Your tools need to integrate with one other and into your workflow, which makes it easier to embed security into the SDLC from start to finish. As the experts say, the best way to encourage developers to add ‘Sec’ to DevOps is to make the secure way the easier way.
Integrate tools into your workflow
The way to make security easier, and combat security tool overload in the process, is to integrate your security tools into a single platform with a dashboard that flags bugs and other potential defects as you go. It’s far better than forcing developers to return to code they wrote weeks ago to deal with problems you discovered today.
High velocity development is the future, there’s no denying it. And while security must keep up with methodologies such as DevOps, it must be carried out in a way that enables development teams to build security into their existing processes. As the shape of software development continues to evolve, so too must the mechanisms to secure it — and that doesn’t simply mean an overabundance of security tooling.
