Static Analysis

Security Notice

AUTHORIZED USE ONLY: These skills are for DEFENSIVE security analysis and authorized research:

• Authorized security assessments with written permission
• Code review and quality assurance
• CI/CD pipeline integration for automated security scanning
• Compliance validation (SOC2, HIPAA, PCI-DSS)
• Educational purposes in controlled environments

NEVER use for:

• Scanning systems without authorization
• Exploiting discovered vulnerabilities without disclosure
• Circumventing security controls
• Any illegal activities

Step 1: Environment Assessment

Before running any analysis, assess the target:

# Identify languages in the project
find . -type f -name "*.js" -o -name "*.ts" -o -name "*.py" -o -name "*.java" -o -name "*.go" -o -name "*.c" -o -name "*.cpp" -o -name "*.cs" -o -name "*.rb" | head -20

# Check for existing CodeQL database
ls -la .codeql/ 2>/dev/null || echo "No CodeQL database found"

# Check for existing Semgrep config
ls -la .semgrep.yml .semgrep/ 2>/dev/null || echo "No Semgrep config found"

# Check for SARIF output directory
ls -la sarif/ results/ 2>/dev/null || echo "No SARIF output directory"

Step 2: CodeQL Analysis

Database Creation

# Create CodeQL database for JavaScript/TypeScript
codeql database create codeql-db --language=javascript --source-root=.

# Create CodeQL database for Python
codeql database create codeql-db --language=python --source-root=.

# Multi-language database
codeql database create codeql-db --language=javascript,python --source-root=.

Running Queries

# Run standard security queries
codeql database analyze codeql-db \
  --format=sarifv2.1.0 \
  --output=results.sarif \
  codeql/javascript-queries:Security

# Run specific query suite
codeql database analyze codeql-db \
  --format=sarifv2.1.0 \
  --output=results.sarif \
  codeql/javascript-queries:codeql-suites/javascript-security-and-quality.qls

# Run custom query
codeql database analyze codeql-db \
  --format=sarifv2.1.0 \
  --output=results.sarif \
  ./custom-queries/

Key CodeQL Query Packs

Step 3: Semgrep Analysis

Running Semgrep

# Run with default rules (auto-detect language)
semgrep scan --config=auto --sarif --output=semgrep-results.sarif

# Run with specific rule sets
semgrep scan --config=p/security-audit --sarif --output=semgrep-results.sarif

# Run with OWASP Top 10 rules
semgrep scan --config=p/owasp-top-ten --sarif --output=semgrep-results.sarif

# Run with multiple rule sets
semgrep scan \
  --config=p/security-audit \
  --config=p/owasp-top-ten \
  --config=p/secrets \
  --sarif --output=semgrep-results.sarif

# Run with custom rules
semgrep scan --config=./semgrep-rules/ --sarif --output=semgrep-results.sarif

Key Semgrep Rule Sets

Step 4: SARIF Output Processing

SARIF Structure

{
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/main/sarif-2.1/schema/sarif-schema-2.1.0.json",
  "version": "2.1.0",
  "runs": [{
    "tool": {
      "driver": {
        "name": "CodeQL",
        "rules": [...]
      }
    },
    "results": [{
      "ruleId": "js/sql-injection",
      "level": "error",
      "message": {
        "text": "This query depends on a user-provided value."
      },
      "locations": [{
        "physicalLocation": {
          "artifactLocation": { "uri": "src/api/users.js" },
          "region": { "startLine": 42, "startColumn": 5 }
        }
      }]
    }]
  }]
}

Parsing SARIF Results

# Count findings by severity
jq '[.runs[].results[] | .level] | group_by(.) | map({level: .[0], count: length})' results.sarif

# List critical/error findings
jq '.runs[].results[] | select(.level == "error") | {rule: .ruleId, file: .locations[0].physicalLocation.artifactLocation.uri, line: .locations[0].physicalLocation.region.startLine, message: .message.text}' results.sarif

# Export findings to CSV
jq -r '.runs[].results[] | [.ruleId, .level, .locations[0].physicalLocation.artifactLocation.uri, .locations[0].physicalLocation.region.startLine, .message.text] | @csv' results.sarif > findings.csv

Step 5: Triage and Reporting

Severity Classification

False Positive Assessment

For each finding, evaluate:

1. Data flow: Does user-controlled data actually reach the sink?
2. Sanitization: Is input validated/sanitized before use?
3. Context: Is the vulnerable pattern in test code or production?
4. Reachability: Can the vulnerable code path be triggered?
5. Impact: What is the actual exploitability?

Report Template

## Static Analysis Report

**Date**: YYYY-MM-DD
**Tools**: CodeQL vX.X, Semgrep vX.X
**Scope**: [project/directory]

### Summary

| Severity | Count | Fixed | False Positive | Remaining |
| -------- | ----- | ----- | -------------- | --------- |
| CRITICAL | X     | X     | X              | X         |
| HIGH     | X     | X     | X              | X         |
| MEDIUM   | X     | X     | X              | X         |
| LOW      | X     | X     | X              | X         |

### Critical Findings

1. **[Rule ID]**: [Description]
   - File: [path:line]
   - Impact: [description]
   - Remediation: [code fix]

### Recommendations

- [Prioritized list of actions]

Step 6: CI/CD Integration

GitHub Actions Integration

name: Static Analysis
on: [push, pull_request]
jobs:
  codeql:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v3
        with:
          output: sarif-results
          upload: true

  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/owasp-top-ten
          generateSarif: '1'
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

OWASP Mapping

Related Skills

• variant-analysis - Pattern-based vulnerability discovery across codebases
• semgrep-rule-creator - Custom Semgrep rule development
• differential-review - Security-focused diff analysis
• insecure-defaults - Hardcoded credentials and fail-open detection
• security-architect - STRIDE threat modeling and OWASP Top 10
• code-analyzer - Code metrics and complexity analysis

Agent Integration

• security-architect (primary): Security assessments and threat modeling
• code-reviewer (secondary): Automated code review augmentation
• penetration-tester (secondary): Vulnerability verification
• qa (secondary): Quality gate enforcement

Iron Laws

1. NEVER deploy to production without running both Semgrep and CodeQL analysis
2. ALWAYS create a fresh CodeQL database — stale databases miss recently added code
3. NEVER suppress a finding without documenting the false positive rationale in a code comment
4. ALWAYS block on CRITICAL/HIGH findings in CI/CD; never merge with unresolved critical issues
5. NEVER run analysis on test/fixture directories — always exclude non-production code paths

Anti-Patterns

Memory Protocol (MANDATORY)

Before starting: Read .claude/context/memory/learnings.md

After completing:

• New pattern -> .claude/context/memory/learnings.md
• Issue found -> .claude/context/memory/issues.md
• Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: If it's not in memory, it didn't happen.

Snyk + Semgrep MCP Integration

When Snyk MCP server is configured, call directly:

• snyk_test_project — dependency vulnerability report with CVSS scores
• snyk_code_test — SAST scan (OWASP Top 10 patterns)
• snyk_iac_test — IaC security issues (Terraform, K8s, Helm)
• snyk_monitor — enroll project for continuous monitoring

When semgrep/mcp server is configured:

• semgrep_scan — run rule registry against codebase
• semgrep_search — semantic code pattern search

Combined Security Pipeline

semgrep scan --config=auto --json > .claude/context/tmp/semgrep.json
snyk test --json > .claude/context/tmp/snyk.json