security-scan

name	security-scan
description	Technology-agnostic security scan for any codebase. Covers dependency audit, OWASP Top 10 (and beyond), configuration review, and generates severity-sorted report with fix suggestions. Works with any language or framework. Trigger phrases: "security scan", "guvenlik taramasi", "OWASP check", "vulnerability scan", "zafiyet tara", "find security issues", "audit security"

Security Scan

Perform a comprehensive, technology-agnostic security audit: detect the stack, audit dependencies, scan code for vulnerabilities (OWASP Top 10 and beyond), check configuration, and produce a severity-sorted report with actionable fixes.

Overview

This skill is technology-agnostic — it works with any language, framework, or runtime. It uses web search to stay current with the latest vulnerability patterns and tools.

Steps executed in order:

1. Project analysis — detect language/framework
2. Dependency audit — run ecosystem-appropriate audit tools
3. Code scan — OWASP Top 10 as baseline + additional vulnerabilities discovered during analysis
4. Config scan — find dangerous configuration mistakes
5. Report — produce a severity-sorted findings list
6. Fix offering — let the user choose how to apply fixes
7. Safety rules — constraints that apply throughout the scan

Pre-Scan Checklist

• Project language and framework detected
• Dependency audit completed for each detected ecosystem
• Code scanned for all applicable OWASP Top 10 categories
• Configuration files checked for security anti-patterns
• Report generated with severity-sorted findings
• Fix options presented to user
• No secrets exposed in report output

---

Step 1: Project Analysis

Scan the project to determine the language, framework, and package ecosystem. This skill is technology-agnostic — it works with any language or framework.

Instructions:

1. Search for manifest/build files in the project root and subdirectories (e.g., package.json, requirements.txt, go.mod, Cargo.toml, Gemfile, pom.xml, build.gradle, composer.json, *.csproj, *.sln, mix.exs, Makefile, etc.)
2. If multiple ecosystems are detected (e.g., a monorepo), record all of them.
3. Read the manifest to identify the specific framework from dependencies.
4. Use web search to find the current recommended security audit tool and commands for the detected ecosystem — tools and best practices change frequently.
5. Store the detected stack — it determines which audit commands to run and which code patterns to check.

---

Step 2: Dependency Audit

Check installed packages against known vulnerability databases.

Instructions:

1. Identify the package manager(s) used in the project.
2. Use web search to find the current recommended audit command for that ecosystem (e.g., npm audit, pip audit, dotnet list package --vulnerable, cargo audit, etc.). Tools evolve — always check for the latest approach.
3. If the audit tool is not installed, inform the user and offer to install it.
4. Run the audit command and capture output.
5. Parse results: extract package name, installed version, vulnerability ID (CVE), severity, and fixed version if available.
6. Include all findings in the final report (Step 5).

Tips:

• Use --json or equivalent flag for machine-readable output when available.
• For ecosystems without a built-in audit command, search for third-party tools (e.g., OWASP Dependency-Check works across Java, .NET, and others).
• In monorepos, run audit for each sub-project separately.

---

Step 3: Code Scan — Security Vulnerability Analysis

Scan the project source code for security vulnerabilities. This scan is technology-agnostic — apply these concepts regardless of the programming language or framework.

OWASP Top 10 is the mandatory baseline. Every scan MUST check for OWASP Top 10 categories. But do NOT stop there — if you discover additional vulnerabilities during the scan, include them.

Before scanning: Use web search for:

• "OWASP Top 10 latest" — to get the current OWASP Top 10 list (it's updated periodically)
• "[framework name] security best practices" — framework-specific guidance
• "[framework name] common vulnerabilities" — known vulnerability patterns for this stack

Scan Approach

For each vulnerability category below:

1. Identify user input entry points — routes, API endpoints, form handlers, CLI arguments, file uploads, WebSocket handlers
2. Trace data flow — follow user input through the code to where it's used
3. Check for sanitization — is the input validated, escaped, or parameterized before use?
4. Use web search for framework-specific vulnerability patterns (e.g., search "[framework name] security vulnerabilities common patterns")

Vulnerability Categories

Do NOT limit yourself to this list. These are the minimum categories to check. If you discover additional security issues during the scan, include them.

Injection Vulnerabilities

• SQL Injection — user input concatenated/interpolated into SQL queries instead of using parameterized queries or prepared statements
• Command Injection — user input passed to shell/system commands instead of using safe argument arrays
• LDAP Injection — user input in LDAP queries without escaping
• NoSQL Injection — user input directly in MongoDB/NoSQL query objects without sanitization
• Template Injection (SSTI) — user input rendered as template code instead of template data
• Expression Language Injection — user input evaluated as code in expression engines

Cross-Site Vulnerabilities

• XSS (Cross-Site Scripting) — user input rendered in HTML without escaping or sanitization
• CSRF (Cross-Site Request Forgery) — state-changing endpoints without CSRF token protection
• CORS Misconfiguration — wildcard origins with credentials, reflected origins without validation

Data Exposure

• Hardcoded Secrets — API keys, passwords, tokens, private keys in source code. Search with regex patterns:

  password\s*=\s*["'][^"']+["']
  api[_-]?key\s*=\s*["'][^"']+["']
  secret\s*=\s*["'][^"']+["']
  -----BEGIN (RSA |EC |DSA )?PRIVATE KEY-----
  

  Exclude test fixtures and .env.example with placeholder values.
• Sensitive Data in Logs — passwords, tokens, PII logged without masking
• Information Disclosure — stack traces, debug info, or internal paths exposed to users

File & Path Vulnerabilities

• Path Traversal — user input in file paths without validation (e.g., ../../../etc/passwd)
• Unrestricted File Upload — no validation on file type, size, or content; files stored in executable paths

Deserialization & Data Handling

• Insecure Deserialization — deserializing untrusted data with unsafe methods (language-specific: check the framework's docs for safe alternatives)
• Mass Assignment — all object fields bindable from user input without allowlisting

Authentication & Authorization

• Broken Authentication — weak password policies, missing rate limiting on login, session tokens in URLs
• Broken Access Control — missing authorization checks on endpoints, IDOR (direct object references without ownership verification)
• JWT Issues — algorithm confusion (alg: none), secrets in code, missing expiration
• Admin Panel / Privileged Area Authorization — if the project has an admin panel, dashboard, or any role-based access:
  • Are admin routes protected by authentication middleware?
  • Is there role/permission checking (not just "is logged in" but "is admin/authorized")?
  • Can a regular user access admin endpoints by guessing URLs?
  • Are admin API endpoints separately protected or do they share the same auth as public endpoints?
  • Is there privilege escalation risk (e.g., user can change their own role)?
  • Are sensitive admin actions (user deletion, config changes, data export) additionally protected (e.g., re-authentication, 2FA)?
• Authorization Architecture Analysis — map the full permission structure:
  1. Identify all user roles/levels in the system (admin, moderator, user, guest, etc.)
  2. List all routes/endpoints and their required permission level
  3. Verify each protected route actually checks permissions in the controller/middleware
  4. Look for inconsistencies: routes that should be protected but aren't
  5. Check if authorization is enforced at the controller level AND the data access level (not just one)

Infrastructure & Configuration

• Security Headers Missing — no CSP, X-Frame-Options, HSTS, X-Content-Type-Options
• Insecure Dependencies — (covered in Step 2, cross-reference here)
• Debug Mode in Production — (covered in Step 4)

How to Scan

1. Read route/controller files — these are where user input enters the application
2. Search for dangerous function calls — use web search for "[language] dangerous functions security" to get a current list for the project's language
3. Check middleware/interceptors — are security middlewares (auth, CSRF, rate limiting) applied?
4. Review data model definitions — check for mass assignment protection
5. Search for regex patterns — hardcoded secrets, http:// URLs, eval(), exec(), etc.
6. Check authentication flows — login, registration, password reset, session management
7. Map the authorization structure — identify all roles, list all protected routes, verify each one actually enforces permissions. Look for admin panels, dashboards, and privileged endpoints. Cross-check that every sensitive route has both authentication AND authorization checks.

For each finding, note:

• Exact file and line number
• What the vulnerability is
• What an attacker could do (impact)
• The specific fix for this codebase (not generic advice)

---

Step 4: Configuration Scan

Check for common security misconfigurations in project and deployment files.

4.1 .env Files Committed to Git

# Check if .env is tracked by git
git ls-files --error-unmatch .env 2>/dev/null
# Check if .env is in .gitignore
grep -q '\.env' .gitignore 2>/dev/null

• Finding: .env file is tracked in the repository.
• Severity: CRITICAL
• Fix: Remove from tracking with git rm --cached .env, add .env to .gitignore, and rotate any secrets that were committed.

4.2 Debug Mode in Production

Search for debug/development settings that should be disabled in production. Use web search for "[framework name] debug mode production security" to find the specific settings for the detected framework.

Common patterns to look for:

• Debug flags set to true in config files
• Verbose error pages that expose stack traces
• Source maps exposed in production builds
• Missing security middleware (e.g., security headers)
• Development-only endpoints still accessible

4.3 Insecure HTTP

Search for hardcoded http:// URLs in configuration and source code that should use https://:

• API endpoint URLs
• Webhook URLs
• OAuth redirect URIs
• CDN resource links
• Cookie settings without Secure flag

Patterns to flag:

http://[^localhost][^\s"']*   # http:// to non-localhost targets
secure:\s*false               # cookie secure flag disabled
SameSite.*None.*(?!Secure)    # SameSite=None without Secure

Exclude: http://localhost, http://127.0.0.1, http://0.0.0.0 (local development URLs).

---

Step 5: Report

After completing Steps 1-4, compile all findings into a single severity-sorted report.

Severity Levels

Level	Meaning
CRITICAL	Exploitable vulnerability — immediate action required (e.g., SQL injection, hardcoded production secrets)
HIGH	Serious risk — should be fixed before deploy (e.g., XSS, command injection, known CVE in dependency)
MEDIUM	Defense gap — should be addressed soon (e.g., missing CSRF, permissive CORS)
LOW	Best-practice violation — fix when convenient (e.g., debug mode, missing security headers)
INFO	Observation — no immediate risk (e.g., outdated dependency with no known vuln)

Report Format

Sort findings by severity (CRITICAL first, INFO last). Use this format for each finding:

[CRITICAL] SQL Injection — src/api/users.ts:42
  Issue: User input directly concatenated into SQL query
  Impact: Attacker can read/modify/delete database data
  Fix: Use parameterized queries

[HIGH] Known Vulnerability in lodash@4.17.15 — package.json
  Issue: CVE-2021-23337 — prototype pollution via template function
  Impact: Remote code execution possible
  Fix: Upgrade to lodash@4.17.21

[MEDIUM] CORS Misconfiguration — src/app.ts:12
  Issue: Access-Control-Allow-Origin set to wildcard with credentials
  Impact: Any website can make authenticated requests to this API
  Fix: Restrict origin to specific allowed domains

[LOW] Debug Mode Enabled — src/index.ts:8
  Issue: Express running without helmet middleware
  Impact: Missing security headers (X-Frame-Options, CSP, etc.)
  Fix: Install and configure helmet middleware

Summary Section

End the report with a summary:

=== Security Scan Summary ===
  CRITICAL: X
  HIGH:     X
  MEDIUM:   X
  LOW:      X
  INFO:     X
  Total:    X findings

---

Step 6: Fix Offering

After presenting the report, offer the user interactive fix options:

How would you like to proceed?
  1. Fix all — apply fixes for all findings automatically
  2. Critical only — fix only CRITICAL and HIGH severity issues
  3. One-by-one — review and approve each fix individually
  4. Manual — I will fix these myself (no changes)

For each fix:

1. Show the exact code change (diff preview) before applying.
2. Wait for user confirmation before modifying any file.
3. For dependency vulnerabilities, show the upgrade command and any breaking change notes.
4. After applying fixes, re-run the relevant check to confirm the issue is resolved.

---

Step 7: Safety Rules

These rules apply throughout the entire scan. Never violate them.

1. Advisory, not exhaustive. This scan checks for common patterns. It is not a replacement for a professional penetration test or a dedicated SAST/DAST tool. Always tell the user this at the end of the report.
2. Mask secrets in the report. If a hardcoded secret is found, display only the first 4 and last 4 characters (e.g., sk-p...i789). Never print a full secret in the report output.
3. Never auto-fix without confirmation. Every code change must be previewed and explicitly approved by the user — even if the user selected "Fix all" mode, show what will change before applying.
4. Do not install tools without asking. If an audit tool (e.g., pip-audit, govulncheck) is not installed, ask the user before installing it.
5. Preserve existing functionality. Fixes must not change application behavior beyond closing the security gap. If a fix might alter behavior, warn the user.
6. Do not exfiltrate code or data. All analysis runs locally. Never send code to external services or APIs.
7. Scope to project boundaries. Only scan files within the project directory. Do not access system files or other projects.