Chef has extended the reach of its InSpec compliance automation framework by adding a plug-in architecture that makes it easier for developers to programmatically generate compliance controls that can be applied to automation frameworks. The Terraform configuration management framework developed by HashiCorp is the first framework supported via the plug-in architecture. InSpec previously was integrated with the open source Ansible automation framework.
Julian Dunn, director of product marketing for Chef, said the plug-in architecture supports multiple communications protocols to extend it to multiple frameworks beyond the Chef IT automation framework.
InSpec 3.0 also makes it easier to describe new resources that can be tested in addition to a stable application programming interface (API) that enables DevOps teams to modify how tests are conducted. Improvements to a packaging mechanism for profiles will also make it easier for developers to more easily iterate on InSpec profiles with dependencies.
Finally, InSpec 3.0 adds a key value-based description interface to enable more fine-grained reporting as well as de-duplication of controls that satisfy one or more compliance regimes. This allows organizations to create their own custom metadata categories.
In general, Dunn notes that application development and deployment, thanks to the rise of DevOps, is moving at a pace that exceeds the ability of those tasked with compliance to keep pace. As a result, responsibility for compliance needs to shift left along with other aspects of cybersecurity, said Dunn.
Dunn conceded it is still early days in terms of making that shift. But as more organizations discover that the rate at which applications can be deployed is being held up by compliance audits, the more incentive there is to enable developers to programmatically insert the appropriate controls into their applications. Once those controls are in place, InSpec then generates human-readable code that serves to reduce the amount of time required to pass an audit before and after an application is deployed in a production environment, said Dunn.
Of course, passing a compliance audit doesn’t mean the application is secure. But it does at the very least provide a baseline for what’s required to make an application nominally secure. In fact, the path of least resistance to any shift toward embracing DevSecOps might be automating the processes for putting compliance controls in place.
While there are hundreds of regulations requiring various levels of compliance, it turns out most of them require the same types of controls to be in place. Once organizations begin to programmatically embed those controls within their applications, the speed at which those applications are certified to comply with multiple regulations should increase. There will be less reason for developers to skip a compliance control to meet an application development deadline when that control can be integrated automatically.
None of this means that people with risk management backgrounds will be participating in DevOps processes anytime soon. But it does means that the output from DevOps teams won’t be stacked up waiting to pass a compliance review because all the applications in front of it are missing one key control or another.
