Sast Orchestration

SAST Orchestration

This skill runs multiple static-analysis tools against a codebase, authors custom detection rules, ingests SARIF, and performs high-signal triage. The headline capability is triage: converting raw, noisy SAST output into a ranked list of exploitable findings — where frontier reasoning models outperform traditional tools.

When to Use

• Scan a codebase for security vulnerabilities (first-party or third-party).
• Write a custom Semgrep rule or CodeQL query from a CVE advisory, patch diff, or sink spec.
• Triage and rank a pile of SAST findings (SARIF or tool-native JSON) by exploitability.
• Reduce false-positive noise from existing scans.
• Integrate SAST into GitHub Actions / GitLab CI / Bitbucket Pipelines / Jenkins.
• Aggregate and deduplicate findings across multiple SAST tools.
• Decide which SAST tool(s) fit a given language/framework.

Trigger Phrases

• "scan this code for vulnerabilities"
• "write a Semgrep rule to detect ..."
• "write a CodeQL query for ..."
• "triage these SAST findings" / "rank these by exploitability"
• "convert this CVE into a detection rule"
• "set up SAST in CI" / "add security scanning to our pipeline"
• "reduce false positives in this scan"
• "aggregate SARIF from multiple tools"

When NOT to Use This Skill

• Dependency/package CVEs (SBOM, transitive vulns, license) → use sca-security.
• Runtime/dynamic testing (HTTP fuzzing, auth bypass, DAST) → use dast-automation.
• Container image scanning (OS packages, base image CVEs) → use container-security.
• IaC misconfiguration (Terraform, CloudFormation, Kubernetes YAML) → use iac-security.
• Mobile app binary scanning (APK, IPA) → use android-pentest / ios-pentest.
• LLM/prompt-injection scanning → use llm-security.
• Threat modeling (architecture-level risk analysis) → use threat-modeling.

SAST = source code static analysis. If the artifact is not source, check a sibling skill first.

Decision Tree

Incoming request
│
├── "write a rule"         → workflows/custom_semgrep_from_cve.md  (from CVE/advisory)
│                            workflows/custom_codeql_from_sink.md  (from sink spec)
│
├── "triage these findings"→ workflows/triage.md                   [MAX THINKING]
│
├── "scan this codebase"   → workflows/multi_tool_scan.md          (parallel fan-out)
│                            then workflows/triage.md
│
├── "too much noise"       → workflows/false_positive_reduction.md
│
├── "SAST in CI"           → workflows/cicd_integration.md
│
└── "which tool for X?"    → references/<tool>.md (selection matrix below)

Tool-picking rules of thumb:

Parallelism Hints

Independent (run concurrently):

• Semgrep, Bandit, gosec, Brakeman, ESLint-security, Gitleaks — all source-only, read-only; fan out fully.
• CodeQL database create across distinct languages — independent.
• CodeQL database analyze across distinct language databases — independent.
• Per-tool sub-agents scanning the same codebase — each writes to a distinct SARIF path.

Sequential (hard dependency):

• CodeQL database create → database analyze for the same language.
• SpotBugs requires mvn compile / gradle build to have produced classes first.
• Aggregation and triage wait for all per-tool scans to complete — do NOT start triage with partial SARIF.

See workflows/multi_tool_scan.md for the reference orchestration.

Sub-Agent Delegation

Pattern: one sub-agent per tool for scanning; one aggregator/triage agent downstream.

• Per-tool scan agent: context-minimal, just runs <tool> and reports SARIF path + count. Minimal thinking.
• Aggregator agent: reads all SARIF, normalizes to schemas/finding.json, deduplicates by (cwe, file, ±3 lines).
• Triage agent: consumes deduped findings, annotates with reachability, exploitability rank, and fix suggestions. Maximum thinking.

Do not pool tool-specific expertise into one mega-agent — it collapses parallelism and exhausts context.

Reasoning Budget

Allocate extended thinking deliberately — not uniformly.

Headline: extended thinking pays off most on triage. This is the single biggest win over traditional SAST tools. Do not rush per-finding analysis.

Structured Output

All findings — regardless of source tool — conform to schemas/finding.json. Key fields include tool, rule_id, cwe, file_path, line, column, snippet, confidence, exploitability_rank (1-5), is_reachable, taint_source, taint_sink, taint_flow, is_false_positive, fp_reason, remediation, fix_suggestion.

Use SARIF 2.1.0 for tool-native emission; convert to the finding schema during aggregation. See references/sarif_format.md.

Workflow Index

References Index

Examples Index

Scripts

Tools

Last Validated

2026-04. Minimum versions tested: Semgrep 1.60, CodeQL CLI 2.17, Bandit 1.8, gosec 2.20, Brakeman 6.2, SpotBugs 4.8 + FSB 1.13, ESLint 9.