Skill Being Reviewed
Skill name: segmentation
Skill path: skills/network/segmentation/
False Positive Analysis
Benign-looking segmentation evidence that can be over-credited:
kubernetes:
default_deny: true
allow_policies:
- app-to-db
calico:
global_network_policies:
- platform-deny-external
cilium:
deny_policies: enabled
validation:
sample_flow_test: passedWhy this is a false positive:
The review sees default-deny and named policies, but it does not prove the effective decision after all selectors, tiers, policy order, pass/default actions, deny precedence, namespace scope, CNI enforcement mode, and runtime labels are applied. A single sample flow can pass while another matching workload is allowed by an additive Kubernetes policy, shadowed by Calico tier behavior, or denied/allowed differently by Cilium deny precedence.
Coverage Gaps
Missed variant 1: additive Kubernetes NetworkPolicies reopen traffic
A namespace has a default-deny policy, but a later allow policy with a broad podSelector, namespaceSelector, or empty selector allows traffic that reviewers expected to remain denied.
Missed variant 2: Calico tier/pass behavior changes the effective decision
A high-priority tier contains a deny rule but also Pass or a default action that continues evaluation to a lower tier. Without recording tier order and default action, the report cannot prove the final segmentation decision.
Missed variant 3: Cilium deny precedence differs from generic allow-only assumptions
A reviewer treats all policies as additive allows, but Cilium deny policies override allow policies. The effective behavior depends on whether deny rules, CiliumClusterwideNetworkPolicy, and Kubernetes NetworkPolicy all select the same endpoint.
Edge Cases
- A policy may be correct in source but ineffective at runtime if labels drift, CNI policy enforcement is disabled, or the workload is outside the selected namespace/endpoint set.
- Some traffic is governed by multiple policy engines: cloud security groups, Kubernetes NetworkPolicy, Calico/Cilium policies, service mesh authorization, and host firewall rules.
- A test from one pod pair does not prove every identity, namespace, node, or cross-cluster path has the same decision.
Remediation Quality
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| Kubernetes NetworkPolicy manifest review |
Partial |
Shows policies, but reviewers must compute additive selection and runtime labels. |
| Calico tiered policy |
Partial |
Provides order and pass/default-action semantics; review must record the effective decision chain. |
| Cilium policy tooling |
Partial |
Can show effective policy, but review must verify deny precedence and endpoint selection. |
Overall Assessment
Strengths: Strong segmentation fundamentals for zones, conduits, default deny, Kubernetes NetworkPolicy, Calico examples, service mesh bypass warnings, and validation expectations.
Needs improvement: Add an effective-decision matrix so reviewers prove which policy engine made the final allow/deny decision for each critical flow instead of crediting policy presence alone.
Priority recommendations:
- Add an effective policy decision evidence gate after workload-level controls.
- Require selector/runtime-label resolution and policy-engine precedence evidence.
- Add output fields for expected decision, observed decision, deciding policy/rule/tier, bypass path, and Not Evaluable reason.
Sources Checked
Bounty Info
Skill Being Reviewed
Skill name:
segmentationSkill path:
skills/network/segmentation/False Positive Analysis
Benign-looking segmentation evidence that can be over-credited:
Why this is a false positive:
The review sees default-deny and named policies, but it does not prove the effective decision after all selectors, tiers, policy order, pass/default actions, deny precedence, namespace scope, CNI enforcement mode, and runtime labels are applied. A single sample flow can pass while another matching workload is allowed by an additive Kubernetes policy, shadowed by Calico tier behavior, or denied/allowed differently by Cilium deny precedence.
Coverage Gaps
Missed variant 1: additive Kubernetes NetworkPolicies reopen traffic
A namespace has a default-deny policy, but a later allow policy with a broad
podSelector,namespaceSelector, or empty selector allows traffic that reviewers expected to remain denied.Missed variant 2: Calico tier/pass behavior changes the effective decision
A high-priority tier contains a deny rule but also
Passor a default action that continues evaluation to a lower tier. Without recording tier order and default action, the report cannot prove the final segmentation decision.Missed variant 3: Cilium deny precedence differs from generic allow-only assumptions
A reviewer treats all policies as additive allows, but Cilium deny policies override allow policies. The effective behavior depends on whether deny rules, CiliumClusterwideNetworkPolicy, and Kubernetes NetworkPolicy all select the same endpoint.
Edge Cases
Remediation Quality
Comparison to Other Tools
Overall Assessment
Strengths: Strong segmentation fundamentals for zones, conduits, default deny, Kubernetes NetworkPolicy, Calico examples, service mesh bypass warnings, and validation expectations.
Needs improvement: Add an effective-decision matrix so reviewers prove which policy engine made the final allow/deny decision for each critical flow instead of crediting policy presence alone.
Priority recommendations:
Sources Checked
Bounty Info