What SAST actually does
A SAST engine parses source files into an abstract syntax tree (AST), then applies rules against that tree: pattern matches for known-dangerous function calls, taint tracking that follows a value from an untrusted source (a request parameter, a form field) to a dangerous sink (a SQL query, a shell command, a file path), and in more advanced engines, cross-file dataflow that connects a source in one file to a sink in another. Nothing executes. This is what makes SAST usable before a single test environment exists — it runs on a laptop, in a CI job, or against a codebase that has never been deployed.
SAST vs DAST vs IAST vs SCA
These four acronyms get used interchangeably in vendor marketing. They test different things, at different stages, and none of them replaces the others.
| Category | When it runs | What it finds |
|---|---|---|
| SAST | Before build — on source code | Vulnerability patterns in code: injection, hardcoded secrets, insecure crypto, unsafe deserialization. |
| DAST | Against a running application | Runtime behavior: how the app actually responds to crafted HTTP requests, auth bypass, misconfigured headers. |
| IAST | During test execution, instrumented | A hybrid — observes real code paths as tests run, combining source visibility with runtime confirmation. |
| SCA | Against the dependency tree | Known CVEs in third-party libraries — not your code, code you imported. |
A mature security program layers more than one of these. SAST is usually the first layer because it runs earliest — before there is anything to deploy or attack.
What a SAST tool should actually cover
Not every scanner that calls itself "SAST" covers the same ground. A short, concrete checklist:
- ✅ Standard mapping — findings tagged to CWE at minimum; OWASP Top 10, ISO 27001, ASVS or NIST CSF mapping if you need compliance evidence, not just a severity label.
- ✅ Language coverage that matches your stack — a tool that covers 30 languages but not the one you actually use covers zero of your code.
- ✅ A low enough false-positive rate to be usable — a scanner that floods triage with noise gets ignored within a month, regardless of its raw finding count.
- ✅ A report someone outside the security team can read — a JSON dump is fine for CI gating, useless for handing to an auditor or a client.
- ✅ CI/CD integration — SARIF export, exit codes, or a native Action/pipeline step, so scanning is not a manual step someone forgets.
- ✅ A clear answer to "where does my code go" — cloud-uploaded SAST and offline SAST are different risk profiles, not a footnote. See what offline SAST actually means.
Where StaticCodeAudit fits
StaticCodeAudit is a curated, offline SAST: a standalone binary that scans 8 languages (Python, JavaScript/TypeScript, HTML, Java, C#, PHP, YAML, Dockerfile) against 708 rules, all mapped to at least CWE, with ISO 27001 Annex A, OWASP ASVS v5.0, WCAG 2.1 and NIST CSF 2.0 matrices built in — not assembled after the fact. It never uploads source code anywhere; the whole scan runs on the machine that runs the binary.
Frequently asked questions
Does SAST replace manual code review or penetration testing?
No. SAST is fast, repeatable, and catches known pattern classes at scale — it will not catch a business-logic flaw a human reviewer would spot ("this API lets any user cancel any other user's order"), and it does not confirm exploitability the way a penetration test against a running system does. It is one layer, usually the first and cheapest one to run.
How many false positives should I expect?
It depends entirely on the engine and the rule design — there is no universal number, and any vendor quoting one without a named benchmark is guessing. Ask for a published, reproducible benchmark (OWASP Benchmark, NIST Juliet, or similar) with precision/recall/F1 per category, not a single aggregate "accuracy" figure. See how this is measured on the language benchmarks page.
Is a linter the same thing as SAST?
No, though they overlap in mechanism. A linter (ESLint, Pylint, RuboCop) mostly checks style and basic correctness bugs. SAST rules specifically target exploitable vulnerability classes — injection, deserialization, hardcoded secrets, cryptographic weaknesses — and are generally mapped to CWE so findings are traceable to a known weakness taxonomy.
Does SAST need internet access to run?
Not inherently — that is a deployment choice by the vendor, not a requirement of static analysis itself. Cloud SAST products upload your source code to run the analysis remotely; offline SAST products run the entire analysis, including rule evaluation, on your own machine. See what offline SAST actually means and how to verify it.
What does "708 rules" actually mean in practice?
It means 708 individually maintained detection patterns, each mapped to at least one CWE, spanning categories like security (injection, secrets, crypto), architecture, dependencies, CI/CD pipeline config, and more. The number by itself says little without knowing the mapping and the measured detection rate per rule — which is why StaticCodeAudit publishes both the full standards mapping and real precision/recall benchmarks instead of just the count.
See a real SAST report, not a mockup
Open the live demo report — generated on a real codebase, all charts interactive, full CWE/ISO/ASVS/WCAG mapping included.
Open the live report Read the offline SAST guide