I've been reading Jim Bird's DevOpsSec book, one of the statements in Chapter 4 - Security as Code is as follows:

Agile ideas and principles—working software over documentation, frequent delivery, face-to-face collaboration, and a focus on technical excellence and automation—form the foundation of DevOps. And Continuous Delivery, which is the control framework for DevOps, is also built on top of a fundamental Agile development practice: Continuous Integration. (O'Reilly 2016, ISBN 9781491971413)

My understanding of a control framework was that it declares certain Control Objectives such as:

  • Payments are made only for authorised products and services received.

This may be satisfied by some process built into the system, and would likely have a number of checks and balances; however, you wouldn't say that that process is the Control Framework.

To me it feels that that sentence should read: "And Continuous Delivery satisfies the Control Framework for DevOps".

Am I totally wrong? Is Continuous Delivery the Control Framework for DevOps?

Or, am I right and Continuous Delivery is not the control Framework for DevOps?

  • Aww , how you twist it to come to a question is fun. +1 for the voluntary ´naive ´ interpretation. Have to think how to tackle it now :/
    – Tensibai
    Mar 27, 2017 at 20:56
  • Ha - part of me wants someone to say, no, you have missed the point of Control Frameworks and this is the reality. My life would be so much simpler that way. Mar 27, 2017 at 21:00
  • Sorry if I have been rude, that was not the intent. I'll try to write my interpretation of it
    – Tensibai
    Mar 28, 2017 at 4:55
  • 2
    The answer is easy: No. Continuous Delivery is one of the many frameworks used during an implementation of DevOps ideas, in one very specific area. Kanban is another type of DevOps framework. It is not "the" framework, it is just one of many. Even when it comes to Software Delivery specifically, CD is just one way to do it. I know, I've implemented successful alternative long before DevOps was even a thing. Mar 28, 2017 at 5:21
  • @Tensibai not rude at all, looking forward to your answer. Mar 28, 2017 at 7:08

2 Answers 2


In my opinion you are right, Continuous Delivery (CD) is not the control framework of Devops, at least it is not the only possible one.

But in the context of the book you're quoting it gets the most used possibility when you start to include security baseline and assessments as part of the product delivered.

In a security context, you'll add smoke tests in a post deploy phase to ensure your application is not subject to XSS or Sql injection for example. If any of this tests fail, block any deploy in other environment, mark the deploy as failed and eventually rollback to previous version.
This enforce the security rules to be satisfied, and in this way act as a control framework to ensure production deploy are 'safe' for known vulnerabilities.


I would say 'Yes' in the context of 'Security as Code', e.g.:

As the author stated, if I have continuous delivery that means I have continuous integration, which implies I can easily integrate and propagate change throughout the system, and likely this is due to prescriptive code-based configuration.

This alone could be a form of control as you can hopefully easily propagate compliance related changes across your infrastructure

However, I think configuration management exemplifies compliance controls in a devops lifecycle. Look at Chef\DSC and InSpec\ServerSpec. You can run configuration management during the bake phase to set initial configuration and then run it on a schedule after deployment as a form of compliance to eliminate drift. InSpec\ServerSpec tools sit outside that CM and 'audit' the state of the systems to ensure the CM is doing its job.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.