Most SAST tools fail on the second run
The first scan is easy. The problem is the hundredth, once suppressions have gone stale, test fixtures dominate the report, and nobody remembers why a rule fires.
Every rule carries CWE, CAPEC, a MITRE technique and a CWSS vector, so the scoring is a published method rather than a vendor number.
Suppressions are anchored to the snippet they were written for, so they relocate when code moves and deactivate when the snippet is gone.
Test suites are detected from path conventions, test configuration and manifest dependencies, so a hardcoded value in a fixture is graded differently from one in production code.
Load external packs with --rule, point at a self-hosted registry with --rule-registry, run one rule with --rule-id, or drop the built-in corpus entirely.
SARIF 2.1.0, with the snippet that caused it
Findings land in .vulnetix/sast.sarif, which GitHub code scanning, GitLab, your editor and every SARIF viewer already understand. Snippet width is set with --snippet-context, including turning snippets off when the report travels somewhere source should not.
What this command does not do
It runs source rules only. Secrets, container and infrastructure rules are their own commands and their own rule kinds, so a SAST run costs what a SAST run should. Rules that cannot apply to a file are skipped by language before evaluation. Detection is conservative: a missed finding is preferred over a wrong one, and absence of a finding is not verified absence of a weakness.
The same Rego engine runs secrets detection, container build file rules and infrastructure as code rules. One engine, one SARIF, four rule kinds.