SAST

What it means

SAST, short for Static Application Security Testing, names the tools that analyze source code or compiled code for security flaws without running the program. OWASP describes the techniques they borrow from compilers: data flow analysis, taint analysis, and lexical analysis that turns source into tokens that are easier to manipulate.

Taint analysis is the easiest to picture. It marks variables that carry user-controllable input and traces them to a vulnerable function, the sink; input that reaches the sink unsanitized is flagged. Because nothing has to be deployed, the check can sit early: OWASP notes that SAST tools can be added into an IDE.

How it works

A SAST run reads the code, models how values move through it, and reports each match by filename and line number. It scales well: it runs across lots of software and repeats on every nightly build or CI run.

Each report is a candidate, not a proven vulnerability. OWASP lists the limits:

• False positives. The tool often cannot tell how data is sanitized along a path and flags flaws that are not real.
• Unprovable findings. Proving that a reported issue is an actual vulnerability is difficult, and configuration issues are often missed because they are not in the code.
• Classes it cannot search for. Authentication problems, access control issues, and cryptography misuse are hard to find automatically.

OWASP places static code analysis at the Implementation phase of a security development lifecycle; its DevSecOps Guideline puts SAST in the vulnerability-scanning stage next to DAST, IAST, and SCA, after pre-commit secrets and lint checks, paired with dependency scanning.

Why it matters for AI-written code

The weaknesses assistants reproduce are old ones. Pearce et al. prompted GitHub Copilot with 89 scenarios built around high-risk CWEs from MITRE’s Top 25 list; of the 1,689 programs it produced, approximately 40% were vulnerable. Those are the classes static analysis handles best.

Generated code also arrives faster than a reviewer reads it. A static check is the cheap first pass: a taint path from a request parameter to a query is visible in the diff before anything runs.

The limits still apply: a clean scan says nothing about authorization logic or a misconfigured deployment, and every match needs a person to decide whether it is real. OWASP says as much: automatic detection with high confidence is beyond the state of the art for many flaw types, so these tools frequently serve as aids for an analyst rather than finding flaws on their own.

How Enji Guard helps

SAST-style evidence enters Enji Guard through the security audit, listed in the catalog as Run security audit (“Check for common security problems and unsafe patterns.”). The runbook calls it analysis-only: a second pass follows risky flows from entry point to storage or output, and its evidence rule reads: “Prefer source-to-sink analysis over keyword-only search.”

Each candidate finding carries:

• the file path and line, or the nearest stable symbol
• the risky behavior and who could trigger it
• a confidence level; notes below medium confidence stay out of the severity totals

Static scanners and read-only tools may run when safe, and results are deduplicated so a root cause counts once. Candidates feed the vulnerability improvement: one durable issue and, when the change is small, reversible, and verifiable, one pull request. Issue-only mode never edits files, and Enji Guard never merges. Once a fix merges, the next audit run checks the new commit.

That loop keeps the security area in the green zone, so coding agents build on a codebase whose findings are current.

Enji Guard does not run repository package scripts, lifecycle hooks, or repository-provided scanners; it inspects their definitions as text. It is not a SAST product wired into an IDE or CI pipeline, and an audit with no findings does not prove the system secure.