security-review

Security Review

Purpose

Find the vulnerabilities in a codebase or a change, with enough specificity that each finding can be fixed and verified. A security review that produces a list of theoretical concerns is not a security review.

When to Use

• Reviewing a pull request that touches authentication, authorization, or user input.
• Auditing a service before it becomes internet-facing.
• Responding to a penetration-test report.
• Periodic review of a security-sensitive codebase.

Capabilities

• OWASP Top 10 analysis against actual code.
• Authorization audit, including object-level checks.
• Secrets and credential discovery.
• Dependency and supply-chain risk assessment.
• Input-validation and output-encoding review.

Inputs

• The code, the diff, or the service.
• The threat model: who the attacker is and what they want.
• The deployment context: is it internet-facing, multi-tenant, handling payments?

Outputs

Findings ranked by severity, each with:

• The vulnerable code, by file and line.
• The exploit path — how it would actually be abused.
• The fix, concretely.
• How to verify the fix.

Workflow

1. Map the attack surface — Every route, every queue consumer, every file upload, every parameter. You cannot audit what you have not enumerated.
2. Follow untrusted data — From each entry point, trace where the data goes: into a query, a command, a template, a file path, a redirect. Each of those is a potential injection.
3. Audit every authorization check — For each endpoint taking an identifier: is there a check that the caller may access that specific object? This is where the real vulnerabilities are.
4. Look for the secrets — In the repository, the history, the config, the logs, and the error messages.
5. Assess the dependencies — Known vulnerabilities, unmaintained packages, and anything with install scripts.
6. Rank by exploitability, not by CVSS alone — An unauthenticated remote data leak outranks a theoretical timing attack, whatever the score says.