agentleFS
VulnetixVulnetix/pix-ai-coding-assistant/skills/sast-scan/SKILL.md

sast-scan

Skill9 starsChanged 6 days agoApache-2.0View on GitHub

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.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 0 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .vulnetix/capabilities.yaml.

    line 38
  2. Very specific:

    If --paths given → scan those paths.

    line 42
  3. Very specific:

    If --rule-id provided, pass through.

    line 50
  4. Very specific:

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

    line 51
  5. Very specific:

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

    line 55
  6. Very specific:

    If running on a PR / branch, write a .vulnetix/sast/<branch>.summary.yaml with finding counts so the pr-security-reviewer agent can pick it …

    line 71

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 scan --sca.
  • Secret detection — use secret-scan.
  • Container/IaC scanning — use container-scan / iac-scan.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

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 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 the pr-security-reviewer agent 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.