Leveling Up DevOps Security

Rethinking Security from End-to-End

Table of Contents

  1. Summary
  2. The Cost and Risk of Inefficient Security Remediation
  3. Incorporating Security Across the DevOps Pipeline
  4. Incorporating Security Remediation into the DevOps Pipeline
  5. Conclusion – Save Time and Money with More Automated Remediation
  6. About Jon Collins

1. Summary

Cybersecurity and innovation are not the most comfortable of bedfellows. While every CIO will say security is a top priority, innovation requires speed and a balanced view of risk, whereas security is often associated with a more cautious approach. DevOps practices look to deliver software-based innovation to organizations; anecdotally, we know that security is often postponed until an idea has been tested, which can create challenges of its own. Mature DevOps organizations are looking to incorporate security earlier in the software lifecycle: a principle known as “shift-left” (as the lifecycle goes from left to right) and “security by design” in terms of requirements. In both cases, the idea is to take security needs into account as early as possible. Evidence suggests that the earlier a security flaw is identified and resolved, the less costly it is to do so.

The importance of focusing on security early cannot be overstated; at the same time, “shifting left” only deals with one end of the lifecycle. The alternative is post-deployment, during the deployment and operational stages of DevOps. At this point the attack surface is a complex mix of infrastructure, external services, and software; it involves a number of stakeholder groups including security and operations teams. As a result, the “shift-left” principle is not sufficient alone for a number of reasons:

  1. Not all security issues can be anticipated in advance. Even with comprehensive security testing, some issues will be missed or may emerge based on unexpected events.
  2. The target architecture, and therefore the potential cybersecurity attack surface, is likely to be complex and evolving, for example in terms of multi-cloud. What is seen as lower-risk today, may not be a year later.
  3. Use of open source code and libraries creates dependencies with an external software base that is highly likely to change, the security of which cannot be taken for granted.
  4. Hackers are constantly exploring new ways to exploit organizations and individuals, and can sometimes ‘get lucky’ when a previously unknown vulnerability is revealed.

Such factors mean that even well-tested code cannot rule out cybersecurity risks. Smarter organizations have procedures and practices to remediate, and otherwise deal with security issues and incidents as they happen, on the basis that not every problem can be anticipated in advance; this includes ‘zero-day’ exploits, previously unknown security challenges that suddenly become high-risk. Such practices are beneficial and necessary, for example, to demonstrate compliance with data governance legislation.

For end-to-end security coverage of the application and service lifecycle, cybersecurity needs to both shift-left and shift-right, incorporating post-deployment and automated remediation as well as pre-emptive security by design. We expand on the challenges of doing so, and their costs, in the next section.

Full content available to GigaOm Subscribers.

Sign Up For Free