How do I install the Sast Scan skill?

Run npx skillmds@latest add aibot88/sast-scan in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Sast Scan safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sast Scan?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Sast Scan free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Sast Scan?

aibot88 (@aibot88) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sast Scan by aibot88 — Agent Skill

Name: Sast Scan
Rating: 4.2 (5 reviews)
Author: aibot88

Sast Scan

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.

aibot88 Updated Sep 9, 2026 3 repo stars

File contents

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

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.

---name: sast-scandescription: 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.--- # 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`](../_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/`](../_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 ```bash 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`: ```bash 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.

Frequently asked questions