Answers the Tenancy Posture question that has been unowned since the framework was drafted - who verifies a consumer's tenant boundary. Two repos were asked and both correctly declined as fleet-scope work. The work needed a home. Independence is the load-bearing property, not a nicety. rapp-postgres wrote fifteen probes against its own isolation model and found four real defects, which is good work and still the author checking their own homework. The probes worth having are the ones the author would not think to write, because the assumption that produced the defect produces the blind spot. That argues against NetKingdom owning this even though it owns the security canon: a facility verifying conformance to a framework must not report to the repo that owns the framework, or self-grading just moves up a level. Proposed owner is the-custodian, consistent with policy and risk. Needs confirmation. Two things stated because overclaiming is the failure this estate keeps catching in itself. "Automated" has a ceiling - the highest-impact cross-tenant findings need someone who understands what the data means, since a response can be well-formed, 200, fast, and contain another tenant's rows; so automate the reproducible and flag the irreducible for dated review. And a passing suite proves the attacks we thought of did not work, not that the boundary holds. The gap between those sentences is where breaches live. WP-0001 gates everything behind rules of engagement, because an automated facility probing systems without written scope is indistinguishable from the threat it models. No standing privilege, no BYPASSRLS, no superuser - an attacker would not have them and a probe holding them proves nothing. No exfiltration of real tenant data even as proof; a count and a schema shape are proof enough. And no saturation probing outside a declared window, because with a six-consumer connection ceiling that is an outage for every co-resident. T04 exists because a probe that has only ever passed is not evidence. Every probe must be shown failing against a known-bad fixture before it is trusted passing - the same discipline rapp-postgres used when it verified its drift check by deliberately re-pinning to a bad digest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| workplans | ||
| INTENT.md | ||
| README.md | ||
whitehat-security
Automated white hat IT-security, pen-testing and isolation-probing.
The estate's adversarial evidence facility: it attacks our own systems, on a schedule, to find out whether the security properties they claim are actually true.
It exists because a repo testing its own boundary grades its own homework. The probes most worth having are the ones an author would not think to write.
-
Independent by construction. It does not take a declared posture as true, and it is not owned by the repo whose canon it verifies.
-
It finds; it does not fix. Findings route to
risk-nexus, which owns severity and disclosure. The repo that owns the defect owns the repair. -
A pass means the attacks we tried did not work — not that the boundary holds. Reports say so.
-
Intent:
INTENT.md -
Workplans:
workplans/