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:

```sh
PYTHONPATH=src python3 -m whitehat_security.cli e3-plan
PYTHONPATH=src python3 -m whitehat_security.cli e3-fixtures
```

`e3-fixtures` calibrates the seven expected outcomes in-process, including
keeping the SQL-compromise reset as `inconclusive`. It opens no database
connection and is not target assurance.
`evidence/offline-e3-calibration.json` is the fixture artifact. A live
database run is owned by `WHITEHAT-WP-0006` and still requires a runtime-safe
surface, named database, and window.

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.