Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Notes regarding a "next generation" implementation of Chef Inspec scaffodling for Chef Habitat.

Scaffolding vNext


The current scaffolding works really well.

Improvements and rearchitecting the current scaffolding would allow for greater flexibility, visibility and customization in profile use and reporting.


  • Every profile is a Habitat artifact
  • Every profile/artifact can be run stand-alone as a once-off run, or as a service with all the benefits of package subscription and automatic updating that Habitat provides
  • Every profile employed in a scan is reported separately (specified individually on the inspec exec command line)
  • Leverage Habitat for profile dependencies

Nice to have

  • Maintain the list of profiles to be run in a single location
  • Minimal (if any) changes required to existing Inspec profiles



  • We need to retain the ability to modify profiles (eg: Setting custom scores)
  • we need to ensure waivers are intelligently managed either in-artifact, or injectable some time later (during run, with configuration?)


  • Potentially use inputs to define scores/custom values, with defaults in the profile itself.
Copy link

mattray commented Jul 16, 2020

Do we want every profile as a Habitat package or do we want to just have the pull the profiles from their sources at build time? It seems we'll need to do scaffolding for the profiles, which is probably a new set of scaffolding (ie. effortless-audit-profile). We need to support Automate, git, filesystems, remote files ( Profile Dependencies).

Copy link

predominant commented Jul 16, 2020

We don't have to do every profile as a habitat package, but if we do, we can do reverse dep builds. If Profile A depends on B, A can be rebuilt when a new stable of B is made available. Stretch goal?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment