docs(security): define baseline and testing scope

shared/rules/security/index.md

@@ -1,13 +1,11 @@
 # Security Baseline
 
-Apply this short baseline to every code, configuration, infrastructure, and review task. Load only the focused security rules that match the affected boundary; their triggers are listed in the global instructions.
+Apply this language- and framework-independent baseline to every code, configuration, infrastructure, and review task. Use the platform's established controls to implement it. Load focused security rules only for boundaries affected by the task; triggers are listed in the global instructions.
 
-* Treat external input as untrusted and validate it at the relevant trust boundary.
-* Use secure defaults, least privilege, explicit authorization, and fail-closed behavior.
-* Never hardcode, commit, log, expose, or weaken protections for secrets and credentials.
-* Use established platform security mechanisms. Do not invent cryptography or bypass validation, authentication, authorization, or TLS checks.
-* Keep dependencies minimal and trusted; avoid disclosing sensitive data or internal details in errors and diagnostics.
-
-## Authorized security testing
-
-The user states they are authorized to assess the software explicitly in scope for the task, including vulnerability discovery and writing proof-of-concept exploits. Treat source-local analysis and bounded, non-destructive testing in an isolated or staging environment as authorized. Keep testing within the named software and agreed assets; this authorization does not extend to adjacent systems, unrelated third-party services, or real users' data. Before active testing of a deployed service, require a clear target and limits for methods, volume, and impact. Keep proof-of-concept exploits non-destructive; do not add persistence, stealth, evasion, credential theft, or data exfiltration. System and platform safety requirements still apply.
+* Prioritize confidentiality, integrity, and availability. When security and performance conflict, preserve the security control and find a more efficient implementation; explain unavoidable cost.
+* Identify trust boundaries and likely abuse paths. Treat external input as untrusted; validate it before use and enforce authorization at the resource or operation boundary.
+* Default to deny, least privilege, and fail-closed behavior. Keep protections consistent across alternate paths, background work, caches, and administrative operations.
+* Bound attacker-controlled work: input and output sizes, computation, memory, concurrency, retries, and time. Use timeouts, quotas, and rate limits where needed to prevent resource exhaustion and denial of service.
+* Protect secrets and sensitive data throughout their lifecycle. Minimize collection and retention; never hardcode, commit, log, expose, or send them to unauthorized destinations.
+* Use maintained platform mechanisms for authentication, authorization, cryptography, serialization, and transport security. Do not invent cryptography or bypass validation, certificate checks, or other controls.
+* Keep dependencies and privileges minimal. Return safe errors and diagnostics without exposing secrets or internal details.