How Building a SAST Tool Rewrote My Approach to Application Security

Building a static application security testing (SAST) tool from the ground up wasn’t just a technical challenge—it was a fundamental reeducation in how I perceive software vulnerabilities. After 13 years of writing code in Java, C#, Kotlin, and Node.js, I considered myself well-versed in secure development practices. Yet, the process of creating a SAST scanner exposed gaps in my understanding that traditional engineering experience couldn’t fill.

This project wasn’t just about writing detection rules or integrating tools into CI/CD pipelines. It was about confronting the uncomfortable truth: knowing how to write secure code isn’t the same as understanding why it’s secure—or how attackers exploit the gaps between intention and implementation.

The Illusion of Secure Patterns

For years, I followed best practices religiously. Parameterized queries for SQL? Used them every time. Input validation? Built it into every API endpoint. OAuth flows? Strictly adhered to the specification. These patterns were instilled in me as the bedrock of secure coding. But when I had to translate that knowledge into a SAST rule capable of distinguishing safe from vulnerable code, I realized how shallow my grasp of the underlying mechanics truly was.

Take SQL injection as an example. I knew parameterized queries prevent it, but I couldn’t articulate why beyond vague assurances about "separating data and queries." Building a detection rule forced me to dig deeper. The critical distinction lies in how databases parse SQL statements:

• Vulnerable code: The query structure and user input merge into a single string, allowing attackers to inject malicious SQL syntax.
• Secure code: The query structure and data travel as separate messages. The database treats the input strictly as data, never as executable code.

This isn’t just academic nitpicking—it’s the difference between a rule that flags unsafe patterns and one that truly understands the threat model. My years of experience had given me the what of secure coding, but not the why. AppSec requires both.

The Adversarial Mindset: Seeing Code Through an Attacker’s Eyes

Software engineering thrives on collaboration. Teams build systems with the assumption that inputs are valid, networks are stable, and users act predictably. Application security, by contrast, demands an adversarial perspective. It’s not enough to ask, Does this code work? The real question is, How could this code be manipulated to do something it wasn’t designed to do?

This shift is jarring for engineers accustomed to constructive problem-solving. When I developed a rule to detect JWT algorithm confusion attacks, I had to mentally role-play as both defender and attacker. The process involved:

• Identifying what parts of the authentication flow an attacker could control.
• Mapping assumptions in the code that, if violated, could lead to token forgery.
• Envisioning the exploit chain—how a small oversight in validation could cascade into a full breach.

This adversarial thinking isn’t intuitive for engineers trained to optimize for functionality. Yet it’s the core of OWASP’s Top 10. Categories like A03:2021 — Injection and A07:2021 — Identification and Authentication Failures aren’t just checklists; they’re catalogs of the assumptions developers make that attackers exploit. Recognizing those assumptions requires flipping the mental model from How can we make this work? to How can this break in the worst possible way?

SAST Tools: Signals, Not Solutions

Before building my own SAST scanner, I treated commercial tools like Snyk or Semgrep as oracles—black boxes that delivered definitive verdicts on code safety. The experience of constructing a SAST tool shattered that illusion. A scanner is nothing more than a codified set of heuristics: rules written by humans, based on their understanding of vulnerabilities, with subjective confidence ratings and severity classifications.

The key insight? A SAST tool doesn’t know your codebase’s context. It doesn’t understand your threat model, your deployment environment, or whether a theoretical vulnerability is actually exploitable in practice. This isn’t a flaw—it’s a limitation of the tool itself.

My approach to SAST results changed entirely after this realization. Instead of treating findings as compliance checkboxes, I now ask:

• What specific pattern is this rule trying to detect?
• Does my codebase exhibit this pattern for the reason the rule assumes?
• In my specific context, is this vulnerability actually exploitable?
• What would an attacker need to control to turn this into a real-world breach?

This analytical rigor transforms a SAST tool from a DevOps gatekeeper into a strategic ally in threat modeling. The scanner’s output is merely the starting point—not the conclusion.

What Every Developer Should Know Before Diving Into AppSec

The transition from software engineering to application security isn’t about learning new programming languages or mastering obscure frameworks. It’s about cultivating a new cognitive framework—one that prioritizes understanding attack mechanics over following secure patterns. Here’s what I wish I had known earlier:

• Vulnerabilities aren’t just bugs; they’re mismatches between design assumptions and attacker capabilities. A buffer overflow isn’t a performance issue—it’s a failure of boundary validation in a world where attackers control input.

• Adversarial thinking is a skill, not a talent. Like debugging or refactoring, it improves with deliberate practice. Start by dissecting OWASP Top 10 entries and asking, Where could an attacker subvert this?

• Tools amplify your expertise, but they can’t replace it. A SAST scanner will flag potential issues, but interpreting those findings in your specific context requires deep domain knowledge.

• The most dangerous vulnerabilities are the ones you don’t know you’re missing. Blind spots in threat modeling often stem from unexamined assumptions—like assuming input validation is sufficient when it’s not context-aware.

The Road Ahead: Security as a Continuous Process

The most humbling lesson from this journey is recognizing how much there is still to learn. Application security isn’t a destination; it’s a discipline that evolves alongside attack techniques and software architectures. The SAST tool I built is now a permanent fixture in my workflow, but its real value lies in the mindset shift it provoked—not the code it generates.

For engineers considering a pivot into AppSec, the path isn’t paved with certifications or frameworks. It’s paved with curiosity about how systems fail, patience for adversarial role-playing, and a willingness to confront the uncomfortable gaps between intention and reality. The tools will come and go, but the ability to think like an attacker—that’s the skill that outlasts them all.