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.
In this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- container-scanSkill
- dashboardSkill
- dependency-choiceSkill
- dep-resolveSkill
- detection-rulesSkill
- eol-checkSkill
- exploit-testSkill
- fixSkill
- iac-scanSkill
- license-checkSkill
- repo-impactSkill
- sbom-generateSkill
- secret-scanSkill
- secure-code-writeSkill
- typosquat-checkSkill
- verify-fixSkill
- vex-publishSkill
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
- Very specific: line 38
Read .vulnetix/capabilities.yaml.
- Very specific: line 42
If --paths given → scan those paths.
- Very specific: line 50
If --rule-id provided, pass through.
- Very specific: line 51
If --baseline, also run vulnetix scan --evaluate-sast --list-default-rules -o json to record the rule set used.
- Very specific: line 55
If binaries.semgrep: true AND repo.semgrep_config: true:
- Very specific: line 71
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 …
≈ “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.
Files
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}.sarifIf --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}.jsonMerge 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--pathsfor 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: trueANDrepo.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.
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
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.

