2.5 KiB
ADDED Requirements
Requirement: Authorization precedes active testing
Active security testing (brute force, fuzzing) SHALL NOT begin until a written authorization recording scope, source IPs, time window and emergency contact exists, a tested backup/snapshot is taken, and dedicated test accounts are provisioned. Active tests SHALL run against a staging clone or within a maintenance window, and SHALL NOT target real user accounts.
Scenario: Test blocked without authorization
- WHEN an operator attempts an active test without the recorded authorization and snapshot
- THEN the runbook procedure halts at the pre-flight gate and the test does not run
Scenario: Test uses dedicated accounts on staging
- WHEN a brute-force test runs
- THEN it targets a dedicated test account on staging (or in a maintenance window), never a real user
Requirement: Pre-flight security checklist
The repo SHALL ship a pre-flight checklist (docs/SECURITY_AUDIT_CHECKLIST.md) covering the three
fronts — brute force, API/data access, inadvertent vectors — plus infrastructure. Each item SHALL
have an explicit pass/fail criterion.
Scenario: Checklist covers all fronts with criteria
- WHEN an operator opens the checklist
- THEN it contains markable items for each of the three fronts and infra, each with a defined pass/fail criterion
Requirement: Non-destructive audit scripts
The repo SHALL provide audit scripts under scripts/security/ (ACL probe, IDOR probe, brute-force
harness, CSRF PoC, web recon) that are non-destructive and parameterized with test-account
credentials rather than hard-coded production secrets.
Scenario: ACL probe reports access matrix
- WHEN the ACL probe runs with a portal test account
- THEN it reports, per model, whether read/write/create/unlink is allowed or denied, without modifying production data
Scenario: Scripts take credentials as parameters
- WHEN a script is invoked
- THEN target URL and credentials are supplied as parameters/env, with no secrets committed to the repo
Requirement: Findings register tracks resolution
Findings SHALL be recorded in docs/SECURITY_FINDINGS.md with severity, evidence and status, and
each SHALL be tracked until resolved and verified.
Scenario: Confirmed findings tracked to closure
- WHEN the audit completes
- THEN the register lists H1–H5 (and any new findings) with severity and a status of resolved/verified or an owner and plan