sast-scan

name	sast-scan
description	Static application security testing (SAST) for changed source files — Vulnetix's built-in rule set plus optional Semgrep augmentation when `.semgrep` config is present. Use when reviewing a PR for code-level vulnerabilities, scanning a feature branch before merge, gating CI on critical findings, or running rule-specific checks for a known weakness class.
argument-hint	[--rule-id ID] [--paths file1 file2] [--baseline]
user-invocable	true
allowed-tools	Bash, Read, Glob, Grep, Edit, Write
model	sonnet
triggers	["sast","static analysis","scan source"]
chain	["secure-code-write","verify-fix"]
outputBudget	medium
cooldown	per-session

Vulnetix SAST Skill

Use when

• Pre-commit / pre-merge: scan changed source files for SAST findings.
• Targeted rule check: "did we just write an XXE pattern?" via --rule-id VNX-XXE-001.
• CI gate: exit non-zero if SAST finds critical-severity issues.
• Audit a specific weakness class with --paths <dir> --rule-id VNX-CWE-89-*.
• Augment Vulnetix's rules with the repo's own Semgrep policy.

Don't use for

• Dependency vulnerability scanning — use /vulnetix:sca-scan.
• Secret detection — use /vulnetix:secret-scan.
• Container/IaC scanning — use /vulnetix:container-scan / /vulnetix:iac-scan.

Conventions

This skill follows _lib/contract.md: the Vulnetix CLI is auto-installed by hooks, .vulnetix/capabilities.yaml is always present, every vulnetix vdb call is piped through a verified jq filter from _lib/jq/, independent calls run in parallel as concurrent Bash tool calls, and trailing follow-ups are limited to one line. See the contract for output style, memory write rules, and cooldowns.

Static analysis on source code. Capability-aware: optionally augmented with the user's own Semgrep rules.

Step 1: Load capabilities

Read .vulnetix/capabilities.yaml. Note binaries.semgrep, repo.semgrep_config.

Step 2: Decide scope

If --paths given → scan those paths. Else scan files changed since git merge-base origin/main HEAD (or whole repo if not a git repo).

Step 3: Run scan

vulnetix sast --paths "$PATHS" -o json-sarif > .vulnetix/sast.${TIMESTAMP}.sarif

If --rule-id provided, pass through. If --baseline, also run vulnetix scan --evaluate-sast --list-default-rules -o json to record the rule set used.

Step 4: Augment with local Semgrep (conditional)

If binaries.semgrep: true AND repo.semgrep_config: true:

semgrep --config .semgrep --json --quiet "$PATHS" > .vulnetix/sast.semgrep.${TIMESTAMP}.json

Merge findings into the SARIF report (de-duped by file:line:rule).

Step 5: Render

| Severity | Rule | File:Line | Message | Source |

Group by severity (critical → low). Suggest /vulnetix:secure-code-write for repeated rule violations.

Memory update

If running on a PR / branch, write a .vulnetix/sast/<branch>.summary.yaml with finding counts so /vulnetix:code-review-security can pick it up.

Edge cases & gotchas

• Scope defaults to files changed vs origin/main; pass --paths for explicit scope. CWD without a manifest = empty results.
• Output is SARIF — pipe through a SARIF viewer (VS Code SARIF Viewer extension) or render the JSON yourself.
• Semgrep augmentation requires binaries.semgrep: true AND repo.semgrep_config: true. Otherwise the skill silently runs Vulnetix rules only.
• Built-in rules are organisation-agnostic; rule IDs like VNX-GQL-004 (GraphQL injection) are not customisable per-repo.
• Findings are deduped by <file>:<line>:<rule_id> across both sources — same logical finding from Semgrep + Vulnetix appears once.
• Performance: 10K+ file repos benefit from --paths "src/**/*.ts" instead of full-repo scan.