opencode-metis 0.1.0

package/opencode/skill/security-assessment/SKILL.md

@@ -0,0 +1,421 @@
+---
+name: security-assessment
+description: "Vulnerability review, OWASP patterns, secure coding practices, and threat modeling approaches for systematic security evaluation"
+license: MIT
+compatibility: opencode
+metadata:
+  category: testing
+  version: "1.0"
+---
+
+# Security Assessment
+
+Roleplay as a security assessment specialist performing systematic evaluation of code, architecture, and infrastructure for vulnerabilities.
+
+SecurityAssessment {
+  Activation {
+    Reviewing code changes for security vulnerabilities
+    Designing new features with security requirements
+    Performing threat analysis on system architecture
+    Validating security controls in infrastructure
+    Assessing third-party integrations and dependencies
+    Preparing for security audits or compliance reviews
+  }
+
+  Constraints {
+    1. Before any action, read and internalize:
+       - Project CLAUDE.md -- architecture, conventions, priorities
+       - CONSTITUTION.md at project root -- if present, constrains all work
+       - Existing security controls -- build on established patterns
+    2. Perform threat modeling before implementation -- security by design
+    3. Validate all user input on the server side, regardless of client validation
+    4. Apply defense in depth -- multiple security layers, never single points of protection
+    5. Separate internal error logging from user-facing error messages
+    6. Use parameterized queries -- never string concatenation for SQL
+    7. Assume breach -- design for detection and containment
+    8. Never commit secrets to source control
+    9. Never trust client-side state for authorization decisions
+    10. Never use deprecated cryptographic algorithms (MD5, SHA1, DES)
+    11. Never return raw internal errors to users
+  }
+
+  OutputSchema {
+    ```
+    SecurityFinding:
+      id: string              # e.g., "C1", "H2"
+      title: string           # Short finding title
+      severity: CRITICAL | HIGH | MEDIUM | LOW
+      category: "authentication" | "authorization" | "injection" | "disclosure" | "configuration" | "cryptography" | "dependency"
+      owasp: string           # OWASP Top 10 reference (e.g., "A01:2021")
+      location: string        # file:line or component
+      finding: string         # What vulnerability was found
+      attack_vector: string   # How it could be exploited
+      recommendation: string  # Specific remediation
+      diff?: string           # Before/after code fix
+    ```
+  }
+
+  SeverityMatrix {
+    | Severity | Match Condition |
+    |----------|----------------|
+    | CRITICAL | Auth bypass, injection, data exposure of credentials/PII |
+    | HIGH | Privilege escalation, SSRF, missing auth on sensitive endpoint |
+    | MEDIUM | Missing security headers, weak crypto, verbose errors |
+    | LOW | Minor config issues, informational findings |
+  }
+
+  ThreatModelingSTRIDE {
+    Spoofing_Authentication {
+      Threat: Attacker pretends to be another user or system.
+
+      Questions:
+      - How do we verify the identity of users and systems?
+      - Can authentication tokens be stolen or forged?
+      - Are there any authentication bypass paths?
+
+      Mitigations:
+      - Strong authentication mechanisms (MFA)
+      - Secure token generation and validation
+      - Session management with proper invalidation
+    }
+
+    Tampering_Integrity {
+      Threat: Attacker modifies data in transit or at rest.
+
+      Questions:
+      - Can data be modified between components?
+      - Are database records protected from unauthorized changes?
+      - Can configuration files be altered?
+
+      Mitigations:
+      - Input validation at all boundaries
+      - Cryptographic signatures for critical data
+      - Database integrity constraints and audit logs
+    }
+
+    Repudiation_NonRepudiation {
+      Threat: Attacker denies performing an action.
+
+      Questions:
+      - Can we prove who performed an action?
+      - Are audit logs tamper-resistant?
+      - Is there sufficient logging for forensics?
+
+      Mitigations:
+      - Comprehensive audit logging
+      - Secure, immutable log storage
+      - Digital signatures for critical operations
+    }
+
+    InformationDisclosure_Confidentiality {
+      Threat: Attacker gains access to sensitive information.
+
+      Questions:
+      - What sensitive data exists in this system?
+      - How is data protected at rest and in transit?
+      - Are error messages revealing internal details?
+
+      Mitigations:
+      - Encryption for sensitive data (TLS, AES)
+      - Proper access controls and authorization
+      - Sanitized error messages
+    }
+
+    DenialOfService_Availability {
+      Threat: Attacker makes the system unavailable.
+
+      Questions:
+      - What resources can be exhausted?
+      - Are there rate limits on expensive operations?
+      - How does the system handle malformed input?
+
+      Mitigations:
+      - Rate limiting and throttling
+      - Input validation and size limits
+      - Resource quotas and timeouts
+    }
+
+    ElevationOfPrivilege_Authorization {
+      Threat: Attacker gains higher privileges than intended.
+
+      Questions:
+      - Can users access resources beyond their role?
+      - Are privilege checks performed consistently?
+      - Can administrative functions be accessed by regular users?
+
+      Mitigations:
+      - Principle of least privilege
+      - Role-based access control (RBAC)
+      - Authorization checks at every layer
+    }
+  }
+
+  OWASPTop10ReviewPatterns {
+    A01_BrokenAccessControl {
+      ReviewPattern:
+      1. Identify all endpoints and their expected access levels
+      2. Trace authorization logic from request to resource
+      3. Test for horizontal privilege escalation (accessing other users' data)
+      4. Test for vertical privilege escalation (accessing admin functions)
+      5. Verify CORS configuration restricts origins appropriately
+
+      RedFlags:
+      - Authorization based on client-side state
+      - Direct object references without ownership verification
+      - Missing authorization checks on API endpoints
+    }
+
+    A02_CryptographicFailures {
+      ReviewPattern:
+      1. Map all sensitive data flows (credentials, PII, financial)
+      2. Verify encryption at rest and in transit
+      3. Check for hardcoded secrets in code or configuration
+      4. Review cryptographic algorithm choices
+      5. Verify key management practices
+
+      RedFlags:
+      - Sensitive data in logs or error messages
+      - Deprecated algorithms (MD5, SHA1, DES)
+      - Secrets in source control
+    }
+
+    A03_Injection {
+      ReviewPattern:
+      1. Identify all user input entry points
+      2. Trace input flow to database queries, OS commands, LDAP
+      3. Verify parameterized queries or proper escaping
+      4. Check for dynamic code execution (eval, exec)
+      5. Review XML parsing for XXE vulnerabilities
+
+      RedFlags:
+      - String concatenation in queries
+      - User input in system commands
+      - Disabled XML external entity protection
+    }
+
+    A04_InsecureDesign {
+      ReviewPattern:
+      1. Verify threat modeling was performed
+      2. Check for abuse case handling (rate limits, quantity limits)
+      3. Review business logic for security assumptions
+      4. Assess multi-tenancy isolation
+      5. Verify secure defaults
+
+      RedFlags:
+      - No rate limiting on authentication
+      - Trust assumptions without verification
+      - Security as an afterthought
+    }
+
+    A05_SecurityMisconfiguration {
+      ReviewPattern:
+      1. Review default configurations for security settings
+      2. Check for unnecessary features or services
+      3. Verify error handling does not expose details
+      4. Review security headers (CSP, HSTS, X-Frame-Options)
+      5. Check cloud resource permissions
+
+      RedFlags:
+      - Debug mode in production
+      - Default credentials unchanged
+      - Overly permissive cloud IAM policies
+    }
+
+    A06_VulnerableComponents {
+      ReviewPattern:
+      1. Inventory all dependencies and their versions
+      2. Check for known vulnerabilities (CVE databases)
+      3. Verify dependencies from trusted sources
+      4. Review for unused dependencies
+      5. Check for version pinning
+
+      RedFlags:
+      - Unpinned dependencies
+      - Known critical vulnerabilities
+      - Dependencies from unofficial sources
+    }
+
+    A07_AuthenticationFailures {
+      ReviewPattern:
+      1. Review password policy enforcement
+      2. Check session management implementation
+      3. Verify brute force protection
+      4. Review token generation and validation
+      5. Check credential storage mechanisms
+
+      RedFlags:
+      - Weak password requirements
+      - Sessions that do not invalidate on logout
+      - Predictable session tokens
+    }
+
+    A08_IntegrityFailures {
+      ReviewPattern:
+      1. Review CI/CD pipeline security
+      2. Check for unsigned code or dependencies
+      3. Review deserialization of untrusted data
+      4. Verify update mechanism security
+      5. Check for code review requirements
+
+      RedFlags:
+      - Deserialization without integrity checks
+      - Unsigned updates or dependencies
+      - No code review before deployment
+    }
+
+    A09_LoggingAndMonitoringFailures {
+      ReviewPattern:
+      1. Verify authentication events are logged
+      2. Check for authorization failure logging
+      3. Review log content for sensitive data
+      4. Verify log integrity protection
+      5. Check alerting configuration
+
+      RedFlags:
+      - Missing authentication failure logs
+      - Sensitive data in logs
+      - No alerting on suspicious patterns
+    }
+
+    A10_SSRF {
+      ReviewPattern:
+      1. Identify all server-side URL fetching
+      2. Verify URL validation against allowlist
+      3. Check for internal network blocking
+      4. Review URL scheme restrictions
+      5. Verify response handling
+
+      RedFlags:
+      - User-controlled URLs without validation
+      - Internal addresses not blocked
+      - Raw responses returned to users
+    }
+  }
+
+  SecureCodingPractices {
+    InputValidation {
+      Always validate on the server side, regardless of client validation:
+
+      ```
+      function validateInput(input) {
+        // Type validation
+        if (typeof input !== 'string') {
+          throw new ValidationError('Input must be a string');
+        }
+
+        // Length validation
+        if (input.length > MAX_LENGTH) {
+          throw new ValidationError('Input exceeds maximum length');
+        }
+
+        // Format validation (allowlist approach)
+        if (!ALLOWED_PATTERN.test(input)) {
+          throw new ValidationError('Input contains invalid characters');
+        }
+
+        return sanitize(input);
+      }
+      ```
+    }
+
+    OutputEncoding {
+      Context-appropriate encoding prevents injection:
+      - HTML context: Encode `<`, `>`, `&`, `"`, `'`
+      - JavaScript context: Use JSON.stringify or hex encoding
+      - URL context: Use encodeURIComponent
+      - SQL context: Use parameterized queries (never encode manually)
+    }
+
+    SecretsManagement {
+      Never commit secrets to source control:
+
+      ```
+      // Bad: Hardcoded secret
+      const apiKey = "sk-1234567890abcdef";
+
+      // Good: Environment variable
+      const apiKey = process.env.API_KEY;
+      if (!apiKey) {
+        throw new ConfigurationError('API_KEY not configured');
+      }
+      ```
+    }
+
+    ErrorHandlingForSecurity {
+      Separate internal logging from user-facing errors:
+
+      ```
+      try {
+        await processRequest(data);
+      } catch (error) {
+        // Log full details internally
+        logger.error('Request processing failed', {
+          error: error.message,
+          stack: error.stack,
+          userId: user.id,
+          requestId: request.id
+        });
+
+        // Return generic message to user
+        throw new UserError('Unable to process request');
+      }
+      ```
+    }
+  }
+
+  InfrastructureSecurityConsiderations {
+    NetworkSecurity {
+      - Segment networks to limit blast radius
+      - Use private subnets for internal services
+      - Implement network policies in Kubernetes
+      - Restrict egress traffic to known destinations
+    }
+
+    ContainerSecurity {
+      - Use minimal base images (distroless, Alpine)
+      - Run as non-root user
+      - Set read-only root filesystem where possible
+      - Scan images for vulnerabilities
+      - Limit container capabilities
+    }
+
+    SecretsInInfrastructure {
+      - Use secret management services (Vault, AWS Secrets Manager)
+      - Inject secrets as environment variables, not files
+      - Rotate secrets regularly
+      - Audit secret access
+    }
+
+    CloudIAM {
+      - Apply principle of least privilege
+      - Use service accounts with minimal permissions
+      - Audit IAM policies regularly
+      - Avoid using root/admin accounts for routine operations
+    }
+  }
+
+  CodeReviewSecurityFocusAreas {
+    Priority areas for security-focused code review:
+    1. Authentication and session management -- Token generation, validation, session lifecycle
+    2. Authorization checks -- Access control at all layers
+    3. Input handling -- All user input paths
+    4. Data exposure -- Logs, errors, API responses
+    5. Cryptography usage -- Algorithm selection, key management
+    6. Third-party integrations -- Data sharing, authentication
+    7. Error handling -- Information leakage, fail-secure behavior
+  }
+
+  BestPractices {
+    - Perform threat modeling before implementation
+    - Apply defense in depth (multiple security layers)
+    - Assume breach: design for detection and containment
+    - Automate security testing in CI/CD
+    - Keep dependencies updated and audited
+    - Document security decisions and accepted risks
+    - Train developers on secure coding practices
+  }
+}
+
+## References
+
+- [Security Review Checklist](checklists/security-review-checklist.md) - Comprehensive security review checklist

package/opencode/skill/security-assessment/checklists/security-review-checklist.md

@@ -0,0 +1,285 @@
+# Security Review Checklist
+
+Comprehensive checklist for security-focused code review, architecture assessment, and infrastructure validation. Use this checklist systematically during security assessments.
+
+## Threat Modeling
+
+### STRIDE Analysis
+
+- [ ] Spoofing threats identified and mitigated
+- [ ] Tampering threats identified and mitigated
+- [ ] Repudiation threats identified and mitigated
+- [ ] Information disclosure threats identified and mitigated
+- [ ] Denial of service threats identified and mitigated
+- [ ] Elevation of privilege threats identified and mitigated
+
+### Attack Surface
+
+- [ ] All entry points documented (APIs, UIs, file uploads, webhooks)
+- [ ] Trust boundaries identified between components
+- [ ] Data flows mapped with sensitivity classifications
+- [ ] Third-party integrations assessed for risk
+- [ ] Unused features and endpoints disabled or removed
+
+### Threat Actors
+
+- [ ] Relevant threat actors identified (external, internal, privileged)
+- [ ] Attacker capabilities and motivations considered
+- [ ] High-value targets identified and prioritized
+- [ ] Attack scenarios documented for critical paths
+
+## Authentication
+
+### Credential Handling
+
+- [ ] Passwords hashed with strong algorithm (bcrypt, argon2, scrypt)
+- [ ] Appropriate cost factor configured for hashing
+- [ ] Password requirements enforce length over complexity
+- [ ] No maximum password length restrictions below 64 characters
+- [ ] Passwords not logged or exposed in error messages
+
+### Session Management
+
+- [ ] Session tokens generated with cryptographic randomness
+- [ ] Session tokens have sufficient entropy (128+ bits)
+- [ ] Sessions invalidated on logout
+- [ ] Sessions invalidated on password change
+- [ ] Session timeout configured appropriately
+- [ ] Session tokens regenerated after authentication
+
+### Multi-Factor Authentication
+
+- [ ] MFA available for sensitive operations
+- [ ] MFA recovery options are secure
+- [ ] MFA bypass conditions documented and minimized
+- [ ] TOTP implementation uses standard algorithms
+
+### Brute Force Protection
+
+- [ ] Account lockout or progressive delays implemented
+- [ ] Rate limiting on authentication endpoints
+- [ ] Lockout notifications sent to account owner
+- [ ] CAPTCHA or proof-of-work for suspicious activity
+
+## Authorization
+
+### Access Control
+
+- [ ] Authorization checks performed on every request
+- [ ] Authorization enforced server-side, not client-side
+- [ ] Default deny: access requires explicit grant
+- [ ] Principle of least privilege applied to all roles
+- [ ] Separation of duties for sensitive operations
+
+### Resource Access
+
+- [ ] Users cannot access other users' resources by ID manipulation
+- [ ] Direct object references validated against ownership
+- [ ] Batch operations validate authorization for all items
+- [ ] File access restricted to authorized directories
+- [ ] API responses filtered to authorized data only
+
+### Administrative Functions
+
+- [ ] Administrative endpoints require elevated authentication
+- [ ] Administrative actions logged with user attribution
+- [ ] Privilege escalation paths audited and minimized
+- [ ] Role assignments require appropriate authorization
+
+## Input Validation
+
+### General Input Handling
+
+- [ ] All input validated server-side
+- [ ] Validation uses allowlist approach (not blocklist)
+- [ ] Input length limits enforced
+- [ ] Input type validation enforced
+- [ ] Validation errors do not reveal internal details
+
+### Injection Prevention
+
+- [ ] SQL queries use parameterized statements
+- [ ] NoSQL queries properly escaped or use ODM
+- [ ] OS commands avoided; if necessary, input validated against allowlist
+- [ ] LDAP queries properly escaped
+- [ ] XPath queries properly escaped
+- [ ] Template injection prevented
+
+### File Handling
+
+- [ ] File uploads validate type by content, not extension
+- [ ] File uploads have size limits
+- [ ] Uploaded files stored outside web root
+- [ ] Uploaded filenames sanitized
+- [ ] Path traversal prevented in file operations
+- [ ] File downloads validate user authorization
+
+### XML Processing
+
+- [ ] External entity processing disabled (XXE prevention)
+- [ ] DTD processing disabled if not required
+- [ ] XML parser configured with resource limits
+
+## Cryptography
+
+### Data Protection
+
+- [ ] Sensitive data encrypted at rest
+- [ ] TLS 1.2+ enforced for data in transit
+- [ ] Certificate validation not disabled
+- [ ] Strong cipher suites configured
+
+### Algorithm Selection
+
+- [ ] No deprecated algorithms (MD5, SHA1, DES, RC4)
+- [ ] Appropriate key sizes (AES-256, RSA-2048+)
+- [ ] Cryptographic library from reputable source
+- [ ] Random number generation uses secure source
+
+### Key Management
+
+- [ ] Keys stored in secure location (HSM, secret manager)
+- [ ] Keys not hardcoded in source code
+- [ ] Key rotation process defined
+- [ ] Key backup and recovery procedures in place
+
+## Error Handling and Logging
+
+### Error Messages
+
+- [ ] Error messages do not expose stack traces
+- [ ] Error messages do not reveal system architecture
+- [ ] Error messages do not expose sensitive data
+- [ ] Generic messages for authentication failures
+
+### Security Logging
+
+- [ ] Authentication events logged (success and failure)
+- [ ] Authorization failures logged
+- [ ] Input validation failures logged
+- [ ] Administrative actions logged
+- [ ] Security-relevant configuration changes logged
+
+### Log Protection
+
+- [ ] Logs do not contain passwords or tokens
+- [ ] Logs do not contain full credit card numbers
+- [ ] Logs do not contain other sensitive PII inappropriately
+- [ ] Log integrity protected (append-only, signed)
+- [ ] Log access restricted and audited
+
+### Alerting
+
+- [ ] Alerts configured for repeated authentication failures
+- [ ] Alerts configured for anomalous access patterns
+- [ ] Alerts configured for privilege escalation attempts
+- [ ] Alert fatigue considered (appropriate thresholds)
+
+## API Security
+
+### Endpoint Security
+
+- [ ] All non-public endpoints require authentication
+- [ ] CORS configured to allow only trusted origins
+- [ ] HTTP methods restricted appropriately
+- [ ] Sensitive operations use POST/PUT/DELETE, not GET
+- [ ] API versioning strategy does not expose deprecated endpoints
+
+### Rate Limiting
+
+- [ ] Rate limits configured per user/IP
+- [ ] Rate limits appropriate for endpoint cost
+- [ ] Rate limit responses include retry-after header
+- [ ] Rate limit bypass not possible through header manipulation
+
+### Data Exposure
+
+- [ ] API responses do not include unnecessary fields
+- [ ] Pagination prevents mass data extraction
+- [ ] Bulk endpoints have appropriate limits
+- [ ] Error responses do not expose internal details
+
+## Infrastructure Security
+
+### Network Configuration
+
+- [ ] Internal services not exposed to public internet
+- [ ] Network segmentation limits lateral movement
+- [ ] Firewall rules follow least privilege
+- [ ] Egress traffic restricted to known destinations
+
+### Container Security
+
+- [ ] Base images from trusted sources
+- [ ] Images scanned for vulnerabilities
+- [ ] Containers run as non-root
+- [ ] Container capabilities minimized
+- [ ] Read-only root filesystem where possible
+
+### Cloud Security
+
+- [ ] IAM follows principle of least privilege
+- [ ] Service accounts have minimal permissions
+- [ ] Cloud storage buckets not publicly accessible
+- [ ] Cloud audit logging enabled
+- [ ] Infrastructure changes require review
+
+### Secrets Management
+
+- [ ] Secrets stored in secret manager (not config files)
+- [ ] Secrets injected at runtime, not build time
+- [ ] Secret access audited
+- [ ] Secret rotation automated where possible
+
+## Dependency Management
+
+### Vulnerability Management
+
+- [ ] Dependencies tracked in manifest file
+- [ ] Dependency versions pinned
+- [ ] Known vulnerabilities checked regularly
+- [ ] Process for responding to critical vulnerabilities
+- [ ] Automated scanning in CI/CD pipeline
+
+### Supply Chain Security
+
+- [ ] Dependencies from official sources
+- [ ] Package integrity verified (checksums, signatures)
+- [ ] Typosquatting risk considered
+- [ ] Transitive dependencies reviewed
+
+## CI/CD Security
+
+### Pipeline Security
+
+- [ ] CI/CD credentials stored securely
+- [ ] Pipeline definitions reviewed for security
+- [ ] Build artifacts signed or checksummed
+- [ ] Deployment requires review/approval
+
+### Code Review
+
+- [ ] Security review required for sensitive changes
+- [ ] Automated security scanning (SAST) in pipeline
+- [ ] Dynamic security testing (DAST) for web applications
+- [ ] Secrets scanning prevents credential commits
+
+## Usage Notes
+
+1. Apply this checklist during security-focused code reviews
+2. Not all items apply to every review - use judgment based on context
+3. Document exceptions with security rationale
+4. Update this checklist as new threats emerge
+5. Combine with automated tools for comprehensive coverage
+6. Prioritize findings by risk (likelihood x impact)
+7. Track remediation and verify fixes
+
+## Risk Rating Guide
+
+When documenting findings, use this risk rating:
+
+- **Critical**: Immediate exploitation possible, severe impact
+- **High**: Likely exploitation, significant impact
+- **Medium**: Exploitation requires conditions, moderate impact
+- **Low**: Exploitation difficult, limited impact
+- **Informational**: Best practice deviation, no direct risk