Reporting & attestations

Evidence auditors accept.

Advanced12 min · lesson 10 of 12

The output of a compliance run is evidence, and reporting is how you make it usable and durable. Beyond the CLI view, the JSON reporter produces a complete, machine-readable record of every control, its result, impact, and the actual observed values — the raw material for dashboards, trend analysis, and audit packages. Compliance platforms (Chef Automate, MITRE Heimdall) ingest these to show posture over time across a fleet, turning point-in-time scans into a continuous compliance picture.

terminal

$ inspec exec baseline -t ssh://ops@web1 \
    --reporter json:evidence/web1-$(date +%F).json cli
# archive the JSON as audit evidence; feed it to Heimdall/Automate for trends
$ inspec exec baseline --reporter html:report.html   # human-facing report

Evidence auditors accept

For an audit, the value is that the control is the requirement and the run is the proof — a JSON report tied to a versioned profile, run against a named target at a known time, is objective evidence a control was met (or a waiver applied). Store reports as immutable, timestamped artifacts, keep them tied to the profile version that produced them, and you can answer “were these systems compliant on that date?” with data instead of assertions. That reproducibility is what auditors want.

Evidence is only as trustworthy as its provenance

A compliance report is evidence only if you can trust where it came from — which profile version, which target, when, and that it was not edited. Generate reports in the pipeline (not hand-run), store them as immutable timestamped artifacts alongside the profile version and target, and protect that store. A report you cannot trace to a specific run against a specific system is an assertion, not evidence.

CIS/DISA baselines & waiversInSpec in CI/CD & pipelines