Security Review

SentryOfficialPublished by Sentry

Skill
Review and audit
Security
CC-BY-SA-4.0
Medium risk

From the author

Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.

— the description by Sentry

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The Security Review skill provides a structured approach to auditing code for security vulnerabilities. It emphasizes deep research into data flow and context to distinguish between theoretical risks and truly exploitable issues. By focusing on attacker-controlled inputs and framework-specific mitigations, it reduces false positives and ensures that reported findings are actionable and high-confidence.

What it does

Performs systematic security audits on provided code snippets or files.
Traces data flow to confirm if inputs are attacker-controlled or server-controlled.
Evaluates code against common vulnerability patterns like injection, XSS, and authentication flaws.
Filters out false positives by checking for framework-level protections and sanitization.
Categorizes findings by severity and confidence levels.
Provides a standardized reporting format for identified vulnerabilities.

When to use it

When you need to audit code for potential security vulnerabilities.
When performing an OWASP-based security review.
When you need to verify if a specific code pattern is exploitable.
When checking for common security issues like SQL injection, XSS, or insecure authentication.

Advantages

Reduces noise by filtering out theoretical issues and server-controlled configurations.
Ensures high-confidence reporting by requiring codebase research before flagging.
Provides clear, actionable remediation advice for identified vulnerabilities.
Standardizes the security review process across different codebases.

Usage examples

“Perform a security review on this file: [code snippet]”: The agent will analyze the code, trace the data flow of inputs, and provide a report of any high-confidence vulnerabilities found, or state that none were identified.
“Check this API endpoint for potential injection vulnerabilities.”: The agent will examine the endpoint's input handling and database queries to determine if user input is properly parameterized or sanitized.
“Audit this authentication logic for security issues.”: The agent will review the authentication implementation against best practices, such as password storage algorithms and brute-force protections.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/getsentry/security-review/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip security-review.zip -d .agents/skills

Documentation by Sentry

Security Review Skill

Identify exploitable security vulnerabilities in code. Report only HIGH CONFIDENCE findings—clear vulnerable patterns with attacker-controlled input.

Scope: Research vs. Reporting

CRITICAL DISTINCTION:

Report on: Only the specific file, diff, or code provided by the user
Research: The ENTIRE codebase to build confidence before reporting

Before flagging any issue, you MUST research the codebase to understand:

Where does this input actually come from? (Trace data flow)
Is there validation/sanitization elsewhere?
How is this configured? (Check settings, config files, middleware)
What framework protections exist?

Do NOT report issues based solely on pattern matching. Investigate first, then report only what you're confident is exploitable.

Confidence Levels

Level	Criteria	Action
HIGH	Vulnerable pattern + attacker-controlled input confirmed	Report with severity
MEDIUM	Vulnerable pattern, input source unclear	Note as "Needs verification"
LOW	Theoretical, best practice, defense-in-depth	Do not report

Do Not Flag

General Rules

Test files (unless explicitly reviewing test security)
Dead code, commented code, documentation strings
Patterns using constants or server-controlled configuration
Code paths that require prior authentication to reach (note the auth requirement instead)

Server-Controlled Values (NOT Attacker-Controlled)

These are configured by operators, not controlled by attackers:

Source	Example	Why It's Safe
Django settings	`settings.API_URL`, `settings.ALLOWED_HOSTS`	Set via config/env at deployment
Environment variables	`os.environ.get('DATABASE_URL')`	Deployment configuration
Config files	`config.yaml`, `app.config['KEY']`	Server-side files
Framework constants	`django.conf.settings.*`	Not user-modifiable
Hardcoded values	`BASE_URL = "https://api.internal"`	Compile-time constants

SSRF Example - NOT a vulnerability:

# SAFE: URL comes from Django settings (server-controlled)
response = requests.get(f"{settings.SEER_AUTOFIX_URL}{path}")

SSRF Example - IS a vulnerability:

# VULNERABLE: URL comes from request (attacker-controlled)
response = requests.get(request.GET.get('url'))

Framework-Mitigated Patterns

Check language guides before flagging. Common false positives:

Pattern	Why It's Usually Safe
Django `{{ variable }}`	Auto-escaped by default
React `{variable}`	Auto-escaped by default
Vue `{{ variable }}`	Auto-escaped by default
`User.objects.filter(id=input)`	ORM parameterizes queries
`cursor.execute("...%s", (input,))`	Parameterized query
`innerHTML = "<b>Loading...</b>"`	Constant string, no user input

Only flag these when:

Django: {{ var|safe }}, {% autoescape off %}, mark_safe(user_input)
React: dangerouslySetInnerHTML={{__html: userInput}}
Vue: v-html="userInput"
ORM: .raw(), .extra(), RawSQL() with string interpolation

Review Process

1. Detect Context

What type of code am I reviewing?

Code Type	Load These References
API endpoints, routes	`authorization.md`, `authentication.md`, `injection.md`
Django/DRF views, permission classes, object-level access	Use the `django-access-review` skill if available for access control; otherwise `authorization.md`
Frontend, templates	`xss.md`, `csrf.md`, `modern-threats.md` (DOM clobbering, prototype pollution)
File handling, uploads	`file-security.md`
Crypto, secrets, tokens	`cryptography.md`, `data-protection.md`
Data serialization	`deserialization.md`
External requests	`ssrf.md`
Business workflows	`business-logic.md`
GraphQL, REST design	`api-security.md`
Config, headers, CORS	`misconfiguration.md`
CI/CD, dependencies	`supply-chain.md`
Error handling	`error-handling.md`
Audit, logging	`logging.md`
Object merging/cloning, `__proto__`, DOM `id`/`name` lookups, WebSocket handlers, LLM prompt construction	`modern-threats.md`

2. Load Language Guide

Based on file extension or imports:

Indicators	Guide
`.py`, `django`, `flask`, `fastapi`	`languages/python.md`
`.js`, `.ts`, `express`, `react`, `vue`, `next`	`languages/javascript.md`

For other languages there is no dedicated guide; rely on the references/ files and verify framework protections directly in the codebase.

3. Load Infrastructure Guide (if applicable)

File Type	Guide
`Dockerfile`, `.dockerignore`	`infrastructure/docker.md`
GitHub Actions workflows	Use the `gha-security-review` skill if available; otherwise `references/supply-chain.md`
Other CI/CD pipelines, lockfiles, package manifests	`references/supply-chain.md`

4. Research Before Flagging

For each potential issue, research the codebase to build confidence:

Where does this value actually come from? Trace the data flow.
Is it configured at deployment (settings, env vars) or from user input?
Is there validation, sanitization, or allowlisting elsewhere?
What framework protections apply?

Only report issues where you have HIGH confidence after understanding the broader context.

5. Verify Exploitability

For each potential finding, confirm:

Is the input attacker-controlled?

Attacker-Controlled (Investigate)	Server-Controlled (Usually Safe)
`request.GET`, `request.POST`, `request.args`	`settings.X`, `app.config['X']`
`request.json`, `request.data`, `request.body`	`os.environ.get('X')`
`request.headers` (most headers)	Hardcoded constants
`request.cookies` (unsigned)	Internal service URLs from config
URL path segments: `/users/<id>/`	Database content from admin/system
File uploads (content and names)	Signed session data
Database content from other users	Framework settings
WebSocket messages

Does the framework mitigate this?

Check language guide for auto-escaping, parameterization
Check for middleware/decorators that sanitize

Is there validation upstream?

Input validation before this code
Sanitization libraries (DOMPurify, bleach, etc.)

6. Report HIGH Confidence Only

Skip theoretical issues. Report only what you've confirmed is exploitable after research.

Severity Classification

Severity	Impact	Examples
Critical	Direct exploit, severe impact, no auth required	RCE, SQL injection to data, auth bypass, hardcoded secrets
High	Exploitable with conditions, significant impact	Stored XSS, SSRF to metadata, IDOR to sensitive data
Medium	Specific conditions required, moderate impact	Reflected XSS, CSRF on state-changing actions, path traversal
Low	Defense-in-depth, minimal direct impact	Missing headers, verbose errors, weak algorithms in non-critical context

Quick Patterns Reference

Always Flag (Critical)

eval(user_input)           # Any language
exec(user_input)           # Any language
pickle.loads(user_data)    # Python
yaml.load(user_data)       # Python (not safe_load)
unserialize($user_data)    # PHP
deserialize(user_data)     # Java ObjectInputStream
shell=True + user_input    # Python subprocess
child_process.exec(user)   # Node.js

Always Flag (High)

innerHTML = userInput              # DOM XSS
dangerouslySetInnerHTML={user}     # React XSS
v-html="userInput"                 # Vue XSS
f"SELECT * FROM x WHERE {user}"    # SQL injection
`SELECT * FROM x WHERE ${user}`    # SQL injection
os.system(f"cmd {user_input}")     # Command injection

Always Flag (Secrets)

password = "hardcoded"
api_key = "sk-..."
AWS_SECRET_ACCESS_KEY = "..."
private_key = "-----BEGIN"

Check Context First (MUST Investigate Before Flagging)

# SSRF - ONLY if URL is from user input, NOT from settings/config
requests.get(request.GET['url'])     # FLAG: User-controlled URL
requests.get(settings.API_URL)       # SAFE: Server-controlled config
requests.get(f"{settings.BASE}/{x}") # CHECK: Is 'x' user input?

# Path traversal - ONLY if path is from user input
open(request.GET['file'])            # FLAG: User-controlled path
open(settings.LOG_PATH)              # SAFE: Server-controlled config
open(f"{BASE_DIR}/{filename}")       # CHECK: Is 'filename' user input?

# Open redirect - ONLY if URL is from user input
redirect(request.GET['next'])        # FLAG: User-controlled redirect
redirect(settings.LOGIN_URL)         # SAFE: Server-controlled config

# Weak crypto - ONLY if used for security purposes
hashlib.md5(file_content)            # SAFE: File checksums, caching
hashlib.md5(password)                # FLAG: Password hashing
random.random()                      # SAFE: Non-security uses (UI, sampling)
random.random() for token            # FLAG: Security tokens need secrets module

Output Format

## Security Review: [File/Component Name]

### Summary
- **Findings**: X (Y Critical, Z High, ...)
- **Risk Level**: Critical/High/Medium/Low
- **Confidence**: High/Mixed

### Findings

#### [VULN-001] [Vulnerability Type] (Severity)
- **Location**: `file.py:123`
- **Confidence**: High
- **Issue**: [What the vulnerability is]
- **Impact**: [What an attacker could do]
- **Evidence**:
  ```python
  [Vulnerable code snippet]

Fix: [How to remediate]

Needs Verification

[VERIFY-001] [Potential Issue]

Location: file.py:456
Question: [What needs to be verified]


If no vulnerabilities found, state: "No high-confidence vulnerabilities identified."

---

## Reference Files

### Core Vulnerabilities (`references/`)
| File | Covers |
|------|--------|
| `injection.md` | SQL, NoSQL, OS command, LDAP, template injection |
| `xss.md` | Reflected, stored, DOM-based XSS |
| `authorization.md` | Authorization, IDOR, privilege escalation |
| `authentication.md` | Sessions, credentials, password storage |
| `cryptography.md` | Algorithms, key management, randomness |
| `deserialization.md` | Pickle, YAML, Java, PHP deserialization |
| `file-security.md` | Path traversal, uploads, XXE |
| `ssrf.md` | Server-side request forgery |
| `csrf.md` | Cross-site request forgery |
| `data-protection.md` | Secrets exposure, PII, logging |
| `api-security.md` | REST, GraphQL, mass assignment |
| `business-logic.md` | Race conditions, workflow bypass |
| `modern-threats.md` | Prototype pollution, LLM injection, WebSocket |
| `misconfiguration.md` | Headers, CORS, debug mode, defaults |
| `error-handling.md` | Fail-open, information disclosure |
| `supply-chain.md` | Dependencies, build security |
| `logging.md` | Audit failures, log injection |

### Language Guides (`languages/`)
- `python.md` - Django, Flask, FastAPI patterns
- `javascript.md` - Node, Express, React, Vue, Next.js

### Infrastructure (`infrastructure/`)
- `docker.md` - Container security

Files

SPEC.md

Security Review Specification

Intent

The security-review skill finds exploitable security vulnerabilities in application code and reports only high-confidence findings. Its main job is to turn a file, diff, or component into a short list of issues where a vulnerable pattern is confirmed to receive attacker-controlled input, each with a location, impact, evidence, and fix.

The skill is deliberately conservative. It asks the agent to research the whole codebase (data flow, configuration, framework protections, upstream validation) before flagging anything, and to drop theoretical or best-practice findings rather than pad the report. A short, accurate report is the success condition; a long list of pattern-matched suspects is a failure.

Scope

In scope:

Reviewing a specific file, diff, pull request, or component the user names, with codebase-wide research to confirm or dismiss each candidate finding.
OWASP-style vulnerability classes: injection, XSS, authentication, authorization, cryptography, deserialization, file handling, SSRF, CSRF, data protection, API design, business logic, misconfiguration, error handling, supply chain, logging, and modern threats (prototype pollution, DOM clobbering, WebSocket security, LLM prompt injection).
Python (Django, Flask, FastAPI) and JavaScript/TypeScript (Node, Express, React, Vue, Next.js) framework-specific guidance.
Dockerfile review.
Severity classification and confidence-tagged reporting in the fixed output format in SKILL.md.

Out of scope:

GitHub Actions workflow exploitation; that belongs to the gha-security-review skill.
In-depth Django access-control review of permission classes and endpoint scopes; SKILL.md routes that to the django-access-review skill when it is available and falls back to references/authorization.md when it is not.
Kubernetes, Terraform, and cloud IAM configuration review. No bundled guides exist; do not reference them from SKILL.md until they are written.
Dedicated Go, Rust, Java, or other language guides. The agent falls back to the language-agnostic references/ files.
Reporting low-confidence, defense-in-depth, or style-level findings.
Running scanners, fuzzers, or dynamic testing tools.

Users And Trigger Context

Primary users: engineers and coding agents asked to look for security problems in application code.
Common user requests: "security review this", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", "is this injectable / XSS-able / SSRF-able".
Should not trigger for: general code review, performance review, GitHub Actions workflow review, Django permission audits, or requests to write exploits against systems the user does not own.

Runtime Contract

Required first actions: identify the exact scope being reported on, detect the code type and language, and load only the matching references/, languages/, and infrastructure/ files from the routing tables in SKILL.md.
Required research: for each candidate finding, trace where the input comes from, check for upstream validation or sanitization, and check framework and configuration protections before deciding confidence.
Required outputs: the ## Security Review: report format from SKILL.md, with [VULN-nnn] entries for HIGH-confidence findings and [VERIFY-nnn] entries for MEDIUM-confidence ones, or the sentence "No high-confidence vulnerabilities identified."
Non-negotiable constraints: report only on the user-provided scope; never flag server-controlled values (settings, environment variables, config files, constants) as attacker-controlled; never report LOW-confidence findings; never flag test files, dead code, or framework-auto-escaped output without the specific unsafe pattern.
Expected bundled files loaded at runtime: SKILL.md always; a subset of references/*.md, languages/*.md, and infrastructure/*.md chosen by the routing tables.

Source And Evidence Model

Authoritative sources:

OWASP Cheat Sheet Series (CC BY-SA 4.0), from which the references/ material is derived; see LICENSE.
OWASP Top 10 and OWASP API Security Top 10 for category and severity framing.
Framework security documentation for Django, Flask, FastAPI, Express, React, Vue, and Next.js.

Useful improvement sources:

positive examples: reviews that trace input to its source and either confirm exploitability or correctly dismiss a pattern because of configuration or framework mitigation.
negative examples: false positives on settings.* or environment-derived URLs, on ORM-parameterized queries, on auto-escaped template output, on MD5 used for checksums, and on test fixtures.
negative examples: missed findings where a vulnerable pattern was present but the agent did not load the relevant reference file.
commit logs/changelogs: upstream OWASP cheat sheet revisions that change recommended mitigations.
issue or PR feedback: reviewer pushback on noisy or theoretical findings.
validation results: quick_validate.py output and manual checks that every bundled file is reachable from a routing table.

Data that must not be stored:

secrets or credentials observed during a review
customer data or PII from the reviewed codebase
private repository URLs or identifiers not needed to reproduce an example

Reference Architecture

SKILL.md contains the scope rules, confidence model, do-not-flag lists, routing tables, review process, severity table, quick pattern reference, and output format.
references/ contains one file per vulnerability class with vulnerable and safe code pairs, detection grep patterns, and a testing checklist.
languages/ contains per-ecosystem framework guidance (python.md, javascript.md).
infrastructure/ contains infrastructure configuration guidance (docker.md only).
LICENSE records the OWASP attribution and CC BY-SA 4.0 terms for the derived material.
references/evidence/, scripts/, and assets/ contain no files currently.

Every file under references/, languages/, and infrastructure/ must appear in at least one routing table in SKILL.md (Detect Context, Load Language Guide, or Load Infrastructure Guide) and in the Reference Files index. Do not list a file in SKILL.md that does not exist in the skill directory.

Validation

Lightweight validation: run uv run skills/skill-writer/scripts/quick_validate.py skills/security-review from the repository root; then confirm by hand that the set of files on disk under references/, languages/, and infrastructure/ matches the set referenced in SKILL.md in both directions.
Deeper validation: run the skill against a small fixture set containing one confirmed SQL injection, one confirmed stored XSS, one SSRF false positive sourced from settings, one ORM-parameterized query, and one auto-escaped template; check that only the two true positives are reported as findings.
Holdout examples: a JavaScript object-merge endpoint that should route to modern-threats.md, a Dockerfile running as root, and a Go or Rust file that should still be reviewed using the generic references without the agent attempting to load a nonexistent language guide.
Acceptance gates: report uses the fixed output format; every finding has a confirmed attacker-controlled input and a concrete fix; no finding cites a server-controlled value as the input; no LOW-confidence items appear; the agent loaded at least one reference file matching the code type.

Known Limitations

Language coverage beyond Python and JavaScript relies on language-agnostic references, so framework-specific mitigations in Go, Rust, Java, PHP, and Ruby may be missed or over-flagged.
Infrastructure coverage is limited to Dockerfiles. Kubernetes, Terraform, and cloud IAM review will produce generic results until dedicated guides exist.
Confidence depends on the agent actually tracing data flow; on very large codebases the research step can be incomplete and findings may land in "Needs Verification" more often.
The reference material is a derivative of the OWASP cheat sheets at a point in time and does not track upstream revisions automatically.

Maintenance Notes

Update SKILL.md when a reference, language, or infrastructure file is added or removed, so the routing tables and Reference Files index stay in lockstep with the directory contents.
Update SPEC.md when the scope, confidence policy, output contract, or set of covered languages and infrastructure types changes.
When adding a new languages/ or infrastructure/ guide, add both a routing row and an index entry in the same change; when removing one, remove both.
Keep the OWASP attribution comment after the frontmatter in SKILL.md and keep LICENSE in the skill root when derived material is edited or extended.
Keep public inventories pointed at the canonical skills/security-review skill, not the .agents/skills mirror.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs an API key, Needs Python

Security

What our scanner noticed· Medium risk

References to credential files
Instructions that use the network
Encoded commands that are executed
Downloads piped into a shell

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Sentry

Publisher

Sentry (Official)

Source

getsentry/skills · skills/security-review · commit e94f222

Licence

Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)

ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Sentry or Sentry.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download security-review.zip