Skip to main content

SAST - Static Application Security Testing

Path: /code/sast · Sidebar: Testing → Code Security → SAST

SAST analyses source code without running it, tracing how untrusted input flows to dangerous operations. apPosture combines its own taint engine with several open-source engines and normalises everything into the unified model.

What it detects

  • Injection via taint flow - SQLi, command injection, path traversal, SSRF, XSS - tracked inter-procedurally (across functions) and through common framework entry points.
  • Weak cryptography - weak hashing, weak RNG, bad crypto usage.
  • Trust-boundary violations and other Tier-1 vulnerability classes.
  • Language coverage spans Python, Java, Go, JavaScript/TypeScript, C#, Ruby, PHP and more.

How the taint engine works

The engine identifies sources (request input, superglobals, parameters), follows assignments/transforms, and flags when tainted data reaches a sink (e.g. a SQL query or subprocess call) without sanitisation. It is deliberately careful to avoid false positives - for example it understands that a list argv to subprocess is not shell injection, and only flags getattr/setattr when the attribute name itself is tainted.

Run a SAST scan

  1. From Repositories, pick a repo (or product) and choose Scan.
  2. apPosture clones the source on demand and runs the engines.
  3. Findings appear on this page and roll into Vulnerabilities.

Reading a SAST finding

Each finding shows:

  • Rule & CWE/OWASP mapping.
  • File + function context and the data-flow path from source to sink.
  • A confidence signal (likely real, uncertain, likely false positive).

Multi-engine aggregation

When available, apPosture also runs permissively-licensed engines (e.g. Bandit, Gosec, others) and merges their results - deduplicated - into the same model. In air-gapped environments it falls back to its own built-in rule pack.

Quality & benchmarking

SAST accuracy is measured against the OWASP Benchmark. Improvements target recall (catching more real issues) while controlling false positives from indirection and aliasing.

Reduce noise at the source

Most SAST false positives come from sanitisation the engine can't see. Mark confirmed false positives in the Vulnerabilities hub so they stay suppressed on future scans.