whitehat-security/docs/e3-cadence.md

E3 conformance cadence

The E3 detection interval is 24 hours, so the declared maximum exposure window is 24 hours plus run and reporting latency. A run is also required before deployment promotion following any schema migration, RLS policy change, role/grant change, security-definer function change, or posture-mechanism change. The event-triggered run does not reset the daily schedule.

This is a detection control, not prevention. A migration can introduce an unprotected table between runs; the interval states how long that condition can remain unnoticed under normal scheduling.

The executable plan is available with:

PYTHONPATH=src python3 -m whitehat_security.cli e3-plan

The run checks the conformance view, unset-GUC reads, wrong-tenant reads and writes, BYPASSRLS on the runtime identity, and unsafe SECURITY DEFINER paths. The SQL-compromise reset probe is recorded as inconclusive under E3: changing the GUC after gaining SQL execution demonstrates E3's documented limit and must not be mislabeled a failed E3-A control.

Every database run requires its own approved target/database/window. It uses one ordinary runtime connection, sets application_name to the engagement id, and never uses an owner, superuser or BYPASSRLS role for convenience.