We’re excited to announce the release of InSpec 3.0! Since the last major revision of InSpec in February, InSpec has been downloaded 49270 times, we’ve merged more than 330 pull requests from 85 contributors, and added dozens of new resources. The 3.0 release includes a ton of bug fixes, usability improvements, and additional platform support. Today I’d like to share some of the highlights, but for a full list of updates, be sure to check out the InSpec Changelog.
With InSpec 3.0, you can now create, install, and search for plugins that allow you to extend the capabilities of InSpec. Plugins come in two varieties:
InSpec plugins (prefixed with inspec-) provide new functionality for the InSpec CLI, adding new commands beyond those included out of the box.
InSpec Platform plugins (prefixed with train-) extend InSpec with the ability to communicate with targets and API endpoints beyond those covered in InSpec’s built-in transports (e.g. SSH, WinRM, AWS, Docker).
For example, the community plugin inspec-iggy provides an inspec terraform generate command that will evaluate a .tfstate file, and dynamically generate an InSpec profile with the appropriate controls to validate the environment. We’ve also released an InSpec provisioner for Terraform that provides built-in facilities for running InSpec Profiles as part of running terraform apply. Plugins can also work in tandem with InSpec Resource Packs, which allow users to create their own custom resources. The inspec-digitalocean resource pack, for example, provides new resources like digitalocean_droplet and digitalocean_loadbalancer and uses the new train-digitalocean plugin to allow you to inspect your DigitalOcean estate directly over their API.
To find out more about installing or creating InSpec plugins, be sure to check out the Plugin Documentation.
Security validation can have myriad exceptions, edge cases, and severities, and with InSpec 3.0, we’ve made it easier than ever to get actionable output from your InSpec scans. Here are some of the highlights!
Improved Skip Messaging
InSpec allows you to conditionally skip controls that aren’t relevant to a particular system without necessitating a unique profile for each of your server or application permutations. Historically, it’s been difficult to tell why a particular control was skipped without digging into the source code, but now each constraint can be given a descriptive message to be displayed directly in the scan output for easy validation whenever a control is skipped.
Multiple Control Descriptions
When creating InSpec controls, you can now provide multiple description fields to provide additional context for each rule being evaluated. Additionally, the desc parameter can now be given two arguments, which will use the first as a header when rendering in Chef Automate, and the second as its content when expanded. This allows users to provide more detailed, categorized descriptions for each control evaluated in their environment.
Text-Based Severity
Each control’s severity is defined by the impact parameter, which ranges from 0.0 (minor) to 1.0 (critical). Users can now alternatively define an impact as 'low', 'medium', 'high', or 'critical' for easier readability.
#inspec channel in Chef Community Slack to chat with us and our community about ll things InSpec.