Security Analysis

Security Analysis Framework

Perform a comprehensive security vulnerability scan and analysis of the current project. Identifies the technology stack, scans for vulnerabilities in source code and dependencies, assesses real-world risk with context-aware analysis, and produces an actionable remediation roadmap.

Conditional-Load Confirmation

paths: does not auto-run this skill — it only makes the skill loadable once you (Claude) have touched one of the listed manifest files with a Read, Edit, or Write tool call this session (see ADR-0012). If you then choose to invoke this skill on your own initiative because you noticed such a manifest was touched — rather than the user directly asking for /security-analysis — confirm first with AskUserQuestion:

{
  "questions": [
    {
      "question": "A dependency manifest file was changed (package.json, pyproject.toml, Cargo.toml, go.mod, requirements.txt, or Gemfile). Run a security scan now? This audits dependencies for known CVEs and may take 1-15 minutes depending on project size.",
      "header": "Security",
      "multiSelect": false,
      "options": [
        {
          "label": "Yes - dependencies only",
          "description": "Faster scan targeting the changed manifests only (--dependencies-only). Skips deep taint analysis and fuzzing methodology review."
        },
        {
          "label": "Yes - full scan",
          "description": "Complete scan: tech-stack detection, dependency audit, source-code patterns, taint analysis, and fuzzing methodology review."
        },
        {
          "label": "No",
          "description": "Nothing is scanned; you can run /security-analysis manually at any time."
        }
      ]
    }
  ]
}

• "Yes - dependencies only": proceed with the full scan using the instructions below, passing --dependencies-only (the default for this path — faster; targets the changed manifests).
• "Yes - full scan": proceed with the full scan using the instructions below with no --dependencies-only flag (complete scan).
• "No": respond with "Security scan skipped. You can run /security-analysis manually at any time." and exit immediately — do not perform any scanning.

A separate --quick surface-only mode (tech detection, dependency audit, top-level patterns only — see Input Validation below) remains available as a manual override on direct invocation; it is not one of the confirmation options above.

When invoked directly by the user, skip this prompt and proceed immediately.

Input Validation

Optional Arguments:

• <path> - Directory or file path to analyze (defaults to current working directory)
• --quick - Surface scan only: technology detection, dependency audit, and top-level code patterns. Skips deep taint analysis and fuzzing methodology review.
• --dependencies-only - Only check dependency vulnerabilities (skip source code analysis)

Usage:

/security-analysis                          # Full scan of current project
/security-analysis src/                     # Scan specific directory
/security-analysis --quick                  # Fast surface-level scan
/security-analysis --dependencies-only      # Dependencies only

Performance

Duration scales with codebase size (file count and total LOC). Web searches for CVE verification add latency when network-dependent lookups are required.

Scope vs /security-review

Routing guidance: Use /security-review when you want a fast check on what you're about to ship. Use this skill (/security-analysis) when you need full-project assurance — dependency CVE audit, static analysis across the entire codebase, and a prioritized remediation roadmap.

Core Security Analysis Process

Phase 1: Discovery and Reconnaissance

1. Technology Stack Detection: Identify languages, frameworks, and dependencies by scanning for manifest files (package.json, requirements.txt, pom.xml, go.mod, Cargo.toml, etc.)
2. Attack Surface Mapping: Enumerate all entry points (APIs, forms, file uploads, CLI arguments, environment variables)
3. Dependency Inventory: List all direct and transitive dependencies with version numbers
4. Configuration Review: Check for security-relevant configurations (CORS, CSP, auth settings)

Phase 2: Vulnerability Scanning

A. Static Code Analysis

Scan source code for OWASP Top 10 and common vulnerability patterns:

• Injection Vulnerabilities: SQL, NoSQL, Command, LDAP, XPath, Template injection
• Broken Authentication: Weak password policies, session fixation, credential storage
• Sensitive Data Exposure: Hardcoded secrets, unencrypted data, logging sensitive info
• XML External Entities (XXE): Unsafe XML parsing
• Broken Access Control: Missing authorization checks, IDOR vulnerabilities
• Security Misconfiguration: Default credentials, unnecessary features enabled
• Cross-Site Scripting (XSS): Reflected, Stored, DOM-based
• Insecure Deserialization: Unsafe object deserialization
• Using Components with Known Vulnerabilities: Outdated dependencies
• Insufficient Logging and Monitoring: Missing security event logging

B. Dependency Vulnerability Analysis

IMPORTANT: Always run native security audit tools FIRST before web search for faster and more accurate results.

For each dependency:

1. Extract Version Information: From package manifests
2. Run Native Security Audit Tools (Primary Method):
   • Node.js/JavaScript: npm audit or npm audit --json
   • Python: pip-audit or safety check
   • Java/Maven: mvn dependency-check:check
   • Java/Gradle: ./gradlew dependencyCheckAnalyze
   • .NET: dotnet list package --vulnerable
   • PHP/Composer: composer audit
   • Ruby: bundle audit check
   • Rust: cargo audit
   • Go: govulncheck ./...
3. Parse Audit Results: Extract CVE IDs, severity levels, and affected versions from tool output
4. Web Search for CVEs (Secondary/Verification Method): NVD, Snyk, GitHub Security Advisories
5. Check Latest Versions: Compare against current stable releases
6. Assess Severity: Use CVSS scores and exploit availability
7. Verify Patch Availability: Check if fixes exist and are stable

C. Context-Aware Analysis

For each identified vulnerability:

1. Code Path Tracing: Is the vulnerable code actually used?
2. Import Analysis: Are vulnerable functions imported?
3. Call Graph Analysis: Are vulnerable methods called?
4. Data Flow Analysis: Does user input reach vulnerable code?
5. Environment Context: Is this a dev-only or production dependency?

Phase 3: Advanced Vulnerability Discovery

Skip this phase if --quick flag is set.

A. Taint Analysis and Data Flow Tracing

1. Identify Sources: Map all entry points (req.body, argv, params, headers)
2. Identify Sinks: Map dangerous functions (eval(), exec(), innerHTML, SQL execution)
3. Trace Flow: Trace if input reaches a sink without a sanitizer step
4. Zero Tolerance: If ANY user input reaches a sensitive sink without strict validation, flag as CRITICAL

B. Logic Abusability

1. Race Conditions: Identify concurrent state updates (db transactions, file writes)
2. Business Logic: Can you buy an item for $0? Can you access data ID+1?
3. State Manipulation: Can you skip a step in a multi-step flow?

C. Data Compromise Check

1. Leakage: Are PII, secrets, or internal IDs exposed in logs, error messages, or API responses?
2. Integrity: Can data be modified without authorization?
3. Availability: Can a payload cause a crash or high resource consumption (DoS)?

Phase 4: Risk Assessment

Severity Classification

CRITICAL (CVSS 9.0-10.0)
- Remote code execution
- Authentication bypass
- SQL injection in production endpoints
- Exposed secrets/credentials

HIGH (CVSS 7.0-8.9)
- Privilege escalation
- Sensitive data exposure
- XSS in authenticated areas
- Known exploits available

MEDIUM (CVSS 4.0-6.9)
- CSRF vulnerabilities
- Information disclosure
- Weak cryptography
- Outdated dependencies with patches available

LOW (CVSS 0.1-3.9)
- Minor information leaks
- Deprecated functions
- Code quality issues with security implications

INFO (CVSS 0.0)
- Security best practice recommendations
- Hardening opportunities
- Awareness items

Risk Factors

• Exploitability: How easy to exploit? (Automated, Simple, Complex, Theoretical)
• Impact: What's at risk? (Data breach, Service disruption, Financial loss)
• Scope: What's affected? (Single user, All users, System-wide)
• Exposure: Who can exploit? (Internet, Authenticated users, Admins only)

Phase 5: Remediation Planning

Remediation Strategies

1. Immediate Fixes (Critical/High)

   • Version upgrades with compatibility verification
   • Code patches with security testing
   • Configuration hardening
   • Temporary mitigations (WAF rules, input validation)

2. Scheduled Fixes (Medium)

   • Plan for next sprint/release
   • Coordinate with feature development
   • Comprehensive testing required

3. Long-term Improvements (Low/Info)

   • Architectural refactoring
   • Security framework adoption
   • Developer training needs

Upgrade Guidance Template

Package: [name]
  Current Version: [x.y.z]
  Vulnerable: YES
  CVE: [CVE-YYYY-NNNNN]
  Severity: [LEVEL]
  Fixed In: [a.b.c]
  Latest Stable: [p.q.r]
  Breaking Changes: [YES/NO]
  Migration Guide: [URL]
  Recommendation: Upgrade to [version] - [reason]

Technology-Specific Security Patterns

For detailed vulnerability signatures and check patterns by language/framework, refer to the reference files in the plugin's references/ directory. The following summaries indicate key focus areas per stack:

Web Search Strategy for Vulnerability Intelligence

Required Searches

For each dependency with suspected vulnerabilities, perform:

1. CVE Search: "[package-name]" CVE [current-year] [previous-year]
2. Security Advisory: "[package-name]" security advisory vulnerability
3. Version Check: "[package-name]" latest stable version
4. Known Exploits: "[package-name]" exploit proof of concept

Trusted Sources

• NVD (nvd.nist.gov)
• Snyk Vulnerability Database
• GitHub Security Advisories
• npm/PyPI/Maven/NuGet security pages
• OWASP resources

Output

Output Location: Write security report to reports/security-analysis-[YYYYMMDD-HHMMSS].md

Security Report Structure

# Security Analysis Report
Generated: [timestamp]
Project: [name]
Scan Scope: [files/dependencies scanned]
Scan Mode: [Full / Quick / Dependencies-Only]

## Executive Summary
- Total Vulnerabilities: [count]
- Critical: [count] | High: [count] | Medium: [count] | Low: [count]
- Immediate Action Required: [YES/NO]

## Critical Findings
[List of critical vulnerabilities requiring immediate attention]

## Detailed Analysis

### File-Level Vulnerabilities
[Per-file security issues with code snippets and line numbers]

### Dependency Vulnerabilities
[Per-package analysis with CVE details and upgrade paths]

### Context-Aware Risk Assessment
[Analysis of which vulnerabilities are actually exploitable in this codebase]

## Remediation Roadmap
### Immediate (0-24 hours)
[Critical fixes]

### Short-term (1-7 days)
[High priority fixes]

### Medium-term (1-4 weeks)
[Medium priority improvements]

### Long-term (1-3 months)
[Low priority and architectural improvements]

## Verification Steps
[How to test that fixes work correctly]

## References
[Links to CVE databases, security advisories, documentation]

Examples

Full scan of a Node.js project:

/security-analysis

Output: A comprehensive report at reports/security-analysis-20260304-141522.md covering dependency CVEs from npm audit, static code analysis for XSS and injection patterns, and a prioritized remediation roadmap.

Quick scan of a specific directory:

/security-analysis src/api/ --quick

Output: Surface-level scan covering technology detection, dependency audit, and top-level code patterns for the src/api/ directory only. Skips deep taint analysis.

Dependencies-only audit before a release:

/security-analysis --dependencies-only

Output: Runs npm audit / pip-audit / native tools for all detected package manifests. Reports known CVEs with severity, affected versions, and upgrade paths. No source code analysis performed.

Typical report summary:

Security Analysis Report
========================
Total Vulnerabilities: 7
  Critical: 0 | High: 2 | Medium: 3 | Low: 2
  Immediate Action Required: YES

Critical Findings: None
High Findings:
  - express@4.17.1: CVE-2024-XXXXX (path traversal) — upgrade to 4.21.0+
  - jsonwebtoken@8.5.1: CVE-2022-23529 (insecure default) — upgrade to 9.0.0+

Error Handling

Best Practices

• Always verify vulnerability information from multiple sources
• Consider the specific context of the application
• Provide clear, actionable remediation steps
• Include code examples for fixes
• Link to official documentation
• Respect responsible disclosure practices
• Focus on practical, implementable solutions