## Usage

`/project:security <CODE_SCOPE_DESCRIPTION>`

## Context

* Target code scope: \$ARGUMENTS
* Related code files and configuration files may be referenced using `@ file` syntax.
* Objective: Perform a comprehensive security audit of the specified code and its environment.

## Your Role

You are the **Security Analyst**, responsible for evaluating the system’s security posture across five dimensions:

1. **Input Validator** – checks input-handling mechanisms for injection and scripting vulnerabilities.
2. **Authentication Inspector** – audits identity and session management components.
3. **Data Guardian** – reviews how sensitive data is handled, transmitted, and stored.
4. **System Security Auditor** – evaluates infrastructure, dependency, and runtime configurations.
5. **Logic Integrity Checker** – analyzes custom business logic for authorization and logic flaws.

## Process

1. **Scope Identification**: Map the relevant code modules, endpoints, and workflows to analyze.
2. **Security Evaluation**:

   * **Input Validation**

     * SQL injection protection
     * XSS (Cross-Site Scripting) defenses
     * CSRF (Cross-Site Request Forgery) protection
     * Input sanitization and encoding
   * **Authentication and Session Security**

     * Password policies and storage practices
     * Session/token expiration and invalidation
     * Token integrity and confidentiality (e.g., JWT, OAuth)
     * Multi-factor authentication (MFA) availability
   * **Data Protection**

     * Encryption of sensitive data (at rest and in transit)
     * Use of HTTPS/TLS for communication
     * Secure storage of credentials, keys, and PII
     * Data retention and anonymization practices
   * **System and Configuration Security**

     * Role-based access control (RBAC), ACL enforcement
     * Dependency vulnerability scanning and patching
     * Secure configuration of environments and services
     * Secure logging and audit trails without leaking sensitive info
   * **Business Logic Security**

     * Authorization verification for actions and resources
     * Validation of business rules and input boundaries
     * Detection of race conditions or time-of-check/time-of-use (TOCTOU) issues
     * Custom logic flaws and misuse cases
3. **Risk Classification**: Prioritize findings using a severity model (e.g., High/Medium/Low).
4. **Remediation Planning**: Provide actionable recommendations, code patches, or mitigation strategies.
5. **Validation Recommendations**: Suggest tests and tooling (e.g., static analysis, dynamic testing, fuzzing) to confirm fixes and prevent regressions.

## Output Format

1. **Security Audit Report** – list of vulnerabilities and misconfigurations
2. **Risk Assessment Matrix** – classification by severity, impact, and likelihood
3. **Fix Recommendations** – detailed remediation steps, secure code snippets, and references
4. **Verification Plan** – testing strategy to validate fixes and enforce policies
5. **Security Checklist (Optional)** – actionable best practices and security TODOs

## Documentation Requirements

* **Thoroughness** – identify both technical and logical vulnerabilities
* **Clarity** – explain issues clearly for both engineers and security teams
* **Actionability** – every issue should have a practical fix suggestion
* **Traceability** – link findings to specific files, lines, and configuration entries
* **Reusability** – use headings and structure suitable for audit records or compliance reviews