The Limits of SAST: When Secure Code Still Builds an Insecure System

Some of the most important application vulnerabilities aren't caused by a dangerous function, an unsafe API, or a tainted data flow. They exist because a security control was never implemented in the first place.

SAST can tell you that code does something dangerous. It is much harder for SAST to tell you that code failed to do something security-critical.

Consider a file-upload endpoint. A developer writes something perfectly reasonable:

@app.post("/profile-picture")
def upload(file):
    path = save(file)
    return {"url": path}

No SQL injection. No hardcoded password. No command injection. The SAST scan is clean.

But the actual security requirements were:

SAST correctly determines the query below is safe from SQL injection. But in a multi-tenant application, the real vulnerability is what's absent.

SELECT *
FROM invoices
WHERE id = :invoice_id;
-- Parameterized. No injection.
-- SAST: clean.

The endpoint checks whether the user is logged in. Good. But for a POST /api/users/change-email — should it also require:

@app.post("/password-reset")
def reset(request):
    ...

The implementation is fine. But what happens when someone sends:

10 requests
100 requests
10,000 requests
1,000,000 requests

The client sends a price. The code accepts it. Everything is syntactically valid.

{
  "product_id": 123,
  "quantity": 1,
  "price": 10
}

Sequentially, this looks perfectly fine:

balance = get_balance(account)

if balance >= amount:
    update_balance(account, balance - amount)
    transfer(amount)

But security doesn't happen sequentially. Step through the concurrent path:

Some of the most important security controls aren't in source code at all — they're in infrastructure: S3 bucket permissions, IAM policies, security groups, Kubernetes RBAC, TLS config, CSP headers, HSTS.

Internet
   ↓
Public S3 bucket
   ↓
Sensitive customer data

I've seen security engineers with limited development experience move into SAST roles and treat scanner output as a vulnerability report rather than as an input into security analysis. That creates two opposite failure modes:

LLM-assisted SAST is substantially more interesting than rule-based scanners because it can reason across controllers, models, middleware, routes, and infra definitions simultaneously. Given:

save_uploaded_file(file)

An LLM might ask: where is the file-type validation? Size restriction? Malware scan? Where is it stored? Can another user retrieve it?

Security is ultimately about properties the system must maintain. Click each one to see why SAST struggles with it:

The answer isn't to abandon it. A mature approach uses all four lenses together:

The most interesting vulnerabilities are often not “the developer wrote dangerous code.” They're “the developer never implemented the security property the system required.”

No scanner can reliably discover every requirement that nobody encoded.