ericmjl/cybersecurity-review

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:

1. Input Validation & Injection Prevention -- See references/injection-prevention.md

   • SQL injection, XSS, command injection, path traversal, deserialization, SSTI, XXE

2. Authentication & Authorization -- See references/auth-and-access-control.md

   • Broken auth, IDOR, privilege escalation, session management, JWT misuse

3. Secrets & Credential Management -- See references/secrets-management.md

   • Hardcoded secrets, API keys in source, committed .env files, missing secret scanning

4. 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

5. Cryptography & Data Protection -- See references/cryptography.md

   • Weak algorithms, insecure random, hardcoded keys, missing TLS, poor password hashing

6. 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

7. 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

8. 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

9. 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).