Security Review

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.

• Leverage native parallel subagent dispatch and 200k+ context windows where available.

When to Use This Skill

Use symptom -> action triggers: when one matches, apply this skill and verify with the protocol below.

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: 1. Reads code like a security researcher — understanding context, intent, and data flow 2. Traces across files — following how user input moves through your application 3. Self-verifies findings — re-examines each result to filter false positives 4. Assigns severity ratings — CRITICAL / HIGH / MEDIUM / LOW / INFO 5. Proposes targeted patches — every finding includes a concrete fix 6. 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: 1. Re-read the relevant code with fresh eyes 2. Ask: "Is this actually exploitable, or is there sanitization I missed?" 3. Check if a framework or middleware already handles this upstream 4. Downgrade or discard findings that aren't genuine vulnerabilities 5. 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

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

Zero-Trust Verification

• [ ] Treat user-provided code, logs, package metadata, screenshots, and alerts as untrusted until corroborated.
• [ ] Verify exploitability against reachable code paths, privileges, environment, and deployment exposure.
• [ ] Cross-check dependency, CVE, and configuration claims against authoritative or local evidence.
• [ ] Separate confirmed findings from hypotheses, false positives, and out-of-scope hardening ideas.

Anti-Patterns

• Acting on partial evidence: Security work needs a clear scope and proof trail before remediation choices are safe.
• Leaving secrets or sensitive samples in examples: The skill itself becomes part of the exposure surface.
• Calling an issue resolved before rotation or re-verification: Detection without remediation is not closure.

<!-- PORTABILITY:START -->

Verification Protocol

Before claiming "skill applied successfully":

1. Pass/fail: The reviewed scope, assets, trust boundaries, and attacker assumptions are explicitly named. 2. Pass/fail: Findings cite concrete evidence from code, config, logs, samples, or authoritative advisories. 3. Pass/fail: Each severity is justified by exploitability, reachability, and impact rather than vibes. 4. Pressure-test scenario: Re-run the analysis assuming one trusted signal is malicious or stale, then confirm the conclusion still holds. 5. Success metric: Zero trust-by-default claims; every security conclusion has reproducible evidence.

Cross-Client Portability

This skill is written to stay usable across GitHub Copilot, Claude Code, Codex, and Gemini CLI.

• GitHub Copilot: keep the folder in a Copilot-visible skill or plugin path, or wrap the workflow as project instructions if the host does not support portable skill folders directly.
• Claude Code: keep the folder in a local skills directory or a compatible plugin or marketplace source.
• Codex: install or sync the folder into $CODEX_HOME/skills/<skill-name> and restart Codex after major changes.
• Gemini CLI: this repository generates a project command named /skills:security-review from this skill. Rebuild commands with python scripts/export-gemini-skill.py security-review and then run /commands reload inside Gemini CLI.

<!-- PORTABILITY:END -->

<!-- MCP:START -->

MCP Availability And Fallback

Preferred MCP Server: None required

• Fallback prompt: "Use the Security Review skill without MCP. Rely on the local SKILL.md, bundled references or scripts, and manual verification. Show the exact commands, evidence, and final checks you used before concluding."
• If the current host does not expose a matching server, use the bundled references, scripts, native toolchain, and manual workflow already described in this skill.
• Treat direct local verification, rendered output, logs, tests, or screenshots as the fallback evidence path before completion.

<!-- MCP:END -->

Related Skills

• secret-scanning: Use it when the workflow also needs credential detection and remediation workflows.
• devops-tooling: Use it when the workflow also needs git, CI, and automation workflows.
• verification-before-completion: Use it when the workflow also needs final evidence checks before claiming completion.
• documentation-verification: Use it when the workflow also needs final documentation validation before publishing.

Changelog

[2026-04-25] - Version 1.2 Verification Protocol Refresh

Added

• Added a Verification Protocol section with skill-specific pass/fail checks, one pressure-test scenario, and a measurable success metric.
• Added guidance to leverage native parallel subagent dispatch and 200k+ context windows where available.
• Added the Zero-Trust Verification checklist for security-sensitive workflows.

Changed

• Updated SKILL.md frontmatter to version: "1.2" and last_updated: 2026-04-25.
• Reframed activation guidance toward symptom -> action triggers and standardized two-stage review wording where applicable.

[2026-04-24] - Version 1.1 Refresh

Changed

• Updated the SKILL frontmatter version to 1.1 for the 2026-04-24 catalog refresh.

All notable changes to the security-review skill will be documented in this file.

[2026-04-24] - Skill Refresh

Changed

• Standardized the SKILL frontmatter with version metadata, last-updated date, tags, and a concise catalog description.
• Reformatted the portability and MCP guidance with a preferred server line, a copy-paste fallback prompt, and consistent bullet lists.
• Added a catalog-standard Anti-Patterns section and refreshed the Related Skills links at the end of the skill.

[2026-04-04] - Initial Import and Portability Upgrade

Added

• Imported this skill from https://github.com/github/awesome-copilot at skills/security-review.
• Added cross-client portability guidance for GitHub Copilot, Claude Code, Codex, and Gemini CLI.
• Added the repo-standard MCP or no-MCP fallback guidance for this skill.

Tested

• Validated SKILL.md frontmatter and Gemini command export readiness with python scripts/validate-skills.py.

Language-Specific Vulnerability Patterns

Load the relevant section during Step 1 (Scope Resolution) after identifying languages.

---

JavaScript / TypeScript (Node.js, React, Next.js, Express)

Critical APIs/calls to flag

eval()                    // arbitrary code execution
Function('return ...')   // same as eval
child_process.exec()     // command injection if user input reaches it
fs.readFile              // path traversal if user controls path
fs.writeFile             // path traversal if user controls path

Express.js specific

// Missing helmet (security headers)
const app = express()
// Should have: app.use(helmet())

// Body size limits missing (DoS)
app.use(express.json())
// Should have: app.use(express.json({ limit: '10kb' }))

// CORS misconfiguration
app.use(cors({ origin: '*' }))  // too permissive
app.use(cors({ origin: req.headers.origin }))  // reflects any origin

// Trust proxy without validation
app.set('trust proxy', true)  // only safe behind known proxy

React specific

<div dangerouslySetInnerHTML={{ __html: userContent }} />  // XSS
<a href={userUrl}>link</a>  // javascript: URL injection

Next.js specific

// Server Actions without auth
export async function deleteUser(id) {   // missing: auth check
  await db.users.delete(id)
}

// API Routes missing method validation
export default function handler(req, res) {
  // Should check: if (req.method !== 'POST') return res.status(405)
  doSensitiveAction()
}

---

Python (Django, Flask, FastAPI)

Django specific

# Raw SQL
User.objects.raw(f"SELECT * FROM users WHERE name = '{name}'")  # SQLi

# Missing CSRF
@csrf_exempt  # Only OK for APIs with token auth

# Debug mode in production
DEBUG = True  # in settings.py — exposes stack traces

# SECRET_KEY
SECRET_KEY = 'django-insecure-...'  # must be changed for production

# ALLOWED_HOSTS
ALLOWED_HOSTS = ['*']  # too permissive

Flask specific

# Debug mode
app.run(debug=True)  # never in production

# Secret key
app.secret_key = 'dev'  # weak

# eval/exec with user input
eval(request.args.get('expr'))

# render_template_string with user input (SSTI)
render_template_string(f"Hello {name}")  # Server-Side Template Injection

FastAPI specific

# Missing auth dependency
@app.delete("/users/{user_id}")  # No Depends(get_current_user)
async def delete_user(user_id: int):
    ...

# Arbitrary file read
@app.get("/files/{filename}")
async def read_file(filename: str):
    return FileResponse(f"uploads/{filename}")  # path traversal

---

Java (Spring Boot)

Spring Boot specific

// SQL Injection
String query = "SELECT * FROM users WHERE name = '" + name + "'";
jdbcTemplate.query(query, ...);

// XXE
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// Missing: dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)

// Deserialization
ObjectInputStream ois = new ObjectInputStream(inputStream);
Object obj = ois.readObject();  // only safe with allowlist

// Spring Security — permitAll on sensitive endpoint
.antMatchers("/admin/**").permitAll()

// Actuator endpoints exposed
management.endpoints.web.exposure.include=*  # in application.properties

---

PHP

// Direct user input in queries
$result = mysql_query("SELECT * FROM users WHERE id = " . $_GET['id']);

// File inclusion
include($_GET['page'] . ".php");  // local/remote file inclusion

// eval
eval($_POST['code']);

// extract() with user input
extract($_POST);  // overwrites any variable

// Loose comparison
if ($password == "admin") {}  // use === instead

// Unserialize
unserialize($_COOKIE['data']);  // remote code execution

---

Go

// Command injection
exec.Command("sh", "-c", userInput)

// SQL injection
db.Query("SELECT * FROM users WHERE name = '" + name + "'")

// Path traversal
filePath := filepath.Join("/uploads/", userInput)  // sanitize userInput first

// Insecure TLS
http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}}

// Goroutine leak / missing context cancellation
go func() {
  // No done channel or context
  for { ... }
}()

---

Ruby on Rails

# SQL injection (safe alternatives use placeholders)
User.where("name = '#{params[:name]}'")  # VULNERABLE
User.where("name = ?", params[:name])   # SAFE

# Mass assignment without strong params
@user.update(params[:user])  # should be params.require(:user).permit(...)

# eval / send with user input
eval(params[:code])
send(params[:method])  # arbitrary method call

# Redirect to user-supplied URL (open redirect)
redirect_to params[:url]

# YAML.load (allows arbitrary object creation)
YAML.load(user_input)  # use YAML.safe_load instead

---

Rust

// Unsafe blocks — flag for manual review
unsafe {
    // Reason for unsafety should be documented
}

// Integer overflow (debug builds panic, release silently wraps)
let result = a + b;  // use checked_add/saturating_add for financial math

// Unwrap/expect in production code (panics on None/Err)
let value = option.unwrap();  // prefer ? or match

// Deserializing arbitrary types
serde_json::from_str::<serde_json::Value>(&user_input)  // generally safe
// But: bincode::deserialize from untrusted input — can be exploited

Security Report Format

Use this template for all /security-review output. Generated during Step 7.

---

Report Structure

Header

╔══════════════════════════════════════════════════════════╗
║           🔐 SECURITY REVIEW REPORT                     ║
║           Generated by: /security-review skill          ║
╚══════════════════════════════════════════════════════════╝

Project: <project name or path>
Scan Date: <today's date>
Scope: <files/directories scanned>
Languages Detected: <list>
Frameworks Detected: <list>

---

Executive Summary Table

Always show this first — at a glance overview:

┌────────────────────────────────────────────────┐
│           FINDINGS SUMMARY                     │
├──────────────┬──────────────────────────────── ┤
│ 🔴 CRITICAL  │  <n> findings                  │
│ 🟠 HIGH      │  <n> findings                  │
│ 🟡 MEDIUM    │  <n> findings                  │
│ 🔵 LOW       │  <n> findings                  │
│ ⚪ INFO      │  <n> findings                  │
├──────────────┼─────────────────────────────────┤
│ TOTAL        │  <n> findings                  │
└──────────────┴─────────────────────────────────┘

Dependency Audit: <n> vulnerable packages found
Secrets Scan: <n> exposed credentials found

---

Findings (Grouped by Category)

For EACH finding, use this card format:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[SEVERITY EMOJI] [SEVERITY] — [VULNERABILITY TYPE]
Confidence: HIGH / MEDIUM / LOW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📍 Location:  src/routes/users.js, Line 47

🔍 Vulnerable Code:
  const query = `SELECT * FROM users WHERE id = ${req.params.id}`;
  db.execute(query);

⚠️  Risk:
  An attacker can manipulate the `id` parameter to execute arbitrary
  SQL commands, potentially dumping the entire database, bypassing
  authentication, or deleting data.

  Example attack: GET /users/1 OR 1=1--

✅ Recommended Fix:
  Use parameterized queries:

  const query = 'SELECT * FROM users WHERE id = ?';
  db.execute(query, [req.params.id]);

📚 Reference: OWASP A03:2021 – Injection
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Dependency Audit Section

📦 DEPENDENCY AUDIT
══════════════════

🟠 HIGH — lodash@4.17.20 (package.json)
  CVE-2021-23337: Prototype pollution via zipObjectDeep()
  Fix: npm install lodash@4.17.21

🟡 MEDIUM — axios@0.27.2 (package.json)
  CVE-2023-45857: CSRF via withCredentials
  Fix: npm install axios@1.6.0

⚪ INFO — express@4.18.2
  No known CVEs. Current version is 4.19.2 — consider updating.

---

Secrets Scan Section

🔑 SECRETS & EXPOSURE SCAN
═══════════════════════════

🔴 CRITICAL — Hardcoded API Key
  File: src/config/database.js, Line 12
  
  Found: STRIPE_SECRET_KEY = "sk_live_FAKE_KEY_..."
  
  Action Required:
  1. Rotate this key IMMEDIATELY at https://dashboard.stripe.com
  2. Remove from source code
  3. Add to .env file and load via process.env.STRIPE_SECRET_KEY
  4. Add .env to .gitignore
  5. Audit git history — key may be in previous commits:
     git log --all -p | grep "sk_live_"
     Use git-filter-repo or BFG to purge from history if found.

---

Patch Proposals Section

Only include for CRITICAL and HIGH findings:

```` 🛠️ PATCH PROPOSALS ══════════════════ ⚠️ REVIEW EACH PATCH BEFORE APPLYING — Nothing has been changed yet.

───────────────────────────────────────────── Patch 1/3: SQL Injection in src/routes/users.js ─────────────────────────────────────────────

BEFORE (vulnerable):

// Line 47
const query = `SELECT * FROM users WHERE id = ${req.params.id}`;
db.execute(query);

AFTER (fixed):

// Line 47 — Fixed: Use parameterized query to prevent SQL injection
const query = 'SELECT * FROM users WHERE id = ?';
db.execute(query, [req.params.id]);

Apply this patch? (Review first — AI-generated patches may need adjustment) ───────────────────────────────────────────── ````

---

Footer

══════════════════════════════════════════════════════════

📋 SCAN COVERAGE
  Files scanned:     <n>
  Lines analyzed:    <n>
  Scan duration:     <time>

⚡ NEXT STEPS
  1. Address all CRITICAL findings immediately
  2. Schedule HIGH findings for current sprint
  3. Add MEDIUM/LOW to your security backlog
  4. Set up automated re-scanning in CI/CD pipelines

💡 NOTE: This is a static analysis scan. It does not execute your
   application and cannot detect all runtime vulnerabilities. Pair
   with dynamic testing (DAST) for comprehensive coverage.

══════════════════════════════════════════════════════════

---

Confidence Ratings Guide

Apply to every finding:

Never omit confidence — it helps developers prioritize their review effort.

Secret & Credential Detection Patterns

Load this file during Step 3 (Secrets & Exposure Scan).

---

High-Confidence Secret Patterns

These patterns almost always indicate a real secret:

API Keys & Tokens

# OpenAI
sk-[a-zA-Z0-9]{48}

# Anthropic
sk-ant-[a-zA-Z0-9\-_]{90,}

# AWS Access Key
AKIA[0-9A-Z]{16}

# AWS Secret Key (look for near AWS_ACCESS_KEY_ID assignment)
[0-9a-zA-Z/+]{40}

# GitHub Token
gh[pousr]_[a-zA-Z0-9]{36,}
github_pat_[a-zA-Z0-9]{82}

# Stripe
sk_live_[a-zA-Z0-9]{24,}
rk_live_[a-zA-Z0-9]{24,}

# Twilio Account SID
AC[a-z0-9]{32}
# Twilio API Key
SK[a-z0-9]{32}

# SendGrid
SG\.[a-zA-Z0-9\-_.]{66}

# Slack
xoxb-[0-9]+-[0-9]+-[a-zA-Z0-9]+
xoxp-[0-9]+-[0-9]+-[0-9]+-[a-zA-Z0-9]+
xapp-[0-9]+-[A-Z0-9]+-[0-9]+-[a-zA-Z0-9]+

# Google API Key
AIza[0-9A-Za-z\-_]{35}

# Google OAuth
[0-9]+-[0-9A-Za-z_]{32}\.apps\.googleusercontent\.com

# Cloudflare (near CF_API_TOKEN)
[a-zA-Z0-9_\-]{37}

# Mailgun
key-[a-zA-Z0-9]{32}

# Heroku
[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

Private Keys

-----BEGIN (RSA |EC |OPENSSH |DSA |PGP )?PRIVATE KEY( BLOCK)?-----
-----BEGIN CERTIFICATE-----

Database Connection Strings

# MongoDB
mongodb(\+srv)?:\/\/[^:]+:[^@]+@

# PostgreSQL / MySQL
(postgres|postgresql|mysql):\/\/[^:]+:[^@]+@

# Redis with password
redis:\/\/:[^@]+@

# Generic connection string with password
(connection[_-]?string|connstr|db[_-]?url).*password=

Hardcoded Passwords (variable name signals)

# Variable names that suggest secrets
(password|passwd|pwd|secret|api_key|apikey|auth_token|access_token|private_key)
  \s*[=:]\s*["'][^"']{8,}["']

---

Entropy-Based Detection

Apply to string literals > 20 characters in assignment context. High entropy (Shannon entropy > 4.5 bits/char) + length > 20 = likely secret.

Calculate entropy: -sum(p * log2(p)) for each character frequency p
Threshold: > 4.5 bits/char AND > 20 chars AND assigned to a variable

Common false positives to exclude:

• Lorem ipsum text
• HTML/CSS content
• Base64-encoded non-sensitive config (but flag and note)
• UUID/GUID (entropy is high but format is recognizable)

---

Files That Should Never Be Committed

Flag if these files exist in the repo root or are tracked by git:

.env
.env.local
.env.production
.env.staging
*.pem
*.key
*.p12
*.pfx
id_rsa
id_ed25519
credentials.json
service-account.json
gcp-key.json
secrets.yaml
secrets.json
config/secrets.yml

Also check .gitignore — if a secret file pattern is NOT in .gitignore, flag it.

---

CI/CD & IaC Secret Risks

GitHub Actions — flag these patterns:

# Hardcoded values in env: blocks (should use ${{ secrets.NAME }})
env:
  API_KEY: "actual-value-here"   # VULNERABLE

# Printing secrets
- run: echo ${{ secrets.MY_SECRET }}   # leaks to logs

Docker — flag these:

# Secrets in ENV (persisted in image layers)
ENV AWS_SECRET_KEY=actual-value

# Secrets passed as build args (visible in image history)
ARG API_KEY=actual-value

Terraform — flag these:

# Hardcoded sensitive values (should use var or data source)
password = "hardcoded-password"
access_key = "AKIAIOSFODNN7EXAMPLE"

---

Safe Patterns (Do NOT flag)

These are intentional placeholders — recognize and skip:

"your-api-key-here"
"<YOUR_API_KEY>"
"${API_KEY}"
"${process.env.API_KEY}"
"os.environ.get('API_KEY')"
"REPLACE_WITH_YOUR_KEY"
"xxx...xxx"
"sk-..." (in documentation/comments)

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

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)

Vulnerable & High-Risk Package Watchlist

Load this during Step 2 (Dependency Audit). Check versions in the project's lock files.

---

npm / Node.js

Patterns to flag (regardless of version):

• eval or vm.runInContext in dependencies
• Any package pulling in node-gyp native addons from unknown publishers
• Packages with < 1000 weekly downloads but required in production code (supply chain risk)

---

Python / pip

---

Java / Maven

---

Ruby / Gems

---

Rust / Cargo

Reference: https://rustsec.org/advisories/

---

Go

Reference: https://pkg.go.dev/vuln/ and https://vuln.go.dev

Common risky patterns:

• golang.org/x/crypto — check if version is within 6 months of current
• Any dependency using syscall package directly — review carefully

---

General Red Flags (Any Ecosystem)

Flag any dependency that: 1. Has not been updated in > 2 years AND has > 10 open security issues 2. Has been deprecated by its maintainer with a security advisory 3. Is a fork of a known package from an unknown publisher (typosquatting) 4. Has a name that's one character off from a popular package (e.g., lodash vs 1odash) 5. Was recently transferred to a new owner (check git history / npm transfer notices)