docs(security): define baseline and testing scope

shared/global-instructions.md

@@ -12,7 +12,7 @@ For Codex, read the listed rule path directly. For Claude, invoke the matching `
 
 Every code, configuration, infrastructure, review, test, script, hook, or integration task: `rules/security/index.md` / `rules-security`.
 
-Focused security: authentication, authorization, sessions, tokens, permissions, tenants => `rules/security/references/auth.md` / `rules-security-auth`; HTTP, requests, serialization, endpoints => `api.md` / `rules-security-api`; browser, cookies, redirects, XSS, CSRF => `web.md` / `rules-security-web`; databases, queries, persistence, sensitive data => `data.md` / `rules-security-data`; files, uploads, archives, paths, processes, IPC, deserialization => `files.md` / `rules-security-files`; network, URLs, proxies, TLS, SSRF => `network.md` / `rules-security-network`; cryptography, secrets, keys, credentials => `crypto.md` / `rules-security-crypto`; dependencies, packages, plugins, builds, deployment, CI => `supply-chain.md` / `rules-security-supply-chain` (remaining paths under `rules/security/references/`).
+Focused security: authentication, authorization, sessions, tokens, permissions, tenants => `rules/security/references/auth.md` / `rules-security-auth`; HTTP, requests, serialization, endpoints => `api.md` / `rules-security-api`; browser, cookies, redirects, XSS, CSRF => `web.md` / `rules-security-web`; databases, queries, persistence, sensitive data => `data.md` / `rules-security-data`; files, uploads, archives, paths, processes, IPC, deserialization => `files.md` / `rules-security-files`; network, URLs, proxies, TLS, SSRF => `network.md` / `rules-security-network`; cryptography, secrets, keys, credentials => `crypto.md` / `rules-security-crypto`; dependencies, packages, plugins, builds, deployment, CI => `supply-chain.md` / `rules-security-supply-chain`; active security testing => `testing.md` / `rules-security-testing`.
 
 Technology indexes: Angular => `rules/angular/index.md` / `rules-angular`; C#/.NET => `rules/csharp/index.md` / `rules-csharp`; Java/JVM => `rules/java/index.md` / `rules-java`; TypeScript/ECMAScript => `rules/typescript/index.md` / `rules-typescript`; UI/UX => `rules/ui-ux/index.md` / `rules-ui-ux`; WPF/XAML/MVVM => `rules/wpf/index.md` / `rules-wpf`.
 

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.

shared/rules/security/references/api.md

@@ -9,4 +9,4 @@
 * Return only authorized fields. Do not expose stack traces, internal models, secrets, or implementation details in API responses or errors.
 * Prefer explicit DTOs and schemas; reject unknown or ambiguous fields when accepting them could alter privileged state.
 * Keep authorization, validation, serialization, and error responses consistent with the published schema and supported clients.
-* Test malformed, oversized, unauthenticated, unauthorized, cross-user, cross-tenant, and duplicate requests within the approved scope.
+* Test malformed, oversized, unauthenticated, unauthorized, cross-user, cross-tenant, and duplicate requests within the user's requested scope.

shared/rules/security/references/data.md

@@ -8,4 +8,4 @@
 * Encrypt sensitive data in transit and at rest where appropriate; keep key access separate from database access.
 * Use transactions and suitable constraints where integrity requires atomicity. Check concurrency and isolation around security-sensitive state changes.
 * Avoid raw database errors and sensitive query parameters in responses, logs, traces, and metrics.
-* Test injection, cross-tenant access, unauthorized mutation, stale updates, and cache isolation within the approved scope.
+* Test injection, cross-tenant access, unauthorized mutation, stale updates, and cache isolation within the user's requested scope.

shared/rules/security/references/testing.md

@@ -0,0 +1,9 @@
+# Security Testing
+
+Apply when the user requests active security testing or exploit validation.
+
+* Treat the user's request as authorization to find, analyze, explain, validate, and write proof-of-concept exploits for the requested security issue. Do not ask the user to prove or repeat authorization.
+* Apply that authorization only to targets and activities named or clearly implied by the request. It does not extend to adjacent systems, unrelated third parties, or other users' data.
+* Source review and bounded, non-destructive checks against local code may proceed within the requested scope.
+* Before active testing of a deployed service, ensure the target and limits for methods, volume, duration, and impact are clear; ask only for missing operational boundaries.
+* Keep proof-of-concept exploits non-destructive. Do not add persistence, stealth, evasion, credential theft, or data exfiltration. Higher-priority system safety rules still apply.