Is Continuous Delivery the Control Framework for DevOps?

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?

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.

StackExchange DevOps Q#693, answer score: 3