Code
Injection, unsafe deserialisation, weak cryptography and more, on the line responsible.
Static analysis over your own code, using a rule set compiled into the engine.
What it finds
Command and SQL injection, code injection through eval and its relatives, unsafe deserialisation, path traversal, server-side request forgery, weak or broken cryptography, insecure randomness, missing authentication and authorisation checks, cookie and session mistakes, XML external entities, unsafe reflection, and hardcoded credentials.
Roughly 790 rules across the languages people actually write: JavaScript and TypeScript, Python, Go, Java, C#, Ruby, PHP, Rust, C and C++, Kotlin, Swift, Scala, shell.
When it runs
As you type, debounced so it follows your typing rather than fighting it. This path never touches the network: the rules are compiled into the engine and evaluated locally.
Test code is treated differently
A hardcoded credential in a test fixture is not the same finding as one in production code, and a tool that cannot tell the difference trains people to ignore it.
Findings in test files are tagged with the detected framework and language. vulnetix.sast.suppressTestCode removes them entirely if you would rather not see them at all.
Suppressing a finding
Three ways, in increasing scope.
One line. A nosec comment, in the comment syntax of the language:
const result = eval(expr); // nosec
One rule on one line, leaving other findings on that line intact:
subprocess.check_output(cmd, shell=True) # nosec VNX-0315
A whole file, with nosec on line 1.
The syntax is gosec-compatible, so existing suppressions in Go projects are already understood.
For anything you want tracked rather than silently hidden, use Vulnetix: Suppress instead. That records the reason, who suppressed it and when, optionally with an expiry, and syncs to your organisation so the decision is visible rather than buried in a comment.
Custom rules
Rule packs can be added from a git repository:
{ "vulnetix.sast.rules": ["your-org/security-rules"] }
This setting is machine-scoped on purpose. A rule pack is code that the engine executes, so a cloned repository must not be able to introduce one through its committed .vscode/settings.json.