SAST Command Reference

The sast command runs a focused scan that evaluates only SAST (sast-kind) Rego rules against your source files. It is equivalent to running:

vulnetix scan --evaluate-sast --no-sca --no-secrets --no-containers --no-iac --no-licenses

Package vulnerability analysis, license analysis, secret detection, container analysis, and IaC analysis are all disabled. Only general static analysis rules run (not secrets, container, or IaC rules — use vulnetix scan or the relevant specialized command for those).

Credentials are optional. When no credentials are configured the community fallback is used automatically.

Usage

vulnetix sast [flags]

Flags

All flags from vulnetix scan are available except the feature-control flags (--evaluate-*, --no-*). SAST-specific flags are also available:

Examples

# SAST scan of the current directory
vulnetix sast

# Scan a specific directory
vulnetix sast --path /path/to/project

# Break the build on high or critical SAST findings
vulnetix sast --severity high

# List all built-in rules and exit
vulnetix sast --list-default-rules

# Skip built-in rules and load custom rules from GitHub
vulnetix sast --disable-default-rules --rule myorg/custom-rules

# Load additional rules on top of the built-in set
vulnetix sast --rule myorg/extra-rules

# Use a self-hosted registry for custom rules
vulnetix sast --rule myorg/rules --rule-registry https://git.example.com

# Emit SARIF JSON to stdout
vulnetix sast --output json-sarif

# Write SARIF to a file
vulnetix sast --output results.sarif

# Silent when clean
vulnetix sast --results-only

# Suppress findings that live in the test suite
vulnetix sast --suppress-test-code

Test-suite detection

Because the CLI runs inside your repository, it can tell whether a finding lives in test code rather than production code — and does so with far more confidence than a filename guess. Each finding’s file is classified against an exhaustive table of test naming conventions across every supported language (*.test.ts, *_test.py, *_test.go, *Test.java, *_spec.rb, *Tests.cs, *_test.rs, *_test.exs, *Spec.scala, …), and the guess is corroborated with two repo-local signals:

• Test-runner configuration files present on disk — jest.config.js, pytest.ini, pyproject.toml [tool.pytest], phpunit.xml, .rspec, Cargo.toml [dev-dependencies], build.gradle (junit/testng), and many more.
• Test frameworks declared as dev-dependencies in your package-manager manifests (jest in devDependencies, pytest in requirements-dev.txt, rspec in the Gemfile, …).

A path match plus a present config or a declared dependency is recorded as a confirmed attribution. Test-suite findings are:

• tagged in the SARIF result properties (vulnetix/test-suite, vulnetix/test-framework, vulnetix/test-confidence, vulnetix/test-matched-pattern, vulnetix/test-evidence);
• deprioritized to LOW in the backend’s SSVC prioritization (test code is rarely a production attack surface); and
• shown in the Vulnetix app with a TEST badge, an “In test code” metric filter, and a test-suite evidence panel on the finding detail page.

The detected config files are also uploaded as scan environment metadata (path, framework, language, size, SHA-256 — not their contents) and surfaced on the scan’s Test runners detected card.

Pass --suppress-test-code to actively suppress test-suite findings instead of just tagging them — this records an auditable suppression (see Ignore / Suppress) rather than a silent mute.

Output Files

SAST Rule Sub-categories

The sast command runs only rules with kind: sast. For other Rego-based analysis categories:

Exit Codes

Related Commands

• vulnetix scan — Full scan with all features enabled
• vulnetix sca — SCA-only scan
• vulnetix secrets — Secret detection only
• vulnetix containers — Container file analysis only
• vulnetix iac — IaC file analysis only
• SAST Rules Reference — All built-in rule documentation