Deduplicated
Hits with the same fingerprint, or the same file, line and rule, collapse to one finding. Agreement between tools becomes a corroborating edge, not a second row.
SAST that follows
the full flow.
Follow untrusted input through your code with static application security testing. See the path from source to sink, with evidence your developers can act on.
checkout/handler
request.query
order.lookup(input)
database.execute(query)
Investigation context
01 / Trace input
Where does untrusted data enter?
- Entry point
- Call path
Follow the input through functions instead of reviewing an isolated pattern match.
02 / Inspect the sink
See the operation that needs review.
- Source location
- Sink operation
Keep the source location and data-flow evidence together for developer investigation.
03 / Decide the fix
Give the developer a verifiable path.
- Finding record
- Disposition reason
Review the finding, propose a change and retain a reason for any disposition.
12
Native taint analysers
One per language, from C to Swift.
Cross-file
Project-wide taint
Flows resolved through imports.
Reason
Governed suppression
A bare
nosec suppresses nothing.SARIF
In and out
Import other tools; annotate pull requests.
The category
What is SAST?
SAST reads code, not a running application, so it can run on every pull request before anything is deployed. Its weakness is noise: a pattern match on a dangerous function call fires whether or not attacker-controlled data ever reaches it. Taint analysis narrows that by tracking data flow, and the quality of a SAST tool is mostly how well it follows that flow across functions and files, and how honestly it credits sanitisers. See the SAST glossary entry for how the term is used across this site.
SecurityVault goes further than the flow. Each taint finding lands on one graph that runs from code to build artifact to cloud workload, so you can see whether the vulnerable handler ships in an image that is running today. A fail-closed gate stops it before merge, and the source-to-sink path is kept as evidence. Developers get fewer findings they can verify; AppSec gets a gate it can defend.
Untrusted input
Follow the value entering a handler.
Sensitive operation
Inspect the call path into the sink.
Application relationship
Keep the source reference with the affected build.
A source match starts an investigation; evidence establishes the context.
How SecurityVault does it
How does SecurityVault run SAST?
Native engine
The native engine runs 12 per-language taint analysers inside one isolated scanner. Supported language models follow flows across functions and files, helping developers inspect the connection between an input source and a sensitive operation. Coverage varies by language and framework.
Precision
Constant propagation follows simple assignments, so
DEBUG = True fifty lines above app.run(debug=DEBUG) still counts. In the JavaScript and TypeScript model a sanitiser clears only the sink category it actually neutralises: an HTML escaper does not clear a SQL injection.Open source
semgrep and bandit run on every repository scan by default. Language bundles add the per-language tools: gosec, brakeman, SpotBugs with Find Security Bugs, njsscan, eslint-security, cppcheck, flawfinder, clippy and graudit.
Custom rules
Rule packs with a typed schema, validated strictly at load and testable against sample code.
Imports
SARIF from tools you already run is imported into the same model. File paths from an imported report are sanitised: traversal, absolute paths and drive prefixes are rejected.
After the scan
What happens to a SAST finding?
It becomes one node on the same graph as your dependencies, images and workloads, tied to the commit it was found in.
Finding
affects
Repository
contains
Commit
triggered
Build
produces
ContainerImage
runs_image
Workload
01
02
Correlated
Source findings can be reviewed alongside dependency and API-route context. These relationships help prioritise investigation; a static match alone does not prove that a vulnerable function executes or that an attack succeeds.
03
Explained
Each taint finding exposes its source-to-sink path. Remediation comes from deterministic templates first; AI assistance is offered only where a rule family opts in.
Gates
Can SAST findings block a merge?
Yes, and the gate fails closed. A pull-request or pipeline gate evaluates the scan's findings against your severity threshold and organisation policies. A scan that times out or fails is a deny, not a pass, and an evaluator error is a deny. Results go back to the pull request as SARIF and annotated comments through a per-organisation rate limit. From a pipeline, esos --fail-on high ci scan exits non-zero on a policy failure and with a different code on an API error, so an outage is never mistaken for a clean result. See deployment gates, the CLI reference and why severity counts alone make weak gates.
Evidence
Does SAST count as evidence for an audit?
Yes. Every SAST finding carries its CWE identifier and is recorded as static-analysis evidence when your controls are evaluated, and an open critical or high finding shows as a gap against the controls it touches. The cross-walk maps that evidence across 6 seeded framework catalogues, including SOC 2, ISO 27001 and PCI DSS, so the secure-development controls in your own audit are backed by scan records rather than screenshots. See continuous compliance.
FAQ
Frequently asked questions about SAST
- Which languages does the native SAST engine cover?
- 12 languages have a native taint analyser: C, C++, C#, Go, Java, JavaScript and TypeScript, Kotlin, PHP, Python, Ruby, Rust and Swift. Open-source tools such as semgrep cover the long tail alongside it.
- Do I have to choose between the native engine and semgrep?
- No. A repository scan runs the native engine and the open-source adapters in the same scan. Where they agree, the results resolve to one logical finding with a corroborates edge rather than two rows.
- How do I suppress a false positive?
- Inline, with an sv-ignore annotation that carries a written reason; nosec and nosemgrep with a reason are honoured by default. A bare marker suppresses nothing, and every suppression is recorded with its rule, path, line and reason. In the platform, a disposition such as false positive is a human verdict with a mandatory reason code.
- Is my source code safe while it is scanned?
- The scanner runs isolated from the rest of the platform and holds no platform credentials. Results come back only through an authenticated, signed ingestion path, so a tampered result is rejected rather than recorded.
- Can I write my own SAST rules?
- Yes. Custom rule packs are YAML or JSON documents validated strictly at load: unknown fields, bad regular expressions and invalid severities are rejected, so a broken rule never runs silently. Each rule can be tested against sample code before you rely on it.
SAST is strongest beside the scans that share its graph: dependency reachability with SCA, secrets detection on the same checkout, and DAST findings matched by route. Built for AppSec teams and developers fixing in the pull request. Weighing options? Read software composition analysis, or start with the quickstart.
From the blog
Further reading
- SAST remediation: write tests that protect the fixTurn a SAST finding into a focused remediation test that checks the dangerous data flow, preserves valid behaviour and catches future regressions.
- SAST vs SCA vs secrets scanning: what each one catchesSAST vs SCA vs secrets scanning compared: what each inspects, what it misses, when it should run and who fixes its findings, with one shared example.
- Reducing SAST false positives without hiding real bugsReduce SAST review noise with better rules, reachability context and reason-coded triage, while keeping real weaknesses visible for reassessment.
- SAST taint analysis explained: sources, sinks, sanitisersLearn how SAST taint analysis traces untrusted input from source to sink, why it beats pattern matching on noise, and where its blind spots are.
See it on your stack
Bring one repository.
One scan, the native engine and the open-source tools together, and a source-to-sink path on a real finding.