This article is based on reporting originally published by TechTarget, drawing on interviews and sessions from ChefConf 2017 in Austin, Texas.
Security and Compliance as Code: The Next DevOps Frontier
As enterprise IT teams grow more comfortable with infrastructure as code and continuous delivery pipelines, attention is turning to the next automation frontier: security and compliance. Rather than treating audits and regulatory checks as manual, point-in-time exercises, DevOps practitioners are exploring whether the same code-driven, repeatable approach that transformed infrastructure management can be applied to compliance controls.
At ChefConf 2017 in Austin, practitioners from a range of industries described real-world experiments with tools such as Chef InSpec and Chef Compliance — and were candid about the obstacles that remain.
What Are Chef InSpec and Chef Compliance?
InSpec is an open source testing framework designed for automated compliance and security checks. It lets engineers describe compliance requirements as human-readable, version-controlled code, then execute those checks automatically against infrastructure. Chef Compliance is the management layer used to coordinate InSpec scans across fleets of servers and surface results in a centralised dashboard.
Michael Glenney, a solutions architect at New Context, a San Francisco-based consulting firm, described InSpec as an easier adoption story than other emerging Chef products such as Habitat and Automate. He attributed this to a clear gap in the market: most existing security scanning tools produce output that is difficult for developers and ops engineers to work with directly.
InSpec offers a common language for security, developers, and ops to implement compliance controls — while other tools can be ‘a clump of XML.’
Michael Glenney, Solutions Architect, New Context
Singing the Same Old DevOps Skills Blues
The challenges facing security and compliance as code closely mirror the broader skills challenges in DevOps: finding people who can bridge the gap between technical tooling and domain-specific knowledge is hard, and that difficulty is amplified when the domain is regulatory compliance.
Translating human-readable regulatory documents into machine-executable compliance checks is still largely a manual, human-driven process. InSpec includes a plugin for the Security Content Automation Protocol (SCAP), which is designed to convert structured regulatory documents into code. However, SCAP has meaningful limitations: it cannot capture non-technical controls or best-practice guidance, and its impact-scoring model does not map cleanly to Chef Compliance severity codes, according to John Ray, a senior consultant at Shadow-Soft, a systems integrator based in Atlanta, who presented at ChefConf.
Beyond the tooling gap, practitioners still need to:
- Ingest and evaluate compliance controls in the context of their specific environment
- Work with business stakeholders to understand the practical impact of each control
- Write a formal specification for how each control should be tested
- Author the InSpec code that executes those checks automatically
Even large enterprises with significant resources find this skill set elusive. Verisk, a data analytics firm in Jersey City, New Jersey, that runs AWS OpsWorks for Chef Automate, was exploring InSpec adoption at the time of the conference. Its OpsWorks licence entitled it to use both InSpec and Compliance Server. CTO Eric Schneider described InSpec as a potential way to integrate compliance rules with the diverse data sets Verisk manages — but acknowledged that the company had not yet worked through the deployment details.
We wish we could wave a magic wand and people who knew how to use these tools already would just appear.
Michael Ryan, Cloud Architect, Verisk
Wanted: Documentation and Training
Ray Crawford, DevOps manager at Trek Bikes, a bicycle manufacturer and distributor in Madison, Wisconsin, described a goal that many practitioners share: embedding security and compliance checks directly into the development environment, well before code reaches the delivery pipeline. That way, compliance becomes a shift-left concern rather than a last-minute gate.
I’m the ops guy — I’m the one who’s either hacking it to make it work and get it over the finish line, or I’m the one telling them ‘no’ on behalf of Infosec. So it’s me that gets a black eye, not Infosec.
Ray Crawford, DevOps Manager, Trek Bikes
Crawford saw InSpec’s most important organisational benefit as a clear division of responsibility: security professionals could own and maintain the compliance code, freeing DevOps teams from having to be subject-matter experts in regulatory frameworks. In practice, however, Trek’s team did not yet have the capacity to take on a new toolchain while simultaneously working through infrastructure automation fundamentals. Crawford estimated it would be several months before his team could seriously engage with InSpec.
On the skills shortage, Crawford took a pragmatic approach, favouring the development of junior talent over expensive specialist contractors:
I prefer a dozen interns who are smart, capable, and eager to learn over a super-expensive IT ninja who came from a place that paid him $200 an hour, is here because we pay him $210 an hour, and is going to leave as soon as he finds someone else to pay him $225.
Ray Crawford, DevOps Manager, Trek Bikes
Crawford also identified a systemic gap in the Chef ecosystem: documentation and community tutorials were not keeping pace with the speed of product changes. Specific examples of under-documented patterns he cited included triggering a Chef run immediately after a server restart, and constructing a Jenkins pipeline using Chef cookbooks.
Chef Platform Integration and Cloud Expansion
On the product side, Chef announced at ChefConf 2017 that Chef Compliance’s dashboard view was being integrated into the broader Chef Automate product, continuing a consolidation that had started roughly a year earlier. The goal was to bring all workflow, compliance, and visibility capabilities under the Automate umbrella, with Chef Compliance remote scanning functionality slated to be folded in over time.
Chef also announced incubation projects to extend InSpec scans beyond server operating systems to cloud control-plane APIs — specifically AWS, Azure, and vSphere. At the time, some Chef partners were already using these capabilities in AWS environments, though they had not yet reached general availability.
Crawford said he would consider adopting Chef Automate, but expressed concern that the rapid pace of platform changes was itself a documentation liability:
It’s true of any rapidly changing software framework — docs and blog posts aren’t current, and you have anxiety and stress as you try to cobble together the pieces. It’s not a platform with well-established patterns like C# or Java.
Ray Crawford, DevOps Manager, Trek Bikes
Key Takeaways for DevOps Teams
- Compliance as code is technically feasible but requires practitioners who understand both the regulatory domain and the tooling — a rare combination.
- SCAP integration helps convert structured regulatory documents into InSpec checks, but non-technical controls and scoring discrepancies still require human judgement.
- Organisational readiness matters as much as tooling. Teams already stretched by infrastructure automation adoption may not have the bandwidth to absorb compliance tooling simultaneously.
- Documentation debt is a real risk in fast-moving ecosystems. Teams should budget time for evaluation and expect to supplement official docs with community resources and direct experimentation.
- Investing in junior talent development may be a more sustainable approach to skills gaps than competing for expensive specialists in a tight market.
- Cloud API scanning — extending compliance checks to AWS, Azure, and vSphere control planes — represents the logical next step beyond OS-level configuration checks.