security-sweep

Scan codebase for security vulnerabilities, hardcoded secrets, injection flaws, misconfigurations, and attack surfaces. Use when user wants a security audit, vulnerability scan, or to find security issues.

install

source · Clone the upstream repo

git clone https://github.com/Onome-AJ/security-sweep-plugin

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/Onome-AJ/security-sweep-plugin "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/security-sweep" ~/.claude/skills/onome-aj-security-sweep-plugin-security-sweep && rm -rf "$T"

manifest: skills/security-sweep/SKILL.md

source content

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.

$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:

Top 3 Priorities — The 3 most impactful issues to fix first, with reasoning
Positive Findings — Security practices the project is doing well (e.g., using parameterized queries, proper .gitignore, CSP headers present)
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.