Evading SAST: A Developer’s Playbook (Not Recommended)

Security scan findings can be annoying — especially when they land on your desk during tight deadlines. If you’re a developer, database engineer, DevOps, or anyone involved in the software lifecycle, you’ve likely wished those security findings would just disappear.

If you’re a developer, you’re in the right place. In this post, we’ll explore how some Static Application Security Testing (SAST) tool findings can be evaded — without fixing the underlying vulnerabilities.

⚠️ Let’s be clear: This article is not a recommendation to implement these evasion techniques in any real-world application. Instead, it is intended as an educational piece to illustrate how SAST tools work — and how developers are ultimately responsible for code security.

Verifiers vs. Bug Finders

Let’s get one thing straight:

When a SAST tool shows no SQL Injection in your app, that doesn’t mean your code is 100% clean.

These tools are not general-purpose verifiers. Instead, they are excellent bug finders — especially for well-known vulnerability types. Based on experience, we can safely say:

“For certain types of vulnerabilities, SAST tools are the best bug-finding automation we have.”

Assumptions & Simplifications

SAST tools work under performance constraints. To be fast and useful, they make simplifying assumptions and approximations. For example:

A codebase that might take a developer 4–5 days to analyze could be processed by a SAST tool in 1–2 hours.

But those assumptions create two risks:

1. False Positives (FP) – Flags that aren’t real issues

2. False Negatives (FN) – Missed real vulnerabilities

Unfortunately, both can be intentionally exploited by developers to “hide” vulnerabilities instead of fixing them.

1. Hiding Sensitive Data Violations

SAST tools often detect sensitive data leaks by pattern-matching variable names like password, secret, token, etc.

For example:

String password = "v1o!gjs49#1glb53*";

Simply renaming variables can evade detection:

String secrets [] = { "v1o!gjs49#1glb53*" };

Or abstracting with custom classes:

class PasswordStore
{
    public String value;
}
PasswordStore ps = new PasswordStore();
ps.value = "v1o!gjs49#1glb53*";

The logic remains the same, but detection becomes harder.

2. Obscuring Control Flow Issues

Empty catch blocks are a well-known code quality issue. But simply adding a meaningless line can fool static analyzers:

catch (Exception e) {
    int sastIsHappy = 42;
}

Now the tool “sees” an active catch block — even though the issue is not resolved.

3. Obfuscating Dangerous Data Flows

Data flow is central to finding injection flaws. But by carefully splitting data across references, we can confuse the tool.

Example:

C a = new C();
C b = a;
string input = Console.ReadLine();
Mix(a, b, input);

...

void Mix(C a, C b, string input) {
    a.x = input;
    Process.Start(b.x);
}

Here, unless the analyzer does deep points-to analysis, it won’t recognize that a and b reference the same object, and a Command Injection might go unnoticed.

4. Abusing Unsupported Language Features

Most tools do not fully support every language construct. For example, in Java Server Faces (JSF):

<h:outputText value="#{param['bio']}" escape="false" />

This might trigger an XSS finding.

But moving the same logic to a custom component can bypass detection:

<my:customOutputText/>

Without understanding the templating structure, many tools won’t follow through the indirection.

So, What’s the Point?

To be 100% clear:

Evading vulnerabilities instead of fixing them is dangerous, irresponsible, and potentially illegal.

The real goal of this article is to demonstrate that SAST tools are not perfect. They are incredibly useful — but cannot replace developer responsibility for code security.

Instead of hiding vulnerabilities, teams should:

• Understand how tools work

• Know their strengths and limitations

• Use them to complement secure development practices

Remember:

Tools can guide you, but secure software is built by secure developers.