Static Application Security Testing (SAST): Is the team careful writing the code?

When building secure software, one of the key factors that can make or break a system is the care taken during the code-writing process. Static Application Security Testing (SAST) is designed to catch potential vulnerabilities early in the development cycle, ensuring that the code is clean, secure, and follows best practices. But how does SAST fit into the broader security testing landscape, and what can we learn from its results?

What Would SAST Result In?

A thorough SAST scan typically results in a detailed report of all the vulnerabilities and weaknesses within your codebase. These results can include:

Code-level Vulnerabilities: SAST identifies issues such as SQL injection risks, buffer overflows, and insecure coding patterns. These are problems that, if left unchecked, could be exploited by attackers.
Insecure Design Patterns: Beyond finding specific bugs, SAST can reveal insecure coding practices that may not immediately lead to an exploit but could leave the system open to attacks in the future.
False Positives: One of the common challenges with SAST is that it can sometimes flag issues that aren’t true vulnerabilities. Developers need to balance acting on SAST results with filtering out false alarms.

In essence, a SAST scan provides a comprehensive review of your code’s security posture, helping your team spot flaws before they ever reach production. The earlier you catch these issues, the easier (and cheaper) they are to fix.

Blaming: A Technical and Social Challenge

Something special in SAST is you can pinpoint who’s responsible for the risk, this is a bit harder in other types of testing, as adding a dependency for example can be a team decision, where a SAST finding is marking a specific line of code with issue, which is clearly the responsibility of the line owner/writer.

SAST can sometimes raise an important question: Who is to blame for the vulnerabilities? Blaming in the context of software security comes in two forms—technical blaming and social blaming—and both play significant roles in how teams handle SAST results, as SAST, unlike DAST, can be traced back to the causing line

Blaming as a Technical Term

Although it has a socially negative meaning, in technical security discussions, “blaming” often refers to tracing a vulnerability back to its source in the code, hence the Git “blame” command. SAST tools make it easy to pinpoint the exact lines where security issues arise, often assigning a “blame” to specific developers or code commits, as you can find the exact line owner of any specific SAST output. This helps teams quickly track down the origins of a problem, but it can also lead to a narrow focus on fixing that particular piece of code without addressing the larger, systemic issue.

For example, a SAST report might blame a junior developer’s insecure implementation of a login function, but the real problem could be a lack of training or unclear coding standards across the team.

Blaming as a Social Term

Although blaming as a technical term is welcomed, as it allows tracing the issue to the exact commit and developer who pushed it, social blaming is something development teams must carefully avoid. When SAST identifies vulnerabilities, it’s easy to point fingers at individual developers, especially those who wrote the code in question. However, security is a team effort, and this kind of social blaming can harm collaboration and trust.

Blaming a single person for vulnerability can create a culture of fear, where developers are afraid to take ownership or try new things. Instead, teams should focus on creating an environment where vulnerabilities are seen as learning opportunities rather than failures. After all, security flaws often arise from gaps in communication, inconsistent coding practices, or a lack of resources—issues that can’t be solved by placing blame on individuals.

Conclusion: Building Secure Code is a Team Effort

Static Application Security Testing (SAST) offers developers a powerful tool to identify code-level vulnerabilities early in the development process. But as with any tool, how you use the results matters. SAST should guide teams toward improvement, not toward assigning blame—whether technically or socially.

By focusing on collaboration, training, and refining secure coding practices, teams can turn SAST from a tool for finding flaws into a key part of their development lifecycle, fostering a culture of accountability and continuous improvement.