Running & reading results

Passed, failed, skipped.

Intermediate10 min · lesson 4 of 12

Running a profile yields a result per control: passed (the system meets it), failed (it does not, with the expected-vs-actual detail), or skipped (the control could not run — wrong platform, a resource that does not exist, or an explicit skip). Reading these well is the day-to-day skill: a failure tells you a real gap; a skip often tells you the control did not apply or something went wrong that you should investigate, not ignore.

terminal

$ inspec exec my-profile -t ssh://ops@web1 --reporter cli
  ✔  ssh-01: SSH must not permit root login
  ✘  pkg-01: Telnet must not be installed
     package telnet is expected not to be installed
  ↺  win-01: (skipped) only applies to Windows
Profile Summary: 12 successful, 1 failure, 3 skipped

Reporters and output

InSpec can emit results in many formats via --reporter: cli (human), json (machine, for pipelines and dashboards), junit (test systems), html, and the Heimdall/automate formats for compliance platforms. You can emit several at once (cli to the console, json to a file). Structured output is what lets InSpec feed CI gates, trend dashboards, and audit evidence stores — the same result, rendered for whoever needs it.

terminal

$ inspec exec my-profile -t ssh://ops@web1 \
    --reporter cli json:results.json     # human on screen, JSON to a file
$ echo $?
100     # non-zero exit on failures -> usable as a CI gate

A skip is not a pass — investigate silent skips

Skipped controls are easy to gloss over because they are not red, but a control that should have run and instead skipped (a mistyped resource, an unreachable path, a platform mismatch you did not expect) is a hole in your coverage masquerading as “not a failure.” Review skips, not just failures; a profile reporting mostly skips against a target is checking almost nothing, even though nothing failed.

The control languageResources & matchers