Repository navigation
fix: isolate framework-scoped exception results - #193
Conversation
Signed-off-by: Gaurav Chaudhary <chaudharygaurav2004@gmail.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
matthyx
left a comment
There was a problem hiding this comment.
Reviewed the framework-scoped exception flow end to end. The raw evaluation remains immutable, tuple correlation is preserved, aggregate and per-framework status/substatus semantics are covered (including action-required and JSON round trips), and the shared regex matcher is concurrency-safe. I found no blockers. Locally verified with go test ./..., go test -race ./..., go vet ./..., and git diff --check origin/main...HEAD.
Kubescape 4.0.16 ships opa-utils v0.0.315 (kubescape/opa-utils#193, "isolate framework-scoped exception results"). ResourceAssociatedRule status now filters attached exceptions through FilterExceptionsByFrameworks; with no framework filter, as for the --format-version v2 JSON report scan-security.sh gates on, only framework-agnostic posture policies match. Every policy here set frameworkName "AllControls", so all 69 exceptions still matched their resources (they appear under rules[].exception) but no failure became "w/exceptions", and the gate failed on C-0002, C-0007 and the rest. Scope each policy by controlID only. Kubescape 4.0.15 treats an empty frameworkName as a wildcard too, so this is backward compatible. Document the requirement in docs/security-scanners.md. Co-Authored-By: Claude <noreply@anthropic.com>
Summary
Verification
Related to #187
This PR covers the opa-utils result model. The Kubescape manual-control integration will follow separately after an opa-utils release.'