From Ops vs Devs to DevOps vs Compliance

Integrating security and compliance into the software pipeline is a logical extension of DevOps, says Chef's Simon Fisher

It's easy to see how DevOps and compliance could be at loggerheads, especially in large organisations. After all, DevOps is all about getting software out to the consumer in ever quicker cycles, whereas compliance is the painstaking process of ensuring that the code meets all the requirements demanded of it in terms of rules, regulations and security.

The rules stipulated by regulators such as the Centre for Internet Security (CIS) tend to be published in documents that may be hundreds of pages long in the case of hardening an operating system, and which contain dozens of commands that have to be applied to each instance of the software in question.

Traditionally, compliance has been implemented on a beta product, with questions asked and tests run after the software has left the production line, but this is no longer acceptable, said Simon Fisher, solutions architect at automation firm Chef, speaking at Computing's DevOps Summit today.

"There are two main problems with this method of ensuring compliance," he said. "First, the teams are all talking a different language. You've got siloed security and compliance staff that work on command line and documentation and developers that work in code."

The second problem concerns scalability: "How do we repeat this across our estate at scale in a timely manner?"

However, as developers have merged with testers to become DevOps and as infrastructure has become code, it is not too big a leap for compliance to be implemented into code and baked into the software production pipeline.

The CIS typically documents hardening procedures as profiles in the form of Security Content Application Protocol (SCAP), an industry standard XML-like format that is hard to read by coders and project managers and thus a potential bottleneck to production. But by automatically converting SCAP to code (Chef uses Inspec) and using that code to power dashboards to provide a visual representation of which parts of the system are compliant and which require attention, such blockages can be removed.

"At Chef our mantra is 'automate everything'," said Fisher. "And we apply that to compliance too."

Ingesting SCAP profiles, generating code from them and integrating that code into the production pipeline means that any changes are automatically incorporated into the software. Profiles can be edited as needed too, increasing flexibility.

"When something new appears in a SCAP profile it's really easy to incorporate this into your workflow," Fisher said. "You can also add your own enterprise-specific rules in there too, like company standards for example, and any CIS rules that don't apply can be skipped."

Increasingly infrastructure is represented by code and this enables the issue of scalability to be tackled by automation, Fisher went on.

"Once you've got your CIS profile set up for Linux or Windows or whatever you're using, you can run it across your whole estate with one command."

He illustrated the benefits of automation by describing a CIS profile that contained 184 commands.

"As you might imagine, copying and pasting all those commands across a whole system would take a long time," he said.

By contrast, automating the process and delivering compliance as code allows a compliance manager to "check compliance across the whole system at the click of a button... with non-compliant areas highlighed in red on a dashboard".