Scroll to top

Is DevOps an Obstacle to Application Security


‘You can take the initiative and lead the first pilot implementation, wait for it to happen in your organization and engage early, or you can pretend it won’t happen and be replaced.’ Dell’s chief security architect David Mortman’s advice to IT security teams.

Enterprises spend some $40 billion a year on information security even though attackers target software more than they do networks, hosts, data and people. Security for software receives just $500 million of that $40 billion. This was a key point Sonatype’s CTO Joshua Corman made at the 2015 RSA conference.

Corman said application security was further compromised by more and more enterprises assembling code from existing building blocks, much of it from unvalidated open source elements, instead of writing their own. ‘That’s why Shellshock and Heartbleed and issues with the software supply chain have been killing us,’ Corman added, ‘because our software’s been assembled from code of unknown origin with unknown risk. This is one of the reasons why it’s open season on open source.’


The essence of DevOps relies on Continuous Delivery by assembling code and continually testing small batches on an automated assembly line. DevOps also promotes a change in culture because it encourages development and operations teams to work hand-in-hand to streamline software development. These are the 5 main phases of DevOps:

  • Continuous development
  • Continuous testing
  • Continuous integration
  • Continuous deployment
  • Continuous operations

Each of these phases uses a set of automated tools that can move the application through the entire process to operations.

‘This radical new paradigm has security practitioners asking whether DevOps could kill information security as we know it,’ says James Brown, CXO at JumpCloud in a recent article on WIRED. ‘Here’s the punch line: yes, it will, but it’s not what you think. Ultimately, DevOps will turn the IT business model on its head with shorter cycle times, automation, and deep cross-functional integration to deliver the next great idea.’


DevOps is about integrating software development, IT operations, security and quality assurance under a single automated umbrella. DevOps combines multiple steps into a single, automated process that delivers small, frequent changes and reduces the time needed to release new software or get new business initiatives to market. That’s why more and more enterprises are adopting DevOps principles in their software development processes, but not all IT professionals are comfortable with these.

‘While some see DevOps as a traumatic, frightening shift for IT professionals,’ writes Eric Parizo at TechTarget, ‘the two speakers at RSA said it is proving to be a transformative movement for anyone involved with software security, and that it will eventually become the default methodology for developing and updating software.’


Many enterprises regard IT security teams with suspicion since they don’t deliver anything useful but often get in the way of new initiatives. Like insurance, they see IT security as a necessary cost of doing business. Even software developers and operations teams often treat security as a standalone discipline, a process bolted on to the end of a software development project.

Dell’s chief security architect David Mortman says many IT professionals thought that DevOps ‘hindered security by breaking down the separation of duties, limiting code checks and pushing software iterations into production without proper quality control.’ Mortman argues however that the opposite is true, that DevOps improves software security because its essence is the continuous delivery of small changes through an automated pipeline.

These changes cannot progress through Dev, SIT, UAT and Pre-Prod unless they pass all the automated checks. If they don’t, problems are fixed and the code goes back into the pipeline for the next round of testing. In other words, new code doesn’t go into a live environment without thorough quality control.


The first step is to get the security team on board at the beginning of a project, instead of at the end. DevOps gives you the chance to integrate security into your IT processes from the start, just as it helps you integrate other functional IT areas. DevOps mandates that feedback or input from the teams involved in a project is integrated early on, and that relevant checks are built into the automated delivery pipeline.

DevOps integrates a number of functional areas in a project, so why should those areas not include security? While DevOps is a powerful paradigm shift, James Brown argues, ‘companies often don’t understand how security fits. DevOps is actually a boon for security folks,’ he says, ‘who can, with the right automation and operational tools, inject security earlier into the development process, and increase the security of the code that ultimately reaches production.’


Security specialists are often reluctant to embrace DevOps, preferring their stand-alone position, and you may have to show them how it makes their jobs easier. An obvious benefit is that smaller, finite deliverables with contained functionality are much simpler to test from a security perspective than bigger systems.

Security teams also have a lot in common with operations teams, since both are committed to keeping the business running and to ensure critical applications and data are well-protected. The last thing both teams want is an attack that exposes sensitive data or interferes with the smooth running of the business. So why not include the security team from the start and bring them on the DevOps journey as well, rather than regarding them as road blocks?


The IT industry’s move to the cloud has given rise to many security concerns, yet the elasticity and advanced tools offered by cloud platforms have seen enterprises move into the cloud en masse. The agile environment makes it so much easier to deliver services, most of all to online users.

‘Securing DevOps and cloud applications is different from traditional IT security models,’ says David Linthicum of Cloud Technology Partners. Not long ago, organizations used security tools and appliances to create a defensive perimeter around enterprise applications and data. With that perimeter long gone, enterprises must build effective security into their new cloud applications.

They ‘need to build security into every step of the development process,’ says Linthicum, ‘and into every part of the application. This is a fundamental change for organizations deploying DevOps, and many don’t figure it out until it’s too late.’

Linthicum’s final argument is that enterprise applications will be more secure in the cloud than traditional applications that run on premise, as long as organizations ‘properly roll out DevOps and manage their cloud platforms.’ He points to the fact that most of the big hacks in recent times involved traditional on-premise systems , not the cloud or DevOps.


Rugged DevOps is an approach that is promoted as a way to provide more secure cloud platforms without hindering continuous integration and application delivery. Its advocates have developed a Five-step model:

  1. Automate manual security testing Automation is key in DevOps because it ensures accuracy and speed. Manual security testing just isn’t fast enough and often misses defects.
  2. Prioritize security earlier To synchronise security and DevOps cycles, it pays to conduct security tests from the start of the development process.
  3. Create cross-functional team participation To implement rugged DevOps, security teams need to work closely with development and operations teams. That works best when the cooperation becomes a proactive partnership, not a formal necessity.
  4. Embed security tools into operations Putting their security tools in a general operations toolkit and sharing their technical knowledge helps small security teams ‘extend their operational influence across larger DevOps organizations.’
  5. Monitor and audit integration processes This ensures high-quality software and helps identify security issues as they arise, in conjunction with cloud security monitoring tools that can automatically track changes from newly added resources to software configurations.

At LimePoint we developed DriftGuard to monitor Oracle and non-Oracle environments, and to fill the gaps left by DevOps software configuration and deployment tools, such as Chef and Puppet.


DevOps is far from perfect and processes fail all the time, but that’s one reason why the concept works so well: because the batches are small and contained and defects easily fixed with the right tools. The emphasis DevOps places on repeatable processes means automating as many tasks as possible – humans make mistakes, most of all when carrying out repetitive tasks.

Of course DevOps has its drawbacks. It needs a culture change in the organisation, and frequently attitude changes in IT teams as well. DevOps also needs good communication and cooperation to work. Another drawback is that it doesn’t play well with legacy systems, and is better suited to new projects.

‘The topic of DevOps generates huge enthusiasm amongst many,’ writes Alex Manly, ‘and it’s great that we have a number of fantastic luminaries who trot the globe spreading the word [but] don’t let your passion spill over into arrogance.’

Read more about DevOps here. Contact us about achieving DevOps in your organisation.

Related posts