safe-runtime-testing
Run authorized, non-destructive security tests against Ouros local or QA services. Use for runtime verification of auth, authorization, API, business-logic or configuration hypotheses when the environ
SKILL.mdskills/safe-runtime-testing/SKILL.md
GitHubSafe Runtime Testing
Goal: obtain reproducible security evidence while leaving application state functionally unchanged except for preserved audit logs.
Read ../../references/ouros-security-model.md when Ouros ownership boundaries are involved.
Gate before every test
Proceed only when all are true:
- target is local or explicitly authorized QA;
- test identity is known;
- exact resources touched by the test are known;
- pre-existing business/user data will not be destructively modified;
- expected mutation is bounded;
- rollback/cleanup is defined;
- availability impact is negligible.
Otherwise mark the hypothesis blocked.
Isolation
Generate a run ID and track every object created by the test.
Prefer, in order: read-only requests, dedicated fixtures, database transaction + rollback, temporary resources with exact-ID cleanup, and reversible configuration with captured before-state.
Never identify cleanup targets by a broad name pattern alone.
Execution loop
- Capture relevant before-state.
- Perform the smallest probe that can answer the hypothesis.
- Capture status, response metadata, trace/request ID and affected object IDs.
- Avoid repeating a successful state-changing probe just for confidence.
- Restore captured state or delete only resources created by this run.
- Re-read relevant state to verify cleanup.
- Preserve normal application/audit logs.
Authorization test pattern
Use two dedicated principals with dedicated resources: principal A owns resource A; principal B owns resource B. Probe whether A can perform the specific operation on B's test resource. Never substitute real user resources.
Failure handling
If cleanup fails, stop further mutations, record exact residual resource IDs, do not broaden deletion criteria, and report cleanup failure separately.
If the app becomes unhealthy, stop the campaign. Do not attempt aggressive recovery unless explicitly authorized.
Result
Return: run_id, target, hypothesis, result (candidate|rejected|blocked), evidence, created_resources, cleanup (verified|incomplete|not-needed), and residual_state.
A runtime result is still a candidate until the finding verifier confirms it.