whitehat-security/docs/e3-cadence.md
tegwick 43327183d8 Finish WHITEHAT-WP-0001 and own live residuals in WP-0006
Close T05 and T06 on the same applicable-target rule as T03: E3 cadence
and in-process calibration, platform-pg not_applicable, P1/P2 evaluator
proven against known-good and known-bad samples. Persist offline capacity
calibration. Live E3, P1/P2, flex-auth E2, and a later audit-core run
move to WHITEHAT-WP-0006, which authorizes no packet.

Assistant: grok
Assistant-Session: 01a05e32-c776-72a3-86ec-c490e027aca9
2026-09-01 20:26:47 +02:00

1.7 KiB

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
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.