Security Audit

Security Audit

Perform a comprehensive security audit of a repository based on industry-standard methodologies (OWASP, SANS, CWE). Find vulnerabilities, misconfigurations, and security anti-patterns. Optionally create GitHub issues for critical findings.

Step 0 — Determine target

If the user provided a GitHub URL, extract owner/repo. If a local path, use directly. If neither, use current working directory.

Ask: "Should I create GitHub issues for critical/high findings?" if not specified.

Step 1 — Reconnaissance

Understand the application before attacking:

1. Identify stack: language, framework, database, cloud provider
2. Map attack surface: endpoints, auth mechanisms, file uploads, external integrations
3. Read configs: docker-compose.yml, Dockerfile, .env.example, CI/CD files, IaC templates
4. Identify entry points: API routes, CLI commands, event handlers, WebSocket endpoints
5. Check dependencies: requirements.txt, package.json, Cargo.toml, go.mod

Output: brief summary of stack, architecture, and attack surface.

Step 2 — Dependency Analysis

2.1 Known Vulnerabilities

# Python
gh api repos/<owner>/<repo>/dependabot/alerts --jq '.[] | select(.state=="open")'
# Or locally:
pip audit / safety check / poetry show --outdated

# Node
npm audit --json / yarn audit --json

# Go
govulncheck ./...

2.2 Supply Chain Risks

Check for:

• Typosquatting packages (names similar to popular packages)
• Pinned vs unpinned versions
• Lock file presence and integrity
• Private registry configs exposed
• Post-install scripts in dependencies

Step 3 — Secrets & Sensitive Data

Scan for hardcoded secrets:

Patterns to search

Files to check

• .env, .env.* (should be in .gitignore)
• Config files committed to repo
• Test fixtures with real credentials
• CI/CD pipeline files (secrets in plain text)
• Dockerfile with ARG/ENV secrets
• git log for previously committed secrets

Step 4 — Authentication & Session Management

4.1 Auth Flaws

4.2 JWT Specific

• Algorithm set to none accepted?
• HMAC key brute-forceable (short/common)?
• No exp claim?
• Secret in source code?
• kid parameter injection?
• JWK/JWKS injection?

Step 5 — Authorization & Access Control

Code patterns to flag

# IDOR - no ownership check
@app.get("/users/{user_id}/data")
def get_data(user_id: int):
    return db.query(User).get(user_id)  # WHO is requesting?

# Mass assignment
user.update(**request.json)  # Accepts ANY field including role

Step 6 — Injection Attacks

6.1 SQL Injection

# VULNERABLE - string formatting
query = f"SELECT * FROM users WHERE id = {user_input}"
cursor.execute(f"DELETE FROM {table} WHERE id = %s")  # table name injection

# SAFE - parameterized
cursor.execute("SELECT * FROM users WHERE id = %s", (user_input,))

Look for: raw SQL with string interpolation, ORM .extra(), .raw(), dynamic table/column names.

6.2 Command Injection

# VULNERABLE
os.system(f"ping {user_input}")
subprocess.call(f"convert {filename} output.png", shell=True)

# SAFE
subprocess.run(["ping", user_input], shell=False)

Look for: os.system, subprocess with shell=True, eval(), exec(), backticks in any language.

6.3 Template Injection (SSTI)

# VULNERABLE - Jinja2
template = Template(user_input)  # User controls template
render_template_string(user_input)

# SAFE
render_template("fixed_template.html", data=user_input)

6.4 XSS (Cross-Site Scripting)

• innerHTML, dangerouslySetInnerHTML, v-html
• Unescaped template variables: {!! $var !!}, <%- var %>
• Reflected input in HTML without encoding
• DOM-based XSS via document.location, window.name

6.5 LDAP / NoSQL / GraphQL Injection

• MongoDB: $where, $regex, $gt from user input
• GraphQL: introspection enabled in prod, no depth/complexity limits
• LDAP: unescaped (cn={input}) filters

Step 7 — API Security

Step 8 — Cryptography

Step 9 — Infrastructure & Configuration

9.1 Docker

• Running as root (USER directive missing)
• Secrets in build args
• latest tag (unpinned)
• Exposed debug ports
• No health check
• Writable filesystem when unnecessary

9.2 CI/CD

• Secrets in plain text in workflow files
• pull_request_target with checkout of PR code (code injection)
• No branch protection on main
• Artifacts with sensitive data
• Self-hosted runners without isolation

9.3 Cloud (AWS/GCP/Azure)

• S3 buckets public
• IAM policies with * resource
• Security groups with 0.0.0.0/0 on non-HTTP ports
• Lambda with excessive permissions
• No encryption at rest
• CloudTrail/audit logging disabled

9.4 Database

• Default credentials
• No connection encryption
• Exposed to internet
• No query timeout
• Missing indexes on auth tables (timing attacks)

Step 10 — Business Logic

Step 11 — File Operations

Step 12 — Scoring & Report

Severity Classification (CVSS-inspired)

Output Format

For each finding:

## [SEVERITY] Title

**Category:** OWASP A01-A10 / CWE-XXX
**Location:** `file:line`
**Impact:** What an attacker can do
**Proof:** Code snippet showing the vulnerability
**Fix:** Remediation with code example
**References:** Links to relevant docs/standards

Step 13 — Final Report

# Security Audit Report

**Repository:** owner/repo
**Date:** YYYY-MM-DD

## Executive Summary

- Critical: N
- High: N
- Medium: N
- Low: N
- Total findings: N

## Findings

[List all findings sorted by severity]

## Recommendations

[Prioritized action items]

## Methodology

Based on:
- OWASP Testing Guide v4.2
- OWASP Top 10 (2021)
- CWE Top 25
- SANS Top 25
- PTES (Penetration Testing Execution Standard)

Guidelines

• Never exploit — only identify and document
• No false positives — only flag code YOU can confirm is vulnerable
• Context matters — internal tools have different risk profiles than public APIs
• Check git history — secrets may have been committed and removed
• Prioritize — focus on what's exploitable, not theoretical
• Be specific — include file:line, code snippet, and concrete fix
• Reference standards — CWE, OWASP, CVE when applicable
• Run agents in parallel for Steps 3-11 when possible to maximize efficiency

Quick Reference — OWASP Top 10 (2021)