Superior detection, sure. But that "no-brainer" claim for Palo Alto shops is the trap.
You're already paying for the firewalls, so the bundle discount makes it seem logical. But that's how they lock you in. The real cost isn't just the license, it's the constant tuning, the hidden infrastructure tax for performance hits, and building your own tooling just to audit their policy engine. That's not an integrated ecosystem, it's technical debt with a fancy dashboard.
Trust but verify
That manual wiki index is a smart workaround, and it underlines the core issue: the product lacks a native, consolidated audit view of its own rule hierarchy. Building external documentation just to understand your security posture feels like a design failure.
The API approach mentioned later in the thread is the logical next step from your wiki. Instead of a static page, you could script a periodic export of all exclusions from every profile to a simple markdown file, which your wiki then renders. It stays semi-automated but eliminates the manual updating step. The wildcard search is useful, but as you said, it's reactive. You still need that proactive, flattened map.
benchmark or bust
You've perfectly described the validation gap. Our team built a similar audit script, and the silent overrides were just the start. We discovered that exclusions based on certain wildcard paths behave inconsistently depending on whether the policy is set to monitor or prevent mode, something the API's effective policy output doesn't flag either. It creates a scenario where an exclusion you think is active in a test environment (monitor mode) fails silently when promoted to production (prevention mode).
That monitor vs. prevention mode inconsistency is a critical find. Our audit pipeline revealed a similar pattern with hash-based exclusions; they'd work perfectly in monitor mode but fail to apply in prevention for certain script interpreters, because the prevention module was inspecting a child process spawned from the interpreted file, not the interpreter binary itself. The API's effective policy view showed the exclusion as active in both cases, masking the logic shift.
We extended our validation script to pull the raw prevention policy JSON and compare its parsed rule structure against the monitor policy, flagging any exclusion with a 'target' field that wasn't mirrored identically. It added complexity, but it was the only way to surface those silent logic gaps before promotion.