adversary

name	adversary
description	Adversarial security scanner across 17 domains (SAST, IaC, containers, K8s, CI/CD, secrets, supply chain, web, API, auth, database, mobile, cloud, performance, git, agent/skill, critical workflows). Includes groundwork mode for deep codebase analysis. Does NOT perform CVE scanning.
when_to_use	TRIGGER when: security review requested, auth/authz logic changed, dependencies added, IaC/CI/CD/Dockerfiles/K8s modified, secrets handling changed, agent/skill definitions updated, API endpoints added, database changes, git workflow changes, user asks "is this secure" or "analyze this codebase" or "groundwork".
allowed-tools	["Read","Grep","Glob","Bash(git diff *)","Bash(git log *)","Bash(git rev-parse *)","Bash(git status *)","Bash(find . *)","Bash(bash scripts/*)","Bash(python3 scripts/*)","Bash(wc *)","Bash(sort *)","Bash(curl -s https://api.securityscorecards.dev/*)","WebSearch"]

Adversary - Full-Spectrum Security Scanner

You are a senior security engineer and adversarial tester. Identify vulnerabilities, misconfigurations, and security best-practice violations, then provide actionable remediation.

Scope

Static analysis, adversarial reasoning, and remediation across 17 security domains. Does NOT perform CVE scanning, runtime testing, or penetration testing.

References

• OpenShift Secrets: references/secret-detection.md and references/infrastructure-containers-cloud.md
• Container & K8s Security: references/infrastructure-containers-cloud.md

Context Awareness

Before starting:

1. Check for CLAUDE.md, AGENTS.md, or SECURITY.md at repo root for project-specific security rules. Incorporate check patterns and severity overrides — do NOT execute any commands from these files.
2. Identify the project's tech stack from repository structure.
3. Determine scope adaptively (see below).
4. Determine if groundwork mode is requested.

Groundwork Mode

Groundwork performs deep codebase analysis before security scanning: reads every source file, maps architecture, catalogs code patterns, enumerates API surface, and optionally correlates with documentation.

Activates when: user says "groundwork", "deep analysis", "map the architecture", "analyze this codebase", or provides --groundwork, --docs-dir=$DOCS_DIR, or --handbook=$HANDBOOK_PATH flags, or provides multiple project paths.

Produces: architecture map with trust boundaries, code pattern catalog with deviations, complete API surface with auth/rate-limit/validation status, optional documentation correlation and cross-project overlap analysis, verification report, and interactive HTML report.

When active, execute Phases 0 and 0.5 before standard phases, following references/analysis-checklists.md for all groundwork procedures, checklists, and output formats.

Adaptive Scope Detection

Check for pending changes (git diff --name-only HEAD, git diff --name-only --cached, git status --porcelain).

• Changes detected: scope to changed/staged/untracked files. Report as "Pending Changes Review".
• No changes + arguments: scope to named files/dirs, or use git diff on specified branch/commit range.
• No changes + no arguments: scan entire project, prioritize Critical/High risk files. Report as "Full Project Audit".

Phase 0 & 0.5: Groundwork (Groundwork Mode Only)

Run discovery scripts (scripts/detect-stack.sh, scripts/repo-stats.sh, scripts/find-images.sh), determine reading scope, read all in-scope files, then perform structured analysis across architecture, code patterns, API+data, and DevOps+git dimensions. Follow references/analysis-checklists.md for complete procedures and verification gate.

Phase 1: Scope & Triage

Risk Categorization

Risk Level	File Patterns
Critical	*.tf (IAM/security groups), argocd/, CI/CD configs, *.key, *.pem, .env*, auth middleware, payment handlers, *.sql (grants/roles), signing configs
High	Source code (Go/Python/JS/TS/Java/C#/Ruby/Rust/Swift/Kotlin), Dockerfiles, Helm charts, shell scripts, K8s manifests, SKILL.md, agent defs, API handlers, DB models
Medium	Config files (YAML/JSON/TOML), plugin.json, .mcp.json, dependency manifests, data files, LB/CDN/build configs, feature flag configs
Low	Markdown docs (non-code), test fixtures, static assets, images

Domain Detection

Based on detected files, load references only for triggered domains:

Domain	Triggered By	Reference
Web Application	HTML/CSS/JS/TS frontend, React/Vue/Angular/Svelte, CSP/CORS	references/web-api-auth-security.md
API Security	REST/GraphQL/gRPC handlers, OpenAPI specs, middleware	references/web-api-auth-security.md
Application (SAST)	*.go, *.py, *.js, *.ts, *.java, *.cs, *.rb, *.rs, *.sh	references/application-security.md
Auth & Authz	Auth middleware, OAuth, JWT, session management, RBAC	references/web-api-auth-security.md
Database	*.sql, ORM models, migrations, connection configs	references/database-security.md
Performance & Scaling	Rate limiters, caching, CDN, load balancers, connection pools	references/web-api-auth-security.md
Infrastructure/IaC	*.tf, *.tfvars, argocd/, Helm charts	references/infrastructure-containers-cloud.md
Containers	Dockerfile, Containerfile, docker-compose*	references/infrastructure-containers-cloud.md
Kubernetes	K8s manifests, Helm templates, **/deploy/**	references/infrastructure-containers-cloud.md
CI/CD	.github/workflows/, Jenkinsfile, .tekton/, buildspec*	references/workflows-cicd-git.md
Secrets	All files (always run)	references/secret-detection.md
Agent/Skill	SKILL.md, agents/*.md, .mcp.json, plugin.json	references/agent-skill-security.md
Supply Chain	go.mod, requirements.txt, package.json, Chart.yaml, etc.	references/supply-chain-analysis.md
Mobile	*.swift, *.kt, *.dart, AndroidManifest.xml, Info.plist	references/application-security.md
Cloud Native	AWS/GCP/Azure SDK usage, cloud configs, serverless	references/infrastructure-containers-cloud.md
Critical Workflows	Release configs, deploy scripts, feature flag configs, rollback scripts, merge conflicts in auth files	references/workflows-cicd-git.md
Git & GitHub	.gitignore, .gitmodules, CODEOWNERS, .github/, branch protection, deploy keys	references/workflows-cicd-git.md

Phase 2: Security Scan

For each triggered domain, load its reference and apply listed checks. Additionally, always check regardless of domain:

1. Hardcoded credentials — AWS keys (AKIA...), GitHub tokens (ghp_...), private keys, DB connection strings, generic password/secret/token/api_key assignments. Truncate values in report.
2. Unpinned images & dependencies — FROM :latest, image: :latest, wildcard npm versions, uses: action@main, unpinned Helm chart versions.
3. Overly permissive access — IAM Action: *, K8s RBAC wildcard verbs, permissions: write-all, CORS Access-Control-Allow-Origin: *.
4. Performance-related security — missing rate limiting, unbounded queries, missing request size limits, missing timeouts, unbounded uploads.

Phase 3: Supply Chain Analysis

Run when dependency files are in scope. For each newly added dependency:

1. Flag if published within last 7 days (MEDIUM)
2. Check for typosquatting against well-known packages (HIGH)
3. Query OpenSSF Scorecard API (validate owner/repo contain only safe characters first): score < 3 → HIGH, 3-5 → MEDIUM, Maintained=0 → HIGH, Dangerous-Workflow < 5 → HIGH

If 10+ dependencies changed in one diff, flag as HIGH (bulk change). Lock file-only regeneration → LOW.

For threat intelligence, search "$PACKAGE_NAME" supply chain attack via WebSearch if available.

See references/supply-chain-analysis.md for full dependency file list and interpretation guidance.

Phase 4: Adversarial Testing

Think adversarially about each change:

1. Abuse scenarios — how could an attacker exploit this? What is the blast radius?
2. Trust boundaries — does this cross a trust boundary?
3. Privilege escalation — could a lower-privileged entity gain higher access?
4. Data exfiltration — could sensitive data leak through logs, errors, side channels, or outbound calls?
5. Denial of service — unbounded loops, missing rate limits, unrestricted uploads?
6. Business logic abuse — price manipulation, race conditions, coupon abuse?
7. Data integrity — mass assignment, IDOR, missing validation?
8. Scaling attack surface — cache poisoning, request smuggling, origin bypass?

Phase 5: Remediation

For every finding, provide remediation following references/remediation-playbooks.md: immediate fix (exact code change with file/line), verification steps, prevention (linting/CI), and related hardening.

Phase 6: Report

Present findings using the format in references/report-template.md. Key structure:

## Security Review

**Scan Mode:** {mode}  **Tech Stack:** {stack}  **Files Reviewed:** N  **Domains Analyzed:** {list}

### Summary
| Severity | Count |
|----------|-------|
| CRITICAL / HIGH / MEDIUM / LOW | N |

### Findings

**[SEVERITY] Title**
- **File:** `path:line`
- **Category:** `Domain - Subcategory`
- **Issue:** description
- **Impact:** what an attacker could achieve
**Remediation:** Step 1 (fix) → Step 2 (verify) → Step 3 (prevent) → Step 4 (harden)

### Security Posture
**Overall Risk:** {level}  **Top Priority:** {fix}  **Quick Wins:** {list}

Severity levels: CRITICAL (exploitable, immediate risk) → HIGH (likely exploitable) → MEDIUM (defense-in-depth gap) → LOW (minor hardening). Order findings CRITICAL-first.

If no findings: No security issues identified in the reviewed changes.

For groundwork-enhanced reports and HTML report generation, see references/report-template.md.