Managing competing demands of development velocity and application security – Intelligent CIO ME

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:

Meaning, dont worry about performance optimisations until your code actually does what its supposed to do, and dont 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 theydoknow if the application is broken or slow. So more often than not, wed 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:

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

It should come as no surprise, then, that nearly half of the respondents to themodern application development security survey, conducted by Enterprise Strategy Group (ESG), state that their organisations regularly push vulnerable code to production. Its 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 whats going to get done, and what cant be (or at least isnt) measured often doesnt get done.

However, we dont have time to do it doesnt really cut it when it comes to application security. This is demonstrated by the 60% of respondents who reported that their applications have sufferedOWASP Top 10exploits 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 doesnt have to be this way, and other findings in the survey point to opportunities that teams have to both maintain development velocityandimprove application security. Here are just a few:

Reject silver bullets

Gone are the days of security teams simply running DAST andpenetration testsat the end of development. A consistent trend shown in the report is that teams are leveraging multiple types of security testing tools across theSDLCto address different forms of risk in both proprietary and open source code.

Integrate and automate

Software development is increasingly automated andapplication security testingneeds 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 isnt 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 its 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 isnt 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 likeForresterand451 Researchhave 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 cant 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 shouldnt 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 cant 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 dont communicate securely or arent 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 its intended to do. Its 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 theyre 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 doesnt matter that a single tool is considered best in class if it cant 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. Its 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, theres 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 doesnt simply mean an overabundance of security tooling.

Facebook Twitter LinkedInEmailWhatsApp

Read the original here:

Managing competing demands of development velocity and application security - Intelligent CIO ME