blumeops/docs/how-to/operations/read-compliance-reports.md
Erich Blume ee51bcafb4 Rip out compensating-controls framework (#359)
## Summary

Removes the compensating-controls (CC) framework. Prowler and Kingfisher continue to run weekly and produce reports; the Prowler mutelist YAML files stay in place but no longer carry \`CC: <id>\` prefixes — each entry now just keeps a free-form \`Description\` of why it's muted.

The CC review cadence proved to be more process overhead than this single-operator homelab needed.

## What changed

**Deleted**
- \`compensating-controls.yaml\` — the CC registry
- \`mise-tasks/review-compensating-controls\` — the staleness-review task
- \`docs/how-to/operations/review-compensating-controls.md\`
- \`docs/how-to/operations/record-review-evidence.md\` (was aspirational)
- \`docs/explanation/compliance-mute-categories.md\` (proposed-future CC/NA/RA work)
- 5 orphan \`+review-cc-*\` / \`+compliance-mute-categories\` changelog fragments

**Modified**
- 6 mutelist YAML files: stripped \`CC: <id>.\` prefix from every \`Description\` / \`statement\` field, kept the free-form text
- \`mise-tasks/review-compliance-reports\`: removed CC mentions from docstrings, panel text, and the node-verification table title. Node-verification logic itself is unchanged.
- \`docs/reference/operations/security.md\`: removed the "Compensating controls" section
- \`docs/how-to/operations/read-compliance-reports.md\`: rewrote step 3 of "Acting on findings" to point at the mutelist YAML directly
- \`docs/changelog.d/prowler-iac-mutelist.infra.md\`: rewrote to drop the "two new compensating controls" framing

## What did not change

- All Prowler manifests (cronjobs, RBAC, PVs, kustomization) — scans still run on the same schedule
- The Kingfisher deployment
- The trivy-shim in the Prowler container — that's about Trivy ignorefile plumbing, independent of the CC concept
- The mutelist entries themselves — each \`Resources\` list is unchanged; only the prose of \`Description\` was edited
- \`CHANGELOG.md\` — historical releases are left as-is

## Test plan

- [ ] Wait for human review before deploying — once merged, re-point ArgoCD: \`argocd app set prowler --revision main && argocd app sync prowler\` (no manifest changes besides the ConfigMap, so impact is limited to muted-finding descriptions in next week's report)
- [ ] Confirm next weekly Prowler K8s CIS run (Sunday 3am) still completes and produces a report on sifaka
- [ ] Confirm next weekly Prowler IaC run still honors \`trivyignore.yaml\` (the trivy shim is untouched but the ignorefile content was rewritten)
- [ ] \`mise run review-compliance-reports\` — verify node-verification block still runs and prints the renamed table title

Reviewed-on: #359
2026-05-22 21:08:53 -07:00

3.4 KiB

title modified last-reviewed tags
Read Compliance Reports 2026-04-06 2026-04-06
how-to
security
compliance

Read Compliance Reports

How to access and interpret compliance scan reports from prowler and other security scanners.

Quick summary

mise run review-compliance-reports

This fetches the latest Prowler report from sifaka, parses it (respecting muted status), compares against the previous week, and shows only actionable unmuted failures. Use --show-muted to also see muted findings, or --full for complete detail.

Accessing reports

Reports are stored on sifaka at /volume1/reports/. Each scanner writes to its own subdirectory:

Scanner Path Schedule
prowler K8s CIS sifaka:/volume1/reports/prowler/ Weekly (Sunday 3am)
prowler Image sifaka:/volume1/reports/prowler-images/ Weekly (Saturday 3am)
prowler IaC sifaka:/volume1/reports/prowler-iac/ Weekly (Saturday 2am)

Copy reports to your local machine (remember scp -O for sifaka):

scp -O sifaka:/volume1/reports/prowler/prowler-output-In-Cluster-*.html /tmp/
open /tmp/prowler-output-In-Cluster-*.html

Report formats

HTML

Open in a browser. Self-contained, filterable by severity, status, and service. Best for human review — shows pass/fail per check with remediation guidance.

CSV

One row per finding. Columns include check ID, status, severity, resource, namespace, description, and remediation. Good for filtering in a spreadsheet or scripting.

JSON-OCSF

Open Cybersecurity Schema Framework format. Machine-parseable, suitable for SIEM ingestion or programmatic analysis.

Compliance CSV

In the compliance/ subdirectory. Findings mapped to specific framework requirement IDs (e.g., CIS 1.11 section numbers). Shows which controls pass or fail.

Interpreting results

Status values

  • PASS — the resource is configured securely per the check
  • FAIL — remediation is recommended
  • MANUAL — Prowler cannot determine the result automatically (e.g., kubelet file permissions when not running on the node)
  • MUTED — the finding was explicitly suppressed via a mutelist

Severity

Findings are categorized as critical, high, medium, or low. Focus on critical and high first.

Expected failures

Not all failures require action. Common expected failures in our minikube cluster:

  • Core/pod security (high): System pods (ArgoCD, external-secrets, tailscale-operator) legitimately need elevated privileges. These can be mutelisted.
  • Apiserver (medium): Audit logging, profiling, and some admission plugins are not configured in minikube defaults. Low risk for a homelab.
  • Kubelet (high): Anonymous auth or read-only port settings from minikube defaults.

Acting on findings

  1. Triage — review new failures, distinguish real issues from expected noise
  2. Remediate — fix what you can (pod security contexts, RBAC tightening)
  3. Mutelist — suppress expected/accepted failures by adding a Resource entry under the matching Check in argocd/manifests/prowler/mutelist/*.yaml with a free-form Description explaining why
  4. Track — compare reports over time to spot regressions