The Builder + Breaker Journey: Writing My First SAST Tool in Rust

Hello there! If you’ve visited my corner of the digital world before, you know I’ve spent my career traversing the realms of fullstack development, ethical hacking, and DevOps.

From my early days cutting my teeth as a software engineer at GCubed, to my five years flourishing as a Senior Developer at Xanda Ltd, I’ve spent a decade architecting robust applications in JavaScript, React, Ruby on Rails, and PHP. I’ve built complex backends and designed engaging UIs.

However, this isn’t a transition away from code—it is an evolution. As I expanded my expertise into Ethical Hacking and became a secOPS group Certified AppSec Practitioner, my goal was to polish my skills simultaneously as both a Developer and an Application Security professional. In bridging these two disciplines, I realized something crucial:

Understanding how to break code makes you a better developer. Understanding how to build code makes you a better hacker.

There is a sweet spot where these two worlds collide: Tooling. And that is where the real magic happens.

The Challenge: 12 Tools in 12 Months

My goal is simple but ambitious: Build 12 cybersecurity tools in one year.

I’m calling this the “Builder + Breaker” series. Just as I push my physical limits in powerlifting, I want to push my intellectual limits by stepping out of my comfort zone of high-level interpreted languages (like PHP and Ruby) and into the world of systems programming.

For my very first project, I decided to tackle a fundamental concept in AppSec: Static Application Security Testing (SAST).

Project #1: rusty-sast

Most developers know SAST tools as the things that yell at you in CI/CD pipelines when you leave an AWS key in your code. I wanted to demystify how these tools actually work by building a lightweight version from scratch.

Why Rust?

I chose Rust for this project (and for the rest of the challenge) for three reasons:

1. Performance: When scanning thousands of files, speed matters. Coming from a background of optimizing React and Rails apps, I wanted raw power.
2. Safety: Rust’s memory safety guarantees prevent me from writing the very vulnerabilities I’m trying to detect.
3. The Ecosystem: Crates like clap (for CLI args) and regex make the developer experience incredible.

How It Works

At its core, rusty-sast is a CLI tool that recursively scans a directory for specific file extensions (currently PHP and JavaScript) and checks them against a set of regex patterns.

It looks for:

• Dangerous Functions: eval(), exec(), system()—the usual suspects for Remote Code Execution (RCE).
• Hardcoded Secrets: Regex patterns that look for things resembling API keys or hardcoded passwords.

Here is a snippet of the logic. It’s simple, but effective for a V1:

Rust

// A simple struct to define a security rule
struct Rule {
    name: String,
    pattern: Regex,
    severity: String,
}

// Defining what we look for
let rules = vec![
    Rule::new("Dangerous Eval", r"eval\(", "HIGH"),
    Rule::new("AWS Access Key", r"AKIA[0-9A-Z]{16}", "CRITICAL"),
];

You can view the full code on my GitHub here: https://github.com/geniuskidkanyi/rusty-sast

The “Builder + Breaker” Perspective

Writing this tool highlighted the limitations of “Grepping for bugs.”

As an Ethical Hacker, I know that eval($_POST['cmd']) is a critical vulnerability. As a Developer, I know that // careful, do not use eval() in a comment is harmless.

My current regex-based approach is “dumb”—it flags both. This was a great lesson in why enterprise SAST tools move beyond Regex and use Abstract Syntax Trees (AST) to understand the context of the code, not just the text.

What’s Next?

This is just the baseline. Much like my journey obtaining my Oracle Cloud Infrastructure Architect certification, this is about layering knowledge. Over the next few weeks, I plan to iterate on this tool by adding:

1. Parallel Processing: Using Rust’s rayon crate to scan files concurrently.
2. Configuration: Moving rules to a YAML file so users can define their own signatures.
3. CI Integration: Outputting results in SARIF format for GitHub Actions support.

This journey is about progress, not perfection. I’m learning Rust one compiler error at a time, and I’m solidifying my AppSec knowledge by building the tools I use daily.

Coming up next month: I’ll be shifting gears from code analysis to network security. Stay tuned for Project #2network security.

Stay tuned for Project #2