Cybersecurity Review
Perform structured security code review across 9 dimensions, adapting depth based on review mode.
Review Modes
Select the appropriate mode based on context:
| Mode |
Trigger |
Scope |
Depth |
| New Code |
Reviewing code just written or a new feature |
Changed files only |
Deep on all 9 dimensions |
| Existing Repo |
Auditing an established codebase |
Full repository scan |
Prioritize high-severity, sample for depth |
| Open Source Eval |
Evaluating a dependency or OSS project |
Full project + community signals |
Supply chain focus + all 9 dimensions |
| Pull Request |
Reviewing a PR for merge readiness |
Diff only + touched files |
Deep on changed code, contextual on surrounding code |
Review Workflow
Step 1: Determine scope and mode
Identify which review mode applies. For PR reviews, obtain the diff. For repo audits, identify primary languages and frameworks.
Step 2: Run through each applicable dimension
Load the relevant reference file for each dimension and assess the code:
Input Validation & Injection Prevention -- See references/injection-prevention.md
- SQL injection, XSS, command injection, path traversal, deserialization, SSTI, XXE
Authentication & Authorization -- See references/auth-and-access-control.md
- Broken auth, IDOR, privilege escalation, session management, JWT misuse
Secrets & Credential Management -- See references/secrets-management.md
- Hardcoded secrets, API keys in source, committed .env files, missing secret scanning
Dependency & Supply Chain Security -- See references/supply-chain-security.md
- Vulnerable dependencies, typosquatting, dependency confusion, lockfile integrity, CI/CD pipeline integrity, GitHub Actions SHA pinning
Cryptography & Data Protection -- See references/cryptography.md
- Weak algorithms, insecure random, hardcoded keys, missing TLS, poor password hashing
Secure Configuration & API Security -- See references/config-and-api-security.md
- Debug mode, permissive CORS, missing security headers, BOLA, mass assignment, rate limiting, SSRF kill-chain patterns
Error Handling, Logging & Resource Safety -- See references/error-logging-resources.md
- Stack trace exposure, sensitive data in logs, log injection, ReDoS, buffer overflows, TOCTOU, mishandling exceptional conditions
LLM & AI Application Security -- See references/llm-ai-security.md
- Prompt injection (direct and indirect/RAG), improper LLM output handling, excessive agency, system prompt leakage, AI supply chain
Infrastructure & API Protocol Security -- See references/infra-and-protocol-security.md
- GraphQL (introspection, depth/complexity, batching), Kubernetes/container misconfig, WebSocket security, OAuth 2.0 vulnerabilities, gRPC security
Step 3: Produce findings report
For each finding, report:
- Severity: Critical / High / Medium / Low / Informational
- Dimension: Which of the 7 categories
- Location: File path and line number(s)
- CWE: The relevant CWE identifier
- Description: What the vulnerability is and why it matters
- Recommendation: Specific fix with code example where possible
Step 4: Summarize
Provide a summary table of all findings by severity, plus an overall security posture assessment.
Severity Classification
| Severity |
Criteria |
| Critical |
Remotely exploitable, no auth required, leads to data breach or RCE |
| High |
Exploitable with low complexity, significant impact (privilege escalation, data leak) |
| Medium |
Exploitable with moderate complexity or requires some preconditions |
| Low |
Minor issue, defense-in-depth improvement, or requires significant preconditions |
| Informational |
Best practice recommendation, no direct exploitability |
Mode-Specific Guidance
New Code Review
Focus on all 9 dimensions with equal weight. Check that new code does not introduce patterns flagged in the reference files. Verify that new dependencies are pinned and scanned. For AI/LLM features, apply dimension 8. For GraphQL/K8s/WebSocket features, apply dimension 9.
Existing Repo Audit
Start with a high-level scan using grep patterns from each reference file. Prioritize Critical/High findings. Sample representative files for deeper review. Check for missing security controls (CSP headers, rate limiting, auth middleware). If the repo uses LLM APIs or ships Kubernetes manifests/Helm charts, include dimensions 8 and 9.
Open Source Evaluation
Begin with supply chain signals: maintenance activity, contributor count, security policy presence, OpenSSF Scorecard if available. Inspect GitHub Actions workflows for SHA pinning and pull_request_target usage. Then review code for all 9 dimensions. Flag any use of dangerous patterns (eval, pickle, shell=True) as higher risk since the code runs in consumer environments.
Pull Request Review
Focus on the diff. For each changed file, assess which dimensions are relevant based on the code's function. Flag new dangerous patterns. Verify that security-sensitive changes have tests. Check that secrets were not accidentally committed. For PRs touching CI/CD workflows, always check SHA pinning and pull_request_target (dimension 4).
1---2name: cybersecurity-review3description: Perform comprehensive cybersecurity code review across 9 security dimensions: injection prevention, authentication/authorization, secrets management, supply chain security (including CI/CD pipeline integrity), cryptography, secure configuration/API security (including SSRF), error handling/logging/resource safety, LLM/AI application security, and infrastructure/API protocol security (GraphQL, Kubernetes, WebSockets, OAuth 2.0, gRPC). Use when reviewing newly written code, auditing existing repositories, evaluating open source projects, or assessing pull requests for security vulnerabilities. Triggers include requests like "security review", "check for vulnerabilities", "audit this code", "cybersecurity review", "is this code secure", or "check this PR for security issues".4license: MIT5---67# Cybersecurity Review89Perform structured security code review across 9 dimensions, adapting depth based on review mode.1011## Review Modes1213Select the appropriate mode based on context:1415| Mode | Trigger | Scope | Depth |16|------|---------|-------|-------|17| **New Code** | Reviewing code just written or a new feature | Changed files only | Deep on all 9 dimensions |18| **Existing Repo** | Auditing an established codebase | Full repository scan | Prioritize high-severity, sample for depth |19| **Open Source Eval** | Evaluating a dependency or OSS project | Full project + community signals | Supply chain focus + all 9 dimensions |20| **Pull Request** | Reviewing a PR for merge readiness | Diff only + touched files | Deep on changed code, contextual on surrounding code |2122## Review Workflow2324### Step 1: Determine scope and mode2526Identify which review mode applies. For PR reviews, obtain the diff. For repo audits, identify primary languages and frameworks.2728### Step 2: Run through each applicable dimension2930Load the relevant reference file for each dimension and assess the code:31321. **Input Validation & Injection Prevention** -- See [references/injection-prevention.md](references/injection-prevention.md)33 - SQL injection, XSS, command injection, path traversal, deserialization, SSTI, XXE34352. **Authentication & Authorization** -- See [references/auth-and-access-control.md](references/auth-and-access-control.md)36 - Broken auth, IDOR, privilege escalation, session management, JWT misuse37383. **Secrets & Credential Management** -- See [references/secrets-management.md](references/secrets-management.md)39 - Hardcoded secrets, API keys in source, committed .env files, missing secret scanning40414. **Dependency & Supply Chain Security** -- See [references/supply-chain-security.md](references/supply-chain-security.md)42 - Vulnerable dependencies, typosquatting, dependency confusion, lockfile integrity, CI/CD pipeline integrity, GitHub Actions SHA pinning43445. **Cryptography & Data Protection** -- See [references/cryptography.md](references/cryptography.md)45 - Weak algorithms, insecure random, hardcoded keys, missing TLS, poor password hashing46476. **Secure Configuration & API Security** -- See [references/config-and-api-security.md](references/config-and-api-security.md)48 - Debug mode, permissive CORS, missing security headers, BOLA, mass assignment, rate limiting, SSRF kill-chain patterns49507. **Error Handling, Logging & Resource Safety** -- See [references/error-logging-resources.md](references/error-logging-resources.md)51 - Stack trace exposure, sensitive data in logs, log injection, ReDoS, buffer overflows, TOCTOU, mishandling exceptional conditions52538. **LLM & AI Application Security** -- See [references/llm-ai-security.md](references/llm-ai-security.md)54 - Prompt injection (direct and indirect/RAG), improper LLM output handling, excessive agency, system prompt leakage, AI supply chain55569. **Infrastructure & API Protocol Security** -- See [references/infra-and-protocol-security.md](references/infra-and-protocol-security.md)57 - GraphQL (introspection, depth/complexity, batching), Kubernetes/container misconfig, WebSocket security, OAuth 2.0 vulnerabilities, gRPC security5859### Step 3: Produce findings report6061For each finding, report:62- **Severity**: Critical / High / Medium / Low / Informational63- **Dimension**: Which of the 7 categories64- **Location**: File path and line number(s)65- **CWE**: The relevant CWE identifier66- **Description**: What the vulnerability is and why it matters67- **Recommendation**: Specific fix with code example where possible6869### Step 4: Summarize7071Provide a summary table of all findings by severity, plus an overall security posture assessment.7273## Severity Classification7475| Severity | Criteria |76|----------|----------|77| **Critical** | Remotely exploitable, no auth required, leads to data breach or RCE |78| **High** | Exploitable with low complexity, significant impact (privilege escalation, data leak) |79| **Medium** | Exploitable with moderate complexity or requires some preconditions |80| **Low** | Minor issue, defense-in-depth improvement, or requires significant preconditions |81| **Informational** | Best practice recommendation, no direct exploitability |8283## Mode-Specific Guidance8485### New Code Review86Focus on all 9 dimensions with equal weight. Check that new code does not introduce patterns flagged in the reference files. Verify that new dependencies are pinned and scanned. For AI/LLM features, apply dimension 8. For GraphQL/K8s/WebSocket features, apply dimension 9.8788### Existing Repo Audit89Start with a high-level scan using grep patterns from each reference file. Prioritize Critical/High findings. Sample representative files for deeper review. Check for missing security controls (CSP headers, rate limiting, auth middleware). If the repo uses LLM APIs or ships Kubernetes manifests/Helm charts, include dimensions 8 and 9.9091### Open Source Evaluation92Begin with supply chain signals: maintenance activity, contributor count, security policy presence, OpenSSF Scorecard if available. Inspect GitHub Actions workflows for SHA pinning and `pull_request_target` usage. Then review code for all 9 dimensions. Flag any use of dangerous patterns (eval, pickle, shell=True) as higher risk since the code runs in consumer environments.9394### Pull Request Review95Focus on the diff. For each changed file, assess which dimensions are relevant based on the code's function. Flag new dangerous patterns. Verify that security-sensitive changes have tests. Check that secrets were not accidentally committed. For PRs touching CI/CD workflows, always check SHA pinning and `pull_request_target` (dimension 4).
ericmjl