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.
• Broken access control (structural) - missing function-level authorization, permitAll on sensitive routes, IDOR / BOLA (CWE-639) where an object reference is taken straight from request input, and CSRF-enforcement that omits an unsafe method (e.g. a config that protects POST/PUT/DELETE but leaves PATCH open, CWE-352).
• Insecure deserialization and XXE hardening-absence - flags deserialization and XML-parsing sinks that lack the hardening that makes them safe.
• Language coverage spans Python, Java, Go, JavaScript/TypeScript, C#, Ruby, PHP and more.

The taint engine also seeds sources beyond plain HTTP handlers so non-web entry points are not blind spots: GraphQL resolver arguments, gRPC servicer request params, message-queue / Celery task payloads, and framework config-derived inputs all start a taint flow.

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.