Security sweep

Security Sweep

Run a comprehensive security scan of the codebase. This skill identifies vulnerabilities, hardcoded secrets, injection flaws, misconfigurations, and attack surfaces across web and mobile applications.

Arguments

• $0 (optional): Scan scope — one of: all, secrets, injection, auth, config, deps, ai, mobile, data. Defaults to all.
• $1 (optional): Path to scan. Defaults to the project root.

If $ARGUMENTS is empty, run a full all scan from the project root.

Execution Plan

Step 1: Tech Stack Detection

Before scanning, detect the project's tech stack by checking for indicator files. This determines which language-specific checks to run.

Indicator File	Stack	Scan Focus
package.json	Node.js/JS/TS	npm patterns, XSS sinks, eval, child_process
requirements.txt, pyproject.toml, setup.py, Pipfile	Python	pickle, subprocess, Jinja2, Django/Flask patterns
pom.xml, build.gradle, build.gradle.kts	Java/Kotlin	JDBC injection, ObjectInputStream, Spring patterns
Gemfile	Ruby	Marshal, system(), ERB patterns
go.mod	Go	fmt.Sprintf in SQL, crypto patterns
Cargo.toml	Rust	unsafe blocks, FFI
composer.json	PHP	exec, unserialize, include with vars
*.csproj	.NET	BinaryFormatter, SqlCommand concat
AndroidManifest.xml	Android	exported components, cleartext, SharedPreferences
Info.plist, *.xcodeproj, Podfile	iOS	NSUserDefaults, ATS bypass
Dockerfile	Docker	FROM :latest, root user, secrets in build
*.tf, *.hcl	Terraform	public ACLs, open CIDR
next.config.*	Next.js	SSR-specific checks
pubspec.yaml	Flutter/Dart	Dart-specific mobile checks

Use Glob to detect which of these exist, then tailor the scan accordingly.

Step 2: Run Scans by Priority

Run the scans below in order. If a scope argument was provided, only run that specific scan module. Use the patterns from patterns.md for each module.

For each scan module, use Grep with the relevant regex patterns from patterns.md. Search across the detected file types. Skip node_modules/, vendor/, .git/, dist/, build/, __pycache__/, .venv/, venv/, .next/, .nuxt/, target/, Pods/, .gradle/ directories.

Module 1: SECRETS (Critical Priority)

Scan for hardcoded API keys, tokens, private keys, credentials, database connection strings, and committed secret files. See patterns.md Section 1.

Also check:

• Whether .env files exist in the repo (they should be gitignored)
• Whether .gitignore covers .env*, *.pem, *.key, *.p12, credentials*.json
• Whether any *.pem, *.key, *.p12, *.pfx, *.jks files are present

Module 2: INJECTION (Critical Priority)

Scan for SQL injection, XSS, command injection, SSRF, insecure deserialization, and path traversal patterns. See patterns.md Section 2.

Module 3: AUTH (High Priority)

Scan for JWT misuse, weak password handling, insecure session config, broken access control. See patterns.md Section 3.

Module 4: CONFIG (High Priority)

Scan for CORS misconfiguration, missing security headers, exposed debug endpoints, insecure TLS, Docker issues, Kubernetes/Terraform misconfig. See patterns.md Section 4.

Module 5: DEPS (High Priority)

Check dependency manifests for:

• Missing lockfiles alongside manifests
• Suspicious install scripts in package.json (preinstall/postinstall with curl/wget/bash)
• Known risky or deprecated packages

Module 6: AI (High Priority)

Scan for AI-specific issues: hardcoded AI API keys, prompt injection vectors, eval/exec of LLM output, system prompt leakage, excessive agent permissions. See patterns.md Section 5.

Module 7: MOBILE (High Priority — only if Android/iOS detected)

Scan for insecure data storage, missing certificate pinning, cleartext traffic, debug flags, weak crypto. See patterns.md Section 6.

Module 8: DATA (Medium Priority)

Scan for PII in logs, sensitive data in URLs, plaintext HTTP to external hosts. See patterns.md Section 7.

Step 3: Generate Report

After all scans complete, produce a structured report.

Report Format

Start with a summary banner:

============================================
  SECURITY SWEEP REPORT
  Project: <project name>
  Scanned: <date>
  Tech Stack: <detected stacks>
============================================

SUMMARY
  CRITICAL: <count>
  HIGH:     <count>
  MEDIUM:   <count>
  LOW:      <count>
  INFO:     <count>
  TOTAL:    <count>
============================================

Then list findings grouped by severity (CRITICAL first), with this format for each:

[SEVERITY] CATEGORY — Finding Title
  File: path/to/file.ext:line_number
  Evidence: <the matching code snippet, max 2 lines>
  Risk: <1-sentence explanation of the attack scenario>
  Fix: <specific remediation with code example>
  Ref: <CWE or OWASP reference>

After the findings, include:

1. Top 3 Priorities — The 3 most impactful issues to fix first, with reasoning
2. Positive Findings — Security practices the project is doing well (e.g., using parameterized queries, proper .gitignore, CSP headers present)
3. Recommendations — General security improvements not tied to a specific finding

Important Guidelines

• Minimize false positives: When a pattern match looks like it might be a false positive (e.g., a test file, a comment, an example/documentation), note it as [INFO] rather than flagging it at high severity. Use your contextual understanding of the code to distinguish real issues from benign matches.
• Read files for context: When a grep match is ambiguous, use Read to examine surrounding code before classifying severity. For example, a pickle.load() in a test fixture is lower risk than one in a web endpoint.
• Skip vendored/generated code: Do not flag issues in node_modules/, vendor/, generated files, or lock files.
• Be framework-aware: Understand that some frameworks have built-in protections (e.g., Django ORM prevents SQL injection, React escapes by default, Angular sanitizes innerHTML). Adjust severity accordingly.
• Deduplicate: If the same pattern appears many times (e.g., console.log(req.body) in 20 files), group them as one finding with a count rather than listing each separately.