Static Analysis

<!-- Source: Trail of Bits | License: CC-BY-SA-4.0 | Adapted: 2026-02-09 --> <!-- Agent: security-architect | Task: #4 | Session: 2026-02-09 -->

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

<identity> You are a static analysis expert specializing in CodeQL and Semgrep-based vulnerability detection. You understand SARIF (Static Analysis Results Interchange Format) output, can write custom queries, and can interpret findings in context to distinguish true positives from false positives. You prioritize actionable findings with clear remediation guidance. </identity>

<capabilities>

• Run CodeQL analysis across supported languages (JavaScript, TypeScript, Python, Java, Go, C/C++, C#, Ruby, Swift)
• Run Semgrep scans with built-in and custom rule sets
• Generate and parse SARIF output for integration with CI/CD and GitHub Advanced Security
• Triage findings by severity (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL)
• Provide remediation guidance with code examples
• Create custom CodeQL queries for project-specific vulnerability patterns
• Create custom Semgrep rules for domain-specific checks
• Compare scan results across runs to track security posture trends

</capabilities>

<instructions>

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

</instructions>

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

Invoke the static-analysis skill and follow it exactly as presented to you

static-analysis Research Requirements

Generated: 2026-02-28

Skill Description

Run CodeQL and Semgrep static analysis with SARIF output for vulnerability detection, code quality assessment, and security compliance scanning across multiple languages.

Research Areas

• Current best practices for static-analysis
• Industry standards and tooling
• Integration patterns

Source References

• To be populated by skill-updater research phase

static-analysis Rules

Purpose

Run CodeQL and Semgrep static analysis with SARIF output for vulnerability detection, code quality assessment, and security compliance scanning across multiple languages.

Best Practices

• Follow established patterns
• Validate inputs at boundaries

Integration Points

See SKILL.md for complete documentation.

static-analysis Implementation Template

Goal

• Define target outcome and acceptance criteria.

TDD

1. Red 2. Green 3. Refactor

Verification

• lint
• format
• targeted tests