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
33 lines
1.5 KiB
Markdown
33 lines
1.5 KiB
Markdown
# 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.
|
|
|
|
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.
|
|
|