coulomb/whitehat-security
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
whitehat-security/docs/e3-cadence.md
tegwick 7a2373ae4c State the harness scope and calibrate E4 and R4 offline. 
SCOPE.md now matches the commands that run. E4 and R4 fail known-bad fixtures in process, and the cadence register schedules nothing.

Assistant: grok
Assistant-Session: 01a10450-dda4-7253-91a9-b8dccb2f0173
2026-10-04 08:54:40 +02:00

1.8 KiB
Raw Blame History

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. Nothing in this repository schedules that run. whitehat cadence is the register, and every family in it has scheduled: false.

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.