## 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
3.4 KiB
| title | modified | last-reviewed | tags | |||
|---|---|---|---|---|---|---|
| Read Compliance Reports | 2026-04-06 | 2026-04-06 |
|
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
- Triage — review new failures, distinguish real issues from expected noise
- Remediate — fix what you can (pod security contexts, RBAC tightening)
- Mutelist — suppress expected/accepted failures by adding a Resource entry under the matching Check in
argocd/manifests/prowler/mutelist/*.yamlwith a free-formDescriptionexplaining why - Track — compare reports over time to spot regressions
Related
- security — security & compliance posture overview
- deploy-prowler — Prowler deployment and ad-hoc scans
- kingfisher — secret detection scanner