tegwick
7e83a66573
Register in-process E3 and capacity fixtures, keep live database and substrate targets pending, and ask ops-mason for namespace-only provision. No packets, no credentials, no cancelled engagement IDs. Assistant: grok Assistant-Session: 01a02670-3345-76f2-a014-70fde8e2a2bb
1.5 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.
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.