Agile security in cloud DevOps

Managing cyber security risks when building software at DevOps speed

Caleb Queern

Caleb Queern

Director, Cyber Security, KPMG US

+1 571-228-8011

It’s 2020. No one disputes two major trends: cloud is the appropriate solution for most new, important IT projects and DevOps software development practices are required to remain competitive in the marketplace. All large organizations are somewhere on their journey in both areas. Among their challenges is what it means to manage cyber security risks when building software at DevOps speed and cloud scale.

Journey Tired Wired Inspired

Building new applications in data centers

Building new applications in the cloud using legacy architecture patterns used in data centers

Building new applications using cloud native serverless computing, data & object storage services


Following Waterfall development patterns with infrequent deployments

Configuring a CI/CD pipeline tool differently for each development team

Transforming the development lifecycle through centralized pipelines, powerful Infrastructure as Code capabilities, and integrated security checks


Reducing risk by applying security when software code is in production with penetration tests

Reducing risk by manually scanning code for vulnerabilities prior to deployment

Reducing risk by using automated, low friction scrutiny that is risk calibrated and easily auditable

The right strategy for becoming a high performing, secure software development organization in the cloud begins with identifying the necessary risk reduction functions to build software. These outcomes can be derived by examining the Software Development Life Cycle (“SDLC”) and analyzing which capabilities, controls, or behaviors are desired across the separate phases. With that list of the “whats” the question turns to the “how” to deliver them in the cloud.

Here is one example of what “good” looks like. Step back and imagine you wanted to ensure your organization could identify and react to potentially malicious activity in your applications. Would you create a separate data lake of relevant logs for each of your applications, apply different detection rules, and expect effective detection and response activities? No, because decentralized monitoring is unlikely to deliver mature, consistent capabilities at speed. For the same reason, when organizations migrate to the cloud, business leaders should take the opportunity to align their development teams on a common Continuous Integration / Continuous Delivery (“CI/CD”) pipeline. This practice of creating a “golden road” has multiple advantages:

  1. Want Static Application Security Testing (“SAST”) or Dynamic Application Security Testing (“DAST”)? Fuzzing? Want to generate software bills of materials (“SBOMs”) to have an inventory of the open source software in your environment, or the ability to scan containers? A common CI/CD pipeline facilitates a single place for these security capabilities to be applied prior to deployment in a consistent, predictable manner. This saves the cost and inefficient time expenditures manually setting up “one off” scans that slow down developer teams that need to move at DevOps velocity.
  2. The pipeline automation is a developer’s dream and can take the place of certain legacy touch points with InfoSec. The same way that no one looks forward to a security checkpoint in the airport, manual or face to face security team involvement prior to deploying new code to production is something many developers will go out of their way to avoid. If you can provide this enhanced experience, developer teams will be more motivated to migrate to your pipeline.

Cloud native applications built by DevOps teams look different in production than legacy applications and are more likely to take advantage of serverless technology, APIs and microservices. Securing each will require new skills on the security team and corresponding technical controls such as API gateways and service meshes. While these may be new to many security teams, one familiar security primitive is asset management; standards and policies should prioritize decent asset tagging to capture who owns what to apply the appropriate security measures in the cloud.

For organizations well on their cloud Devops journey and ready for another opportunity to reduce risk, chaos engineering is an option. Chaos engineering is the practice of performing experiments on production systems to identify weaknesses in complex systems. Like their peers in Site Reliability Engineering teams, the security organization should consider learning to perform these controlled experiments that can identify unknown risks in cloud production systems.

While the cloud technology is alluring, leaders must not forget the human aspect. Security teams with less engineering background can focus on or be realigned to performing important complimentary services such as threat modeling, security champions programs, and bug bounty programs. Each are low friction methods for preventing or detecting vulnerabilities in your DevOps teams’ cloud applications.

This may all sound like a lot. Keep in mind the basics: As security “shifts left” in the product lifecycle in cloud environments, security teams can make a more profound impact on the actual security of the product with less business friction. Know that there is no threshold for “achieving DevSecOps.” It may take many organizations the better part of this decade to get this right. The most powerful business transformations come from incremental progress over time.