DevOps without the security sacrifice

Kevin Bocek, Chief Security Strategist, Venafi, examines how to accelerate fast IT without sacrificing security.

Earlier this year, Gartner research showed that 60% of organisations are using or will soon use DevOps. Businesses are adopting bimodal IT – relying both on traditional (slow) IT and newer methods that deliver faster time-to-market and continuous improvement of business technology. DevOps, one of the most popular new philosophies, provides IT services quickly to support innovation and faster development of new features.

There is no doubt that DevOps accelerates the deployment and rapid evolution of business technology and delivers numerous advantages such as:

  • Faster response times to address market changes or customer requirements more quickly. Companies that have embraced a DevOps methodology increased their speed to market by 20%.
  • Increased customer satisfaction through frequent product updates based on continuous feedback from users.
  • Better operational efficiency due to automation, resulting in more than 60% of organisations adopting DevOps approaches.

Slow security processes challenging DevOps

However, as with every new technology, the rewards do not come without risks. In fact, nearly 80% of CIOs are concerned that DevOps makes it more difficult to know what’s trusted and what’s not. In order to maximise the speed of delivery of these services, it’s not uncommon for DevOps teams to overlook security. This oversight can have costly consequences, including data breaches, application outages and failed audits.

Let’s look closely at one example of how DevOps is being challenged by today’s slow security processes. Cryptographic keys and digital certificates comprise the foundation of trust and privacy. This foundation enabled explosive growth of the Internet in the 1990s and allows us to trust Internet-based transactions. Recently, cryptographic keys and digital certificates have expanded to include the cloud and the Internet of Things (IoT).

Keys and certificates turn on private, encrypted communications and let us know that a website should be trusted over Hypertext Transfer Protocol Secure (HTTPS). Without them, any website could pretend to be your bank, favourite online store or cloud provider. They’re used to connect applications, administrators and clouds over Secure Shell (SSH). Digital keys and certificates authorise digitally signed code to run on iOS and Android devices, Windows and OS X operating systems and even Boeing and Airbus aircraft.

But the process to issue and deploy keys and certificates has historically been slow and complicated – the exact opposite of DevOps’ goals and objectives. Getting trusted digital certificates can take days, not the seconds the automated and orchestrated DevOps environment expects.

DevOps teams frequently ‘engineer’ their way around this problem. In some cases, DevOps teams use untrusted or unauthorised certificates like those freely available from Let’s Encrypt or GoDaddy. In other cases, they don’t use certificates at all. Either approach makes it more difficult to identify threats, and without HTTPS encryption, data is exposed to attackers. Complicating things further, if HTTPS is used, it’s difficult for security systems to inspect encrypted traffic for threats and attacks.

The open source community, like Lemur from the Netflix security and operations team, has found ways to make it easier for DevOps teams to use keys and certificates. But so far these attempts to improve the security of DevOps systems have only created new, more complex security blind spots.

Creative ways to empower DevOps

The question remains: How can enterprises reap the benefit of DevOps without exposing themselves to additional security risks? Solving this problem requires security teams to think differently – we need to build security into DevOps in a way that is fast and easy. In the same way Formula 1 engineers enable drivers to push the limits, security teams need to find creative ways to empower DevOps to go faster, without compromising security.

Here are some tried and true best practices for keys and certificates that can help DevOps teams embrace speed without sacrificing security:

Automate: make it fast and easy

Organisations should implement procedures to automate the creation and distribution of keys and certificates for use with HTTPS and SSH throughout the build process so that DevOps teams don’t have to do it themselves. Give DevOps a simple, easy-to-use API and bake it in everywhere. This approach allows IT security to eliminate keys and certificates kludges (aka ‘re-engineering’) and keeps data and applications safe and secure.

Maximise visibility to eliminate certificate-related outages

Customer satisfaction is an ongoing endeavour; one service outage and your customer satisfaction rating can plummet. Failure to renew certificates before they expire or improper configurations (as with the Microsoft Azure outage) can be costly. Service failures with applications using HTTPS can result in a downtime of up to US$1 million per hour for high volume services. In order to avoid unnecessary outages, make sure you are able to discover where all application certificates are being used.

Build for new: use a catalogue of recipes

For ‘slow’ IT applications, it’s typical to spend up to 4.5 hours to provision each certificate manually. However, DevOps teams may need to deliver tens or even hundreds of certificates in a matter of seconds. It’s possible to create ‘recipes’ – collections of automation driven through APIs – to orchestrate all of the steps needed to use keys and certificates. Catalogues of recipes that work across development and orchestration environments are critical to making the provisioning of keys and certificates fast and easy and preserve cross-cloud compatibility and mobility.


A DevOps teams should never have to choose between agility and security. By implementing controls and automation for keys and certificates, it is possible to keep DevOps moving at the speed of business without sacrificing security.


Edited for web by Cecilia Rehn.