Security Review

GitHubOfficialFirst committed by Mrigank005Distributed by GitHub

Skill
Review and audit
Security
MIT
Medium risk

From the author

AI-powered codebase security scanner that reasons about code like a security researcher — tracing data flows, understanding component interactions, and catching vulnerabilities that pattern-matching tools miss. Use this skill when asked to scan code for security vulnerabilities, find bugs, check for SQL injection, XSS, command injection, exposed API keys, hardcoded secrets, insecure dependencies, access control issues, or any request like "is my code secure?", "review for security issues", "audit this codebase", or "check for vulnerabilities". Covers injection flaws, authentication and access control bugs, secrets exposure, weak cryptography, insecure dependencies, and business logic issues across JavaScript, TypeScript, Python, Java, PHP, Go, Ruby, and Rust.

— the description by Mrigank005

AutoGineer summary

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

Security Review is an advanced auditing tool that mimics a human security researcher's approach to codebase analysis. Rather than relying on simple pattern matching, it performs holistic data flow analysis to trace user input to dangerous sinks, understands component interactions, and verifies findings to reduce false positives. It covers a wide range of security concerns including injection flaws, authentication and access control issues, insecure cryptography, and business logic vulnerabilities across multiple programming languages.

What it does

Performs deep data flow analysis to trace user input to dangerous sinks
Audits project dependencies for known CVEs
Scans for hardcoded secrets, API keys, and credentials
Identifies injection flaws, authentication bugs, and business logic issues
Provides severity ratings and concrete patch proposals for critical findings
Filters results through a self-verification pass to minimize false positives

When to use it

When you need to audit a codebase for security vulnerabilities
Before deploying code to production to check for exposed secrets
When investigating potential injection flaws like SQLi or XSS
To review authentication and authorization logic
When checking for insecure dependencies or outdated libraries

Advantages

Context-aware analysis that understands intent and component interactions
Reduces noise by self-verifying findings before reporting
Provides actionable, language-specific patch proposals
Covers a broad spectrum of vulnerabilities beyond simple syntax patterns
Supports multiple major programming languages and frameworks

Usage examples

“security-review src/auth/”: The agent scans only the authentication module, identifying potential BOLA or missing auth checks and providing patches for any high-severity findings.
“Is my code secure?”: The agent performs a full project audit, including dependency checks, a secrets scan, and a deep vulnerability analysis, outputting a structured security report.
“Check my repo for vulnerabilities”: The agent conducts a comprehensive security review of the entire codebase, grouping findings by category and providing a summary table with severity levels.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/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 Mrigank005

Security Review

An AI-powered security scanner that reasons about your codebase the way a human security researcher would — tracing data flows, understanding component interactions, and catching vulnerabilities that pattern-matching tools miss.

When to Use This Skill

Use this skill when the request involves:

Scanning a codebase or file for security vulnerabilities
Running a security review or vulnerability check
Checking for SQL injection, XSS, command injection, or other injection flaws
Finding exposed API keys, hardcoded secrets, or credentials in code
Auditing dependencies for known CVEs
Reviewing authentication, authorization, or access control logic
Detecting insecure cryptography or weak randomness
Performing a data flow analysis to trace user input to dangerous sinks
Any request phrasing like "is my code secure?", "scan this file", or "check my repo for vulnerabilities"
Running /security-review or /security-review <path>

How This Skill Works

Unlike traditional static analysis tools that match patterns, this skill:

Reads code like a security researcher — understanding context, intent, and data flow
Traces across files — following how user input moves through your application
Self-verifies findings — re-examines each result to filter false positives
Assigns severity ratings — CRITICAL / HIGH / MEDIUM / LOW / INFO
Proposes targeted patches — every finding includes a concrete fix
Requires human approval — nothing is auto-applied; you always review first

Execution Workflow

Follow these steps in order every time:

Step 1 — Scope Resolution

Determine what to scan:

If a path was provided (/security-review src/auth/), scan only that scope
If no path given, scan the entire project starting from the root
Identify the language(s) and framework(s) in use (check package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile, composer.json, etc.)
Read references/language-patterns.md to load language-specific vulnerability patterns

Step 2 — Dependency Audit

Before scanning source code, audit dependencies first (fast wins):

Node.js: Check package.json + package-lock.json for known vulnerable packages
Python: Check requirements.txt / pyproject.toml / Pipfile
Java: Check pom.xml / build.gradle
Ruby: Check Gemfile.lock
Rust: Check Cargo.toml
Go: Check go.sum
Flag packages with known CVEs, deprecated crypto libs, or suspiciously old pinned versions
Read references/vulnerable-packages.md for a curated watchlist

Step 3 — Secrets & Exposure Scan

Scan ALL files (including config, env, CI/CD, Dockerfiles, IaC) for:

Hardcoded API keys, tokens, passwords, private keys
.env files accidentally committed
Secrets in comments or debug logs
Cloud credentials (AWS, GCP, Azure, Stripe, Twilio, etc.)
Database connection strings with credentials embedded
Read references/secret-patterns.md for regex patterns and entropy heuristics to apply

Step 4 — Vulnerability Deep Scan

This is the core scan. Reason about the code — don't just pattern-match. Read references/vuln-categories.md for full details on each category.

Injection Flaws

SQL Injection: raw queries with string interpolation, ORM misuse, second-order SQLi
XSS: unescaped output, dangerouslySetInnerHTML, innerHTML, template injection
Command Injection: exec/spawn/system with user input
LDAP, XPath, Header, Log injection

Authentication & Access Control

Missing authentication on sensitive endpoints
Broken object-level authorization (BOLA/IDOR)
JWT weaknesses (alg:none, weak secrets, no expiry validation)
Session fixation, missing CSRF protection
Privilege escalation paths
Mass assignment / parameter pollution

Data Handling

Sensitive data in logs, error messages, or API responses
Missing encryption at rest or in transit
Insecure deserialization
Path traversal / directory traversal
XXE (XML External Entity) processing
SSRF (Server-Side Request Forgery)

Cryptography

Use of MD5, SHA1, DES for security purposes
Hardcoded IVs or salts
Weak random number generation (Math.random() for tokens)
Missing TLS certificate validation

Business Logic

Race conditions (TOCTOU)
Integer overflow in financial calculations
Missing rate limiting on sensitive endpoints
Predictable resource identifiers

Step 5 — Cross-File Data Flow Analysis

After the per-file scan, perform a holistic review:

Trace user-controlled input from entry points (HTTP params, headers, body, file uploads) all the way to sinks (DB queries, exec calls, HTML output, file writes)
Identify vulnerabilities that only appear when looking at multiple files together
Check for insecure trust boundaries between services or modules

Step 6 — Self-Verification Pass

For EACH finding:

Re-read the relevant code with fresh eyes
Ask: "Is this actually exploitable, or is there sanitization I missed?"
Check if a framework or middleware already handles this upstream
Downgrade or discard findings that aren't genuine vulnerabilities
Assign final severity: CRITICAL / HIGH / MEDIUM / LOW / INFO

Step 7 — Generate Security Report

Output the full report in the format defined in references/report-format.md.

Step 8 — Propose Patches

For every CRITICAL and HIGH finding, generate a concrete patch:

Show the vulnerable code (before)
Show the fixed code (after)
Explain what changed and why
Preserve the original code style, variable names, and structure
Add a comment explaining the fix inline

Explicitly state: "Review each patch before applying. Nothing has been changed yet."

Severity Guide

Severity	Meaning	Example
🔴 CRITICAL	Immediate exploitation risk, data breach likely	SQLi, RCE, auth bypass
🟠 HIGH	Serious vulnerability, exploit path exists	XSS, IDOR, hardcoded secrets
🟡 MEDIUM	Exploitable with conditions or chaining	CSRF, open redirect, weak crypto
🔵 LOW	Best practice violation, low direct risk	Verbose errors, missing headers
⚪ INFO	Observation worth noting, not a vulnerability	Outdated dependency (no CVE)

Output Rules

Always produce a findings summary table first (counts by severity)
Never auto-apply any patch — present patches for human review only
Always include a confidence rating per finding (High / Medium / Low)
Group findings by category, not by file
Be specific — include file path, line number, and the exact vulnerable code snippet
Explain the risk in plain English — what could an attacker do with this?
If the codebase is clean, say so clearly: "No vulnerabilities found" with what was scanned

Reference Files

For detailed detection guidance, load the following reference files as needed:

references/vuln-categories.md — Deep reference for every vulnerability category with detection signals, safe patterns, and escalation checkers
- Search patterns: SQL injection, XSS, command injection, SSRF, BOLA, IDOR, JWT, CSRF, secrets, cryptography, race condition, path traversal
references/secret-patterns.md — Regex patterns, entropy-based detection, and CI/CD secret risks
- Search patterns: API key, token, private key, connection string, entropy, .env, GitHub Actions, Docker, Terraform
references/language-patterns.md — Framework-specific vulnerability patterns for JavaScript, Python, Java, PHP, Go, Ruby, and Rust
- Search patterns: Express, React, Next.js, Django, Flask, FastAPI, Spring Boot, PHP, Go, Rails, Rust
references/vulnerable-packages.md — Curated CVE watchlist for npm, pip, Maven, Rubygems, Cargo, and Go modules
- Search patterns: lodash, axios, jsonwebtoken, Pillow, log4j, nokogiri, CVE
references/report-format.md — Structured output template for security reports with finding cards, dependency audit, secrets scan, and patch proposal formatting
- Search patterns: report, format, template, finding, patch, summary, confidence

Files

ATTRIBUTION.mdAdded by AutoGineer867 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md8.9 KiB
references/language-patterns.md5.2 KiB
references/report-format.md6.6 KiB
references/secret-patterns.md3.4 KiB
references/vuln-categories.md7.7 KiB
references/vulnerable-packages.md3.9 KiB

references/vuln-categories.md

Vulnerability Categories — Deep Reference

This file contains detailed detection guidance for every vulnerability category. Load this during Step 4 of the scan workflow.

1. Injection Flaws

SQL Injection

What to look for:

String concatenation or interpolation inside SQL queries
Raw .query(), .execute(), .raw() calls with variables
ORM whereRaw(), selectRaw(), orderByRaw() with user input
Second-order SQLi: data stored safely, then used unsafely later
Stored procedures called with unsanitized input

Detection signals (all languages):

"SELECT ... " + variable
`SELECT ... ${variable}`
f"SELECT ... {variable}"
"SELECT ... %s" % variable   # Only safe with proper driver parameterization
cursor.execute("... " + input)
db.raw(`... ${req.params.id}`)

Safe patterns (parameterized):

db.query('SELECT * FROM users WHERE id = ?', [userId])
User.findOne({ where: { id: userId } })  // ORM safe

Escalation checkers:

Is the query result ever used in another query? (second-order)
Is the table/column name user-controlled? (cannot be parameterized — must allowlist)

Cross-Site Scripting (XSS)

What to look for:

innerHTML, outerHTML, document.write() with user data
dangerouslySetInnerHTML in React
Template engines rendering unescaped: {{{ var }}} (Handlebars), != var (Pug)
jQuery .html(), .append() with user data
eval(), setTimeout(string), setInterval(string) with user data
DOM-based: location.hash, document.referrer, window.name written to DOM
Stored XSS: user input saved to DB, rendered without escaping later

Detection by framework:

React: Safe by default EXCEPT dangerouslySetInnerHTML
Angular: Safe by default EXCEPT bypassSecurityTrustHtml
Vue: Safe by default EXCEPT v-html
Vanilla JS: Every DOM write is suspect

Command Injection

What to look for (Node.js):

exec(userInput)
execSync(`ping ${host}`)
spawn('sh', ['-c', userInput])
child_process.exec('ls ' + dir)

What to look for (Python):

os.system(user_input)
subprocess.call(user_input, shell=True)
eval(user_input)

What to look for (PHP):

exec($input)
system($_GET['cmd'])
passthru($input)
`$input`  # backtick operator

Safe alternatives: Use array form of spawn/subprocess without shell=True; use allowlists for commands.

Server-Side Request Forgery (SSRF)

What to look for:

HTTP requests where the URL is user-controlled
Webhooks, URL preview, image fetch features
PDF generators that fetch external URLs
Redirects to user-supplied URLs

High-risk targets:

AWS metadata service: 169.254.169.254
Internal services: localhost, 127.0.0.1, 10.x.x.x, 192.168.x.x
Cloud metadata endpoints

Detection:

fetch(req.body.url)
axios.get(userSuppliedUrl)
http.get(params.webhook)

2. Authentication & Access Control

Broken Object Level Authorization (BOLA / IDOR)

What to look for:

Resource IDs taken directly from URL/params without ownership check
findById(req.params.id) without verifying userId === currentUser.id
Numeric sequential IDs (easily guessable)

Example vulnerable pattern:

// VULNERABLE: no ownership check
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findById(req.params.id);
  res.json(doc);
});

// SAFE: verify ownership
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findOne({ _id: req.params.id, owner: req.user.id });
  if (!doc) return res.status(403).json({ error: 'Forbidden' });
  res.json(doc);
});

JWT Vulnerabilities

What to look for:

alg: "none" accepted
Weak or hardcoded secrets: secret, password, 1234
No expiry (exp claim) validation
Algorithm confusion (RS256 → HS256 downgrade)
JWT stored in localStorage (XSS risk; prefer httpOnly cookie)

Detection:

jwt.verify(token, secret, { algorithms: ['HS256'] })  // Check algorithms array
jwt.decode(token)  // WARNING: decode does NOT verify signature

Missing Authentication / Authorization

What to look for:

Admin or sensitive endpoints missing auth middleware
Routes defined after app.use(authMiddleware) vs before it
Feature flags or debug endpoints left exposed in production
GraphQL resolvers missing auth checks at field level

CSRF

What to look for:

State-changing operations (POST/PUT/DELETE) without CSRF token
APIs relying only on cookies for auth without SameSite attribute
Missing SameSite=Strict or SameSite=Lax on session cookies

3. Secrets & Sensitive Data Exposure

In-Code Secrets

Look for patterns like:

API_KEY = "sk-..."
password = "hunter2"
SECRET = "abc123"
private_key = "-----BEGIN RSA PRIVATE KEY-----"
aws_secret_access_key = "wJalrXUtn..."

Entropy heuristic: strings > 20 chars with high character variety in assignment context are likely secrets even if the variable name doesn't say so.

In Logs / Error Messages

console.log('User password:', password)
logger.info({ user, token })   // token shouldn't be logged
res.status(500).json({ error: err.stack })  // stack traces expose internals

Sensitive Data in API Responses

Returning full user object including password_hash, ssn, credit_card
Including internal IDs or system paths in error responses

4. Cryptography

Weak Algorithms

Algorithm	Issue	Replace With
MD5	Broken for security	SHA-256 or bcrypt (passwords)
SHA-1	Collision attacks	SHA-256
DES / 3DES	Weak key size	AES-256-GCM
RC4	Broken	AES-GCM
ECB mode	No IV, patterns visible	GCM or CBC with random IV

Weak Randomness

// VULNERABLE
Math.random()                    // not cryptographically secure
Date.now()                       // predictable
Math.random().toString(36)       // weak token generation

// SAFE
crypto.randomBytes(32)           // Node.js
secrets.token_urlsafe(32)        // Python

Password Hashing

# VULNERABLE
hashlib.md5(password.encode()).hexdigest()
hashlib.sha256(password.encode()).hexdigest()

# SAFE
bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))
argon2.hash(password)

5. Insecure Dependencies

What to flag:

Packages with known CVEs in installed version range
Packages abandoned > 2 years with no security updates
Packages with extremely broad permissions for their stated purpose
Transitive dependencies pulling in known-bad packages
Pinned versions that are significantly behind current (possible unpatched vulns)

High-risk package watchlist: see `references/vulnerable-packages.md`

6. Business Logic

Race Conditions (TOCTOU)

// VULNERABLE: check then act without atomic lock
const balance = await getBalance(userId);
if (balance >= amount) {
  await deductBalance(userId, amount);  // race condition between check and deduct
}

// SAFE: use atomic DB transaction or optimistic locking
await db.transaction(async (trx) => {
  const user = await User.query(trx).forUpdate().findById(userId);
  if (user.balance < amount) throw new Error('Insufficient funds');
  await user.$query(trx).patch({ balance: user.balance - amount });
});

Missing Rate Limiting

Flag endpoints that:

Accept authentication credentials (login, 2FA)
Send emails or SMS
Perform expensive operations
Expose user enumeration (password reset, registration)

7. Path Traversal

# VULNERABLE
filename = request.args.get('file')
with open(f'/var/uploads/{filename}') as f:  # ../../../../etc/passwd

# SAFE
filename = os.path.basename(request.args.get('file'))
safe_path = os.path.join('/var/uploads', filename)
if not safe_path.startswith('/var/uploads/'):
    abort(400)

Requirements and compatibility

Written for: GitHub Copilot

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: Needs an API key

Security

What our scanner noticed· Medium risk

References to credential files

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

First committed by

Mrigank005

Publisher

GitHub (Official)

Distributed by

GitHub

Source

github/awesome-copilot · skills/security-review · commit 797337f

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

Contributors

Mrigank005

AutoGineer is not affiliated with or endorsed by Mrigank005 or GitHub.

Download ZIP

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

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Mrigank005

Security Review

When to Use This Skill

How This Skill Works

Execution Workflow

Step 1 — Scope Resolution

Step 2 — Dependency Audit

Step 3 — Secrets & Exposure Scan

Step 4 — Vulnerability Deep Scan

Step 5 — Cross-File Data Flow Analysis

Step 6 — Self-Verification Pass

Step 7 — Generate Security Report

Step 8 — Propose Patches

Severity Guide

Output Rules

Reference Files

Files

references/vuln-categories.md

Vulnerability Categories — Deep Reference

1. Injection Flaws

SQL Injection

Cross-Site Scripting (XSS)

Command Injection

Server-Side Request Forgery (SSRF)

2. Authentication & Access Control

Broken Object Level Authorization (BOLA / IDOR)

JWT Vulnerabilities

Missing Authentication / Authorization

CSRF

3. Secrets & Sensitive Data Exposure

In-Code Secrets

In Logs / Error Messages

Sensitive Data in API Responses

4. Cryptography

Weak Algorithms

Weak Randomness

Password Hashing

5. Insecure Dependencies

What to flag:

High-risk package watchlist: see references/vulnerable-packages.md

6. Business Logic

Race Conditions (TOCTOU)

Missing Rate Limiting

7. Path Traversal

Requirements and compatibility

Security

Attribution and licence

Related skills

Security Audit

Sast Configuration

Firmware Analyst

Policy Enforcer

Backend Development Security Auditor

Memory Forensics

Download ZIP

High-risk package watchlist: see `references/vulnerable-packages.md`