DEV Community: Patience Mpofu

Why I Built an ML-Powered Secrets Detector Instead of Just Using Regex

Patience Mpofu — Sun, 10 May 2026 15:40:08 +0000

ost secrets scanners work the same way.

They maintain a list of regex patterns — one for AWS access keys, one for GitHub personal access tokens, one for Stripe keys, one for JWT headers — and they scan your code looking for matches. When a pattern fires, they report a finding. When it doesn't, they stay silent.

This works well for secrets that have distinctive, consistent formats. An AWS access key always starts with AKIA followed by 16 uppercase alphanumeric characters. A GitHub PAT has a recognisable prefix. A private key has a PEM header. Regex catches these reliably.

But it's only part of the problem. And the part it misses is exactly where real breaches happen.

This is the story of why I built a machine learning secrets detector — what the existing approaches get wrong, what ML adds, and what the combined system catches that neither approach catches alone.

The Two Failure Modes of Existing Tools

Before building anything, I spent time understanding where the leading tools fail. TruffleHog, detect-secrets, and Gitleaks are all excellent tools. They're also all vulnerable to the same two failure modes in different proportions.

Failure Mode 1: The Regex Gap

Regex-only scanners miss secrets that don't match a known pattern.

The most dangerous class of missed secrets is the generic hardcoded credential — a password, database URL, or internal API key that doesn't follow any publicly documented format because it was generated internally.

# No regex pattern catches this reliably
DB_PASSWORD = "Tr0ub4dor&3"
INTERNAL_API_KEY = "prod-backend-service-key-2019"
SMTP_PASSWORD = "companyname_mail_2018!"

These are real secrets. They're low entropy by the standards of a cryptographically random key. They don't match any known service's key format. A regex scanner walks past them silently.

This is not a theoretical concern. A significant proportion of credential exposures in real breaches involve exactly this type of secret — human-chosen passwords and internal tokens that were never designed to be detected by pattern matching.

Failure Mode 2: The Entropy False Positive Flood

Some tools compensate by flagging anything with high Shannon entropy — the reasoning being that secrets are random, and random strings have high entropy.

This is directionally correct and practically unusable in many codebases.

High-entropy strings that are not secrets appear constantly in normal code:

# UUID — high entropy, not a secret
session_id = "550e8400-e29b-41d4-a716-446655440000"

# SHA-256 hash — very high entropy, not a secret
expected_checksum = "d8e8fca2dc0f896fd7cb4cb0031ba249"

# Base64-encoded image data — extremely high entropy, not a secret
avatar_placeholder = "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJ..."

# Package integrity hash — high entropy, not a secret
integrity = "sha512-abc123def456..."

A pure entropy scanner flags all of these. In a Node.js project with a package-lock.json, an entropy scanner generates thousands of findings from integrity hashes alone. Engineers learn to ignore it within a week.

What ML Adds: Context-Aware Classification

The insight that drove the ML approach is that whether a string is a secret depends on context, not just the string itself.

d8e8fca2dc0f896fd7cb4cb0031ba249 is either a secret or a benign hash depending on what variable contains it. A human security engineer can tell these apart instantly by reading the surrounding code. A regex scanner and an entropy scanner cannot.

The question I asked was: can I teach a classifier to do what a human engineer does — look at the full context of a string and make a judgment about whether it's a secret?

The answer turned out to be yes, with a 26-dimensional feature vector that captures what a human eye actually processes when making that judgment.

Here's the comparison that drove the design:

Approach	Catches High-Entropy Secrets	Catches Low-Entropy Secrets	False Positive Rate
Regex only	Yes (known formats)	No	Low
Entropy only	Yes	No	Very high
ML classifier	Yes	Yes	Significantly reduced

The ML classifier doesn't replace regex — it adds a second layer. Known-format secrets (AWS keys, GitHub PATs, JWTs) are still caught by pattern flags that are part of the feature vector. Generic hardcoded credentials that no regex would catch are caught by the combination of entropy, character distribution, and — most importantly — the variable name context.

The Feature That Changed Everything: Key Name Risk

When I looked at feature importances after training the initial model, one feature stood above all others: key_name_risk, with an importance score of 0.28 out of 1.0.

That's the variable name. Not the value — the name of the variable holding the value.

This makes intuitive sense once you see it. These two lines of code contain the same string value:

checksum = "d8e8fca2dc0f896fd7cb4cb0031ba249"
password = "d8e8fca2dc0f896fd7cb4cb0031ba249"

A human engineer looks at these and immediately knows: the first is almost certainly a hash, the second is almost certainly a secret. The string itself carries no information about its purpose. The variable name carries everything.

I built a risk scoring function that assigns numerical scores to variable names based on their semantic association with sensitive data:

password, passwd, secret, private_key → score 1.0
api_key, token, credential, auth → score 0.9
access_key, client_secret, bearer → score 0.85
config, setting, value → score 0.1
checksum, hash, version, id → score 0.0 The classifier learns to combine this score with the entropy and character distribution features to make decisions that mirror what a human reviewer would make.

The result: password = "abc123" gets flagged despite low entropy. checksum = "d8e8fca2dc0f896fd7cb4cb0031ba249" gets passed despite high entropy. Neither outcome is achievable with regex or entropy alone.

Why Random Forest, Not a Neural Network

When people hear "ML classifier," they often assume deep learning. I chose Random Forest deliberately, and it's worth explaining why.

Interpretability. A Random Forest tells you exactly why it made a decision — which features contributed how much to a particular classification. When an engineer asks "why did the scanner flag this?", I can show them the feature breakdown: high entropy (0.82), key name risk (0.95), matches JWT pattern (true). A neural network produces a probability with no explanation.

Size. The trained model is approximately 1MB as a pickle file. It ships with the tool, requires no internet connection, and adds negligible overhead to a scan. A neural network of sufficient sophistication would be orders of magnitude larger.

Training speed. The model trains on 6,000 labeled samples in seconds on a standard laptop CPU. No GPU required. This matters enormously for the retraining feature — teams can add their own training samples and retrain in their local environment without specialist infrastructure.

No overfitting on small data. With 6,000 training samples — which is small by deep learning standards — Random Forest generalises better than a neural network would. The structured feature engineering does the heavy lifting; the model itself doesn't need to be sophisticated.

The tradeoff is ceiling accuracy. A neural network operating on raw token sequences would likely achieve higher peak accuracy given sufficient data. But for a tool that needs to be deployable, explainable, and retrainable by a team without ML expertise, Random Forest is the right choice.

Synthetic Training Data: The Ethical Constraint

One early design decision shaped everything else: I would not train on real leaked secrets from public repositories.

The alternative — scraping GitHub for accidentally committed credentials and using them as positive training examples — is technically straightforward and has been done. It's also legally and ethically problematic. Those credentials belong to real people and organisations. Even if the data is technically public, using it to train a commercial tool raises questions I didn't want to answer.

Instead, I built a synthetic data generator that produces realistic examples of both secrets and benign high-entropy strings:

Secrets (label=1): Algorithmically generated AWS access keys, GitHub PAT formats, JWT structures, OpenAI key formats, Slack tokens, database connection strings, and — critically — synthetically generated "human-chosen" passwords that follow common patterns without being anyone's real password.

Benign (label=0): UUIDs, MD5 and SHA-256 hashes, version strings, base64-encoded image data fragments, color hex codes, package integrity hashes, lorem ipsum text fragments.

The synthetic approach has one significant advantage beyond ethics: I can generate unlimited training data and precisely control the class distribution. The 6,000 sample baseline can be scaled to 50,000 samples with a single command, which meaningfully improves model accuracy on edge cases.

The Three-Layer Detection Architecture

The final tool combines three detection mechanisms, each compensating for the others' weaknesses:

Layer 1 — Pattern matching flags. Sixteen binary features in the feature vector correspond to known secret formats (AWS, GitHub, JWT, OpenAI, Slack, database URLs, private key headers, and so on). These fire on known formats with near-zero false positives and form the backbone of high-confidence detections.

Layer 2 — Entropy and character analysis. Shannon entropy, character class ratios, repetition ratio, longest run of repeated characters — these features capture the statistical "shape" of a secret without requiring a specific format match. High entropy combined with a high-risk key name is a strong signal even when no pattern matches.

Layer 3 — Key name risk scoring. The variable name context that neither regex nor entropy captures. This is what allows the classifier to catch password = "simple123" despite its low entropy and lack of a recognisable format.

A finding is reported when the classifier's confidence exceeds a configurable threshold (default: 0.7). Findings include the confidence score, the matched pattern if any, and — for CI/CD integration — an exit code that can gate builds.

What This Actually Catches

I ran the tool against a collection of test cases designed to stress each approach. Results that illustrate the gap:

Caught by all approaches: AWS_KEY = "AKIAIOSFODNN7EXAMPLE" — known format, high entropy, high-risk key name. Every tool gets this.

Caught only by ML: DB_PASS = "Winter2019!" — low entropy, no known format, but the key name DB_PASS scores 1.0 and the classifier flags it at 89% confidence. Regex misses it. Entropy misses it.

False positive in entropy tools, not in ML: expected_hash = "d8e8fca2dc0f896fd7cb4cb0031ba249" — high entropy, but key name scores 0.0 and the ML classifier correctly passes it. A pure entropy scanner flags it; the ML classifier does not.

False positive in regex tools, not in ML: An internal test file with TEST_TOKEN = "fake-token-for-testing" annotated with # secrets-ignore — the suppression annotation is respected, and the low-entropy value combined with a test file context (another feature) keeps the confidence below threshold even without the annotation.

Where This Fits in a Security Programme

A secrets detector — even an ML-powered one — is one layer of a defence-in-depth approach, not a complete solution.

It catches secrets at the point of scanning. It doesn't prevent secrets from being created in the first place (that's developer education and code review). It doesn't rotate compromised credentials (that's incident response). It doesn't enforce secrets management policies (that's your secrets manager — Vault, AWS Secrets Manager, Azure Key Vault).

What it does well: systematically surface secret exposure across a codebase and git history, prevent new secrets from reaching the repository via pre-commit hooks, and provide a measurable baseline for "how many secret exposures exist in our codebase right now."

That baseline matters more than most teams realise — you can't improve what you can't measure.

The full source, including the feature extractor, trainer, and pre-commit hook, is at github.com/pgmpofu/secrets-detector.

Next up: a deep dive into the 26-dimensional feature vector — exactly what the model sees when it evaluates a candidate secret, and how each feature contributes to the final decision.

What Building a SAST Tool Taught Me About AppSec That 13 Years of Software Engineering Didn't

Patience Mpofu — Sat, 09 May 2026 23:16:23 +0000

I've been writing software professionally since 2011.

Java, C#, Kotlin, Node.js. Enterprise backends, microservices, APIs, data pipelines. I've shipped production code that millions of people have used without knowing it. I've led teams, reviewed architectures, mentored junior engineers, and done all the things that accumulate into what people call "senior software engineer."

And yet, when I decided to transition into application security, I realised I had significant blind spots — not about how software works, but about how software fails. Specifically, how it fails in ways that attackers can exploit.

This is the final article in a series about building a SAST scanner from scratch, embedding it in CI/CD pipelines, writing custom detection rules, and managing false positives. But it's really about what that whole process taught me about application security as a discipline — and what I wish I'd understood earlier.

I Knew How to Write Secure Code. I Didn't Know Why It Was Secure.

Here's an embarrassing admission: I've been using parameterised queries for SQL for at least a decade. I knew you were supposed to use them. I used them every time. I would have told you confidently that they prevent SQL injection.

But if you'd asked me, before I started studying AppSec seriously, to explain why they prevent SQL injection — the actual mechanism — I would have given you a hand-wavy answer about "the database handling it separately."

Building the SQL injection detection rule forced me to get precise. I had to understand exactly what makes "SELECT * FROM users WHERE id = " + userId dangerous, what makes SELECT * FROM users WHERE id = ? with a bound parameter safe, and why the difference matters at the level of how the database parses and executes the statement.

The answer — that parameterised queries send the query structure and the data in separate messages, so the database never attempts to parse the data as SQL syntax — is not complicated. But I didn't actually know it at that level of precision until I had to write a rule that distinguishes between the two patterns.

This was a theme throughout the project. I knew the what of secure coding from years of following conventions and best practices. Building detection rules forced me to learn the why — the actual attack mechanics that the conventions are defending against.

The lesson: Knowing the secure pattern is not the same as understanding the vulnerability. For a software engineer, the secure pattern is enough to write safe code. For an AppSec engineer, you need to understand the attack, because your job is to find it when someone else didn't write the safe pattern.

Security Is an Adversarial Discipline

Software engineering is largely a collaborative discipline. You're building something. The goal is for it to work. Your mental model of the system is oriented around the happy path — the flow where inputs are valid, networks are reliable, and users do what you expect.

AppSec is adversarial. The mental shift required is genuinely disorienting at first.

When I was building the JWT algorithm none rule, I had to think like someone who wants to forge authentication tokens. Not because I want to do that, but because unless I understand exactly how the attack works — what the attacker controls, what assumptions the vulnerable code makes, what the exploit chain looks like — I can't write a rule that reliably detects it.

This is the skill that 13 years of software engineering didn't develop: adversarial thinking. The question isn't "does this code do what it's supposed to do?" It's "how could someone make this code do something it's not supposed to do?"

The OWASP Top 10 is, at its core, a catalogue of the assumptions developers make that attackers exploit. A03 — Injection assumes that input is data, not instructions. A07 — Authentication Failures assumes that the code correctly validates identity. A02 — Cryptographic Failures assumes that encryption means the data is protected.

Every category is a place where the developer's mental model of the system diverges from what an attacker can actually do to it. Understanding OWASP deeply means understanding those divergences — not as a checklist, but as a way of thinking.

The lesson: You can't find vulnerabilities you can't imagine. Developing adversarial thinking — the habit of asking "how could this go wrong for someone who wants it to go wrong" — is the most important cognitive shift in the AppSec transition.

Tools Are Amplifiers, Not Answers

Before I built my own SAST tool, I used SAST tools. And I treated them roughly like a compiler warning: something fires, I look at it, I decide whether to fix it or ignore it.

Building one changed how I think about what a SAST tool actually is.

A SAST tool is a codified set of heuristics about what vulnerable code looks like. Those heuristics are written by humans, based on human understanding of vulnerability patterns, with human decisions about confidence levels and severity ratings. The tool doesn't know your codebase. It doesn't know your threat model. It doesn't know whether the finding it just generated is actually exploitable in your specific deployment context.

This sounds like a criticism. It isn't. It's a description of a tool's appropriate role.

When I run Snyk or Semgrep now, I engage with the results differently than I did before. I ask: what pattern is this rule trying to catch? Is that pattern present in my code for the reason the rule assumes? Does the vulnerability the rule targets actually apply in my context? What would an attacker need to control to exploit this?

Those are AppSec questions, not DevOps questions. A DevOps mindset treats SAST output as a compliance gate. An AppSec mindset treats it as a starting point for analysis.

The lesson: A SAST scanner is a signal generator, not an oracle. The value it provides is proportional to the quality of thinking applied to its output — not to the number of findings it generates or suppresses.

False Positives Taught Me About Risk Tolerance

Every time I suppressed a finding in my own scanner, I had to make a decision: is this actually safe, and how confident am I?

That turns out to be the central skill of AppSec: structured risk assessment under uncertainty.

You almost never have complete information. You can't always trace every data flow through a complex system. You can't always know whether a finding is exploitable without building a proof of concept. You have to make a judgment call about whether the risk is acceptable given what you know.

What I learned from managing false positives is that risk tolerance is not a feeling — it's a position that needs to be documented and defensible. "I suppressed this because it looked fine" is not a risk assessment. "I suppressed this because the data being processed is always from our internal configuration system and never from user input, as confirmed by tracing the call stack in lines 42–67" is a risk assessment.

The difference matters when something goes wrong. And in security, things go wrong.

The lesson: Risk assessment is a core AppSec competency, not a soft skill. Developing a structured, documented approach to risk decisions — even informal ones — is more valuable than any specific technical knowledge.

The Gap Between Writing Secure Code and Finding Insecure Code

These are related skills. They are not the same skill.

Writing secure code is a constructive activity. You know what you're building. You apply secure patterns. You follow established conventions. The feedback loop is relatively tight — if you use parameterised queries, you know you're not vulnerable to SQL injection there.

Finding insecure code is a forensic activity. You're examining code you didn't write, often without full context, looking for patterns that indicate vulnerability. The feedback loop is loose — you might flag something, triage it, determine it's a false positive, and never know whether your triage was correct.

The cognitive skills are different. Construction requires knowing the secure pattern. Detection requires knowing the vulnerable pattern and all its variations. It requires understanding which variations are genuinely dangerous and which are contextually safe. It requires maintaining a mental model of an attacker's perspective while reading code that was written from a developer's perspective.

I've spent 13 years getting good at construction. Building this scanner was the first systematic exercise I did in detection. It was harder than I expected — not technically, but cognitively. Shifting from "I'm building this thing to work" to "I'm looking for ways this thing could be exploited" is a genuine gear change.

The lesson: AppSec is not "software engineering plus security knowledge." It's a different cognitive discipline that happens to use the same raw material. Senior software engineers making this transition should expect a genuine learning curve, not just a knowledge gap.

What I'd Tell Someone Starting This Transition

If you're a software engineer moving into AppSec — or considering it — here's what I'd tell you based on this project and the broader transition.

Build something. Reading about OWASP is useful. Reading CVE writeups is useful. Neither teaches you what building a detection rule teaches you. The act of translating "this is a vulnerability" into "this is what the vulnerable code looks like in text" forces a precision of understanding that passive learning doesn't produce.

Study the attacks, not just the defences. Most of your software engineering career was spent learning defences — secure patterns, safe APIs, frameworks that handle the dangerous parts for you. AppSec requires understanding the attacks those defences are designed against. Read exploit writeups. Understand how CVEs actually work. Build your own vulnerable applications and attack them.

Get comfortable with ambiguity. Software engineering has right answers. Does this code compile? Does this test pass? Does this function return the correct value? AppSec often doesn't. Is this finding exploitable? Is this suppression justified? Is this risk acceptable? These questions frequently don't have clean answers, and developing comfort with that ambiguity is part of the transition.

Use your engineering background as a superpower, not a crutch. The thing that makes engineers valuable in AppSec is the ability to read code at scale, understand system architecture, and reason about data flows — skills most pure security professionals develop slowly. Use that. But don't assume that understanding how the code is supposed to work means you understand how it can be broken.

Write about what you're learning. This series started as a way to document my own thinking. Every article forced me to be more precise about something I thought I understood. The act of explaining something to someone else reveals the gaps in your own understanding faster than almost anything else.

Where This Goes Next

Building this scanner and writing this series was one project. The transition is ongoing.

The next project is taking an old Java service and doing something I haven't done yet in this series: running Snyk against a real dependency tree on real legacy code, remediating real CVEs, and measuring the before-and-after security posture with actual metrics.

That's a different kind of AppSec work — Software Composition Analysis rather than static analysis, dependency vulnerabilities rather than code vulnerabilities, Snyk's recommendations rather than my own rules. But the underlying skills are the same: understand the attack, assess the risk, make a defensible decision, measure the outcome.

The transition from software engineer to AppSec engineer is not a destination. It's an ongoing process of developing adversarial thinking, structured risk assessment, and the forensic discipline of finding what's broken rather than building what works.

Thirteen years in, I'm still learning. That's the right state to be in.

The full SAST tool that this series was built around is at github.com/pgmpofu/sast-tool.

If this series was useful to you — or if you're making a similar transition and want to compare notes — I'd genuinely like to hear from you. Find me here on dev.to or connect on LinkedIn.

False Positives in SAST — How I Built Suppression Into My Scanner and Why It Matters

Patience Mpofu — Sat, 09 May 2026 05:02:58 +0000

There's a failure mode that kills security tooling programmes quietly, without drama, and it's not a technical failure.

It's a trust failure.

It goes like this: a team enables a SAST scanner. The scanner fires on 200 things. Engineers triage 40 of them and discover that 25 are false positives. They fix the 15 real findings, suppress the 25 false positives, and then face another 160 findings they haven't looked at yet. Two sprints later, nobody is triaging anymore. The scanner still runs. The reports still generate. Nobody reads them. The security programme is theatre.

False positives are the mechanism by which this happens. Not because developers are lazy — because time is finite and trust is fragile. If a scanner cries wolf enough times, engineers stop listening. That's rational behaviour, not negligence.

This article is about how I thought about false positives when building my SAST tool, what I built to manage them, and why the suppression system design matters as much as the detection rules themselves.

What a False Positive Actually Costs

Before getting into solutions, it's worth being precise about the cost.

A false positive in a SAST scanner costs:

Triage time — an engineer has to read the finding, understand the rule, examine the code in context, and reach a conclusion. Even for an experienced engineer, that's 5–15 minutes per finding for anything non-trivial.
Trust capital — every false positive is a small withdrawal from the trust account between the security team and the engineering team. Trust capital is finite and slow to rebuild.
Attention budget — the more false positives exist, the less attention real findings receive. This is the most dangerous cost. Security is fundamentally an attention allocation problem. A scanner with a 40% false positive rate isn't 40% less useful. It's potentially useless, because the signal-to-noise ratio has collapsed to the point where engineers can't efficiently find real findings among the noise.

The Three Sources of False Positives

Not all false positives are the same. Understanding where they come from determines how to address them.

1. Context-Blind Pattern Matching

This is the most common source in regex-based scanners. The pattern matches the text but doesn't understand what the code is doing.

The MD5 example I've used throughout this series is the canonical case:

# False positive — MD5 for file integrity, not passwords
file_hash = hashlib.md5(file_content).hexdigest()

# True positive — MD5 for password storage
stored_password = hashlib.md5(user_password).hexdigest()

Both lines match the pattern \bmd5\s*\(. Only the second is a vulnerability. A regex scanner cannot tell them apart without understanding the semantic context — what type of data is being hashed.

2. Safe Framework Usage That Looks Dangerous

Some frameworks make inherently dangerous operations safe through abstraction. The dangerous-looking code is actually fine because the framework handles the dangerous part.

// Looks like SQL injection — it's not
// Spring Data JPA with @Query annotation handles parameterisation
@Query("SELECT u FROM User u WHERE u.email = :email")
User findByEmail(@Param("email") String email);

A naive injection rule that flags anything resembling a SQL query with a variable near it would fire here. The JPA annotation system makes this perfectly safe — but the scanner doesn't know that.

3. Test and Configuration Code

Test files are full of patterns that would be alarming in production code:

# test_auth.py
def test_jwt_none_algorithm_rejected():
    # Testing that we correctly REJECT the none algorithm
    malicious_token = jwt.encode({"user": "admin"}, "", algorithm="none")
    response = client.post("/auth", json={"token": malicious_token})
    assert response.status_code == 401  # Should be rejected

This test is doing exactly the right thing — verifying that the application rejects the none algorithm attack. But a scanner looking for algorithm="none" will flag it as AUTHN-001 without understanding that this is a negative test case.

What I Built: The Suppression System

My scanner supports two suppression mechanisms, each designed for different scenarios.

Inline Suppression Annotations

The simplest mechanism: a comment on the same line as the finding tells the scanner to skip it.

file_hash = hashlib.md5(file_content).hexdigest()  # sast-ignore

I support two annotation formats — # sast-ignore and # nosec — because nosec is the Bandit convention and teams coming from Bandit shouldn't have to change their existing annotations.

The scanner checks for these annotations before reporting a finding. If either is present on the matched line, the finding is suppressed silently.

The problem with silent suppression: It's invisible. If every suppression silently disappears from the report, there's no way to audit whether suppressions are legitimate or whether engineers are using them to hide real findings.

Suppression With Justification

The better pattern — and what I recommend teams enforce in code review — is annotating why the suppression is valid:

# MD5 used for file integrity checking only, not credential storage
# Tracked in SEC-REVIEW-2024-041 — confirmed non-sensitive context
file_hash = hashlib.md5(file_content).hexdigest()  # sast-ignore

The annotation still suppresses the finding, but the comment creates a paper trail. When a security audit happens — and it will — every suppression has a documented rationale that a reviewer can evaluate. "We reviewed this and it's fine because X" is defensible. A bare # sast-ignore with no context is not.

The Suppression Inventory in JSON Output

Here's a design decision I'm particularly pleased with: suppressed findings don't disappear from the JSON report. They appear in a separate suppressed_findings array:

{
  "findings": [
    {
      "id": "CRYPTO-002",
      "title": "SHA-1 Usage Detected",
      "severity": "HIGH",
      "file": "src/utils/crypto.py",
      "line": 47
    }
  ],
  "suppressed_findings": [
    {
      "id": "CRYPTO-001",
      "title": "Weak Hashing — MD5",
      "severity": "HIGH",
      "file": "src/utils/file_integrity.py",
      "line": 23,
      "suppression_reason": "MD5 used for file integrity only — sast-ignore"
    }
  ],
  "summary": {
    "total_findings": 1,
    "suppressed": 1,
    "by_severity": { "HIGH": 1 }
  }
}

This means:

The pipeline counts only active findings when deciding whether to fail
The full report shows both active and suppressed findings
Security reviewers can audit suppressions without looking at individual source files
Trend analysis can track suppression rates over time alongside finding rates That last point matters for measuring programme health. If your suppression count is growing faster than your finding count, something is wrong — either your rules are too noisy, or engineers are gaming the system.

Confidence Levels as Pre-Emptive Noise Reduction

The suppression system deals with false positives after they appear. Confidence levels deal with them before.

Every pattern in my rule engine declares a confidence level:

patterns:
  - regex: 'pickle\.loads?\s*\('
    confidence: HIGH     # Almost always a real finding
  - regex: 'unserialize\s*\('
    confidence: MEDIUM   # Real finding in PHP web context, benign in CLI context
  - regex: 'request\.headers\.get\(["\']Origin["\']\)'
    confidence: LOW      # Could be proper allowlist implementation

Confidence levels serve two purposes.

For engineers reading findings: Confidence communicates how much manual review a finding deserves. A HIGH confidence finding deserves immediate attention. A LOW confidence finding is a prompt to look at the code and make a judgment call. Without this signal, every finding looks equally important — which means either everything gets treated as urgent (unsustainable) or everything gets triaged with the same low attention (misses real issues).

For pipeline configuration: Teams can configure their build gate to fail only on findings above a confidence threshold:

# Fail on HIGH severity + HIGH confidence only
python main.py ./src --fail-on HIGH --min-confidence HIGH

# See everything including LOW confidence findings in audit mode
python main.py ./src --fail-on none --min-confidence LOW

This is a more nuanced gate than severity alone. A MEDIUM severity finding with HIGH confidence (this is almost certainly real, and it's moderately serious) might warrant blocking. A HIGH severity finding with LOW confidence (this is probably bad, but it might be fine) might not. The two dimensions together give you much more precise control over your signal-to-noise ratio.

The Suppression Review Process

The suppression mechanism is only as good as the governance around it. A suppression system without a review process is just a way to silence the scanner faster.

Here's the process I'd implement in a team setting:

Step 1 — Developer identifies a finding they believe is a false positive.
They don't suppress it immediately. They raise it in the PR for discussion.

Step 2 — The team reviews the claim.
Is the developer's reasoning sound? Is the code actually safe in context? Does anyone have concerns? This is a two-minute conversation in most cases, not a security committee meeting.

Step 3 — If accepted, the suppression is added with justification.
The # sast-ignore goes in with a comment explaining why. The suppression is visible in the PR diff — it can't be hidden.

Step 4 — The suppression is tracked.
In the JSON report, in a suppression registry spreadsheet, or in a dedicated Notion page — wherever works for your team. What matters is that someone periodically reviews the suppression inventory and asks: are these still valid?

Step 5 — Periodic suppression review.
Suppressions rot. Code changes. The context that made a suppression valid six months ago may no longer apply. A quarterly review of active suppressions — not of the whole codebase, just the suppression inventory — keeps the list honest.

Tuning Rules to Reduce Systemic False Positives

When a specific rule consistently generates false positives across the codebase, the right answer isn't to suppress every instance — it's to tune the rule.

The MD5 rule is a good example. Rather than flagging every md5( call at HIGH confidence, I could tighten the pattern to focus on contexts that suggest credential handling:

Before (noisy):

patterns:
  - regex: '\bmd5\s*\('
    confidence: HIGH

After (tighter):

patterns:
  - regex: 'md5\s*\(\s*(password|passwd|pwd|secret|credential|token)'
    confidence: HIGH
  - regex: '(password|passwd|pwd)\s*=\s*.*md5\s*\('
    confidence: HIGH
  - regex: '\bmd5\s*\('
    confidence: LOW   # Generic usage — review context

Now the rule distinguishes between MD5 in credential contexts (HIGH confidence, almost certainly a problem) and generic MD5 usage (LOW confidence, warrants a look but probably fine). The total finding count might be the same, but the actionable finding count — the ones that genuinely require a fix — goes up as a proportion of the total.

This is the most sustainable way to reduce false positives: better rules, not more suppressions.

The False Negative Trade-off

Every time you tune a rule to reduce false positives, you risk introducing false negatives — real vulnerabilities the scanner no longer catches.

This is the fundamental tension in SAST tool design. It has no clean resolution. It only has a deliberate choice.

If you tighten the MD5 rule to only flag credential contexts, you'll miss the case where a developer uses a custom variable name:

# Now invisible to the tightened rule
user_auth_hash = hashlib.md5(user_password).hexdigest()

The question is: which failure mode is more expensive for your specific context?

If your team is diligent about triage and the cost of a false negative (missed vulnerability) is high — financial services, healthcare, anything with regulatory consequences — keep rules broader and invest in the triage process.

If your team is drowning in noise and findings aren't getting triaged at all — the scanner has already effectively failed — tighten the rules to rebuild trust, accept the trade-off, and plan to layer in additional controls elsewhere.

There's no universally correct answer. There's only an honest assessment of your specific situation.

What a Healthy Suppression Profile Looks Like

After a few months of running the scanner with a consistent process, here's what healthy metrics look like:

Suppression rate below 20%. If more than 1 in 5 findings is being suppressed, your rules are too noisy for your codebase. Tune the rules rather than suppressing everything.

No suppressions without justification comments. Bare # sast-ignore annotations with no explanation are a red flag. Make justification comments a code review requirement.

Suppression inventory reviewed quarterly. Old suppressions that are no longer valid are silent technical debt. A quarterly review catches them.

False positive rate declining over time. As you tune rules based on real-world results, your false positive rate should go down. If it's stable or increasing, you're not learning from your suppression data.

New findings triaged within one sprint. If findings from a scan are still unreviewed after two weeks, your triage process isn't keeping up. Either reduce the finding volume (tune rules) or increase triage capacity.

The Bigger Point

False positive management is not a technical problem. It's a trust and process problem that has technical levers.

The suppression system in my scanner — inline annotations, justification comments, suppressed findings in the JSON output, confidence levels on patterns — these are all technical levers. But they only work in the context of a team that has agreed on how to use them.

The best SAST implementation I can imagine is one where:

Engineers trust the scanner because it has a low false positive rate
The scanner trusts engineers because suppressions are reviewed and justified
Security teams trust both because the suppression inventory is auditable and periodically reviewed That's not a configuration. That's a culture. The configuration just makes the culture possible.

Full source and suppression documentation at github.com/pgmpofu/sast-tool.

Next up — the final article in this series: what building all of this taught me about application security that 13 years of software engineering didn't.

The Adoption Trap to Avoid

Patience Mpofu — Thu, 07 May 2026 18:41:12 +0000

The single biggest mistake teams make with CI/CD-integrated security tooling is treating it as a one-time setup rather than an ongoing programme.

The scanner is not the security programme. The scanner is a signal generator. The security programme is the process by which signals become fixes, fixes become patterns, and patterns become rules that prevent the same issue from appearing again.

Configurable thresholds give you the controls to introduce that programme without breaking your team's deployment workflow. Use them gradually, communicate the reasoning at each phase, and invest as much in the suppression review process as you do in the initial setup.

A scanner your team trusts and engages with is worth ten scanners that get bypassed.

Full source and GitHub Actions workflow examples at github.com/pgmpofu/sast-tool.

Next up: the one everyone's been asking about — false positives in SAST, how I built suppression into the scanner, and why managing false positives is as important as finding real vulnerabilities.

Writing Custom SAST Rules for Vulnerabilities Your Scanner Doesn't Cover

Patience Mpofu — Thu, 07 May 2026 18:38:18 +0000

Every SAST tool ships with a default ruleset. And every default ruleset has gaps.

Sometimes the gap is a framework-specific vulnerability that the tool's authors didn't anticipate. Sometimes it's an internal pattern unique to your organisation — a custom authentication library, a legacy data access layer, a home-grown serialisation format that every engineer knows is sensitive but no off-the-shelf rule covers.

This is the article where I show you how to close those gaps using the YAML rule engine I built. No Python required. No rebuilding the scanner. Just a YAML file and an understanding of what you're trying to detect.

By the end, you'll have written three custom rules from scratch — a Java-specific one, a Node.js-specific one, and an organisation-level one that catches usage of a fictional internal library pattern. The process is the same for any vulnerability you want to target.

Before You Write a Rule: The Four Questions

Every good detection rule starts with the same four questions. Skip them and you end up with either a rule that fires on everything or a rule that fires on nothing.

1. What does the vulnerable code actually look like in text?
Not the conceptual vulnerability — the literal characters that appear on screen when a developer writes the bad pattern. Be specific. "SQL injection" is not an answer. "SELECT * FROM users WHERE id = " + userId is an answer.

2. What does safe code look like?
You need the counterexample. If your pattern would also match safe code, you have a false positive problem. If you can't articulate what safe code looks like, you don't understand the vulnerability well enough to write a rule yet.

3. Which languages does this apply to?
Some patterns are universal — hardcoded secrets look similar everywhere. Others are language or framework-specific. Writing a broad rule when a narrow one is appropriate generates noise and erodes trust in the scanner.

4. What's the right confidence level?
HIGH means "this is almost certainly a real vulnerability." MEDIUM means "this warrants human review." LOW means "this is suspicious but probably benign." If you're unsure, start at MEDIUM and tighten it after you see the results on real code.

Now let's write some rules.

The Rule Format (Quick Reference)

rules:
  - id: CUSTOM-001
    title: Short descriptive title
    description: >
      What the vulnerability is and why it matters.
    severity: CRITICAL | HIGH | MEDIUM | LOW
    category: Injection | Secrets | Cryptography | Authentication | Misconfiguration | Path Traversal
    cwe: CWE-XXX
    owasp: AXX:2021 - Category Name
    languages: ["python", "java", "javascript", "typescript", "csharp", "kotlin", "go", "ruby", "php"]
    remediation: >
      What the developer should do instead.
    patterns:
      - regex: 'your-pattern-here'
        confidence: HIGH | MEDIUM | LOW

Save it anywhere — the scanner discovers all YAML files in the rules/ directory automatically. If you want to keep your custom rules separate from the core ruleset, create a rules/custom/ subdirectory and point the scanner at it:

python main.py ./src --rules ./rules/custom/

Rule 1: Java — Spring `@Transactional` on Public Methods Exposing Sensitive Data

This one is Java-specific and framework-specific. It's the kind of vulnerability that no generic SAST tool covers because it requires understanding Spring's transaction management model.

The vulnerability: In Spring, @Transactional annotations on public methods in @Service or @Repository classes work as expected because Spring creates a proxy. But when @Transactional is placed on a private method, Spring's proxy-based AOP cannot intercept it — the transaction is silently ignored. This is especially dangerous when the private method performs database writes that need to be atomic.

This isn't a traditional security vulnerability in the CVE sense — it's a correctness issue that can become a security issue when the failed transaction silently corrupts data, leaves partial writes in the database, or bypasses audit logging that was supposed to be transactional.

What safe code looks like: @Transactional on public methods, or using TransactionTemplate for programmatic transaction management on private methods.

What vulnerable code looks like:

@Service
public class PaymentService {

    @Transactional  // silent no-op — Spring proxy can't intercept private methods
    private void processRefund(String accountId, BigDecimal amount) {
        ledgerRepo.debit(accountId, amount);
        auditRepo.log("REFUND", accountId, amount);  // may not be in same transaction
    }
}

The rule:

rules:
  - id: JAVA-001
    title: "@Transactional on Private Method — Transaction Silently Ignored"
    description: >
      Spring's proxy-based AOP cannot intercept @Transactional annotations on
      private methods. The annotation is silently ignored, meaning the method
      executes without transaction management. This can cause partial writes,
      data corruption, and bypassed audit logging in database operations.
    severity: HIGH
    category: Misconfiguration
    cwe: CWE-362
    owasp: A05:2021 - Security Misconfiguration
    languages: ["java"]
    remediation: >
      Move @Transactional to public methods only. For private methods that
      require transaction management, either make them public, use
      TransactionTemplate for programmatic transactions, or restructure
      the code so the public caller method is annotated instead.
    patterns:
      - regex: '@Transactional[\s\S]{0,100}private\s+\w+\s+\w+\s*\('
        confidence: HIGH
      - regex: 'private\s+\w+\s+\w+\s*\([\s\S]{0,100}@Transactional'
        confidence: MEDIUM

Testing your rule — create a test file test_java_transactional.java and verify it fires:

// Should fire — JAVA-001
@Transactional
private void updateBalance(String id, BigDecimal amount) { }

// Should NOT fire — public method is fine
@Transactional
public void processPayment(String id, BigDecimal amount) { }

Run:

python main.py ./test_java_transactional.java --rules ./rules/custom/java-rules.yaml

Rule 2: Node.js — `child_process.exec` with Template Literals

This one targets a Node.js-specific pattern that's extremely common in backend services written by developers who came from a systems programming background.

The vulnerability: child_process.exec() passes its argument to the shell for execution. If that argument contains user-controlled input — even through a template literal that looks clean — it enables OS command injection. The shell will happily interpret special characters like ;, &&, |, and backticks as command separators or subshell operators.

What safe code looks like: child_process.execFile() or child_process.spawn() with arguments as an array — these bypass the shell entirely and treat the command and arguments as separate values.

What vulnerable code looks like:

// Dangerous — shell injection possible
const filename = req.body.filename;
exec(`convert ${filename} -resize 800x600 output.jpg`, callback);

// Also dangerous — looks safer but isn't
exec("ffmpeg -i " + userInput + " output.mp4", callback);

What safe code looks like:

// Safe — no shell involved
execFile('convert', [filename, '-resize', '800x600', 'output.jpg'], callback);

// Safe — spawn with args array
spawn('ffmpeg', ['-i', userInput, 'output.mp4']);

The rule:

rules:
  - id: NODE-001
    title: "child_process.exec with Dynamic Input — OS Command Injection"
    description: >
      child_process.exec() passes its argument to the system shell, enabling
      OS command injection when the argument includes user-controlled input,
      template literals, or string concatenation. Attackers can inject shell
      metacharacters to execute arbitrary commands on the host system.
    severity: CRITICAL
    category: Injection
    cwe: CWE-78
    owasp: A03:2021 - Injection
    languages: ["javascript", "typescript"]
    remediation: >
      Replace exec() with execFile() or spawn() and pass command arguments
      as an array. These functions bypass the shell entirely and treat each
      argument as a literal string, preventing shell metacharacter injection.
      Never concatenate user input into exec() arguments.
    patterns:
      - regex: 'exec\s*\(\s*`[^`]*\$\{'
        confidence: HIGH
      - regex: 'exec\s*\(\s*["\'][^"\']*["\'\s]\+\s*\w'
        confidence: HIGH
      - regex: 'exec\s*\(\s*\w+\s*\+'
        confidence: MEDIUM

The three patterns cover the three common forms: template literals with interpolation, concatenation with a string prefix, and concatenation with a variable. The last one is MEDIUM because exec("mycommand" + options) where options is a static config value is less dangerous — but still warrants review.

Rule 3: Organisation-Level — Internal Audit Logger Bypass

This is the most interesting type of custom rule: one that only makes sense for your specific codebase.

Imagine your organisation has an internal library called AuditLogger that must be called for any database mutation. The security policy is clear: every write operation must produce an audit event. But the library has a skipAudit() method that was added for performance testing and was never supposed to reach production code.

This isn't in any public CVE database. No off-the-shelf SAST tool would ever flag it. But it's a real security control bypass in your organisation's context.

The rule:

rules:
  - id: ORG-001
    title: "AuditLogger.skipAudit() — Security Control Bypass"
    description: >
      The skipAudit() method on AuditLogger disables audit event generation
      for database mutations. This method was introduced for load testing
      only and must never appear in production code. Its presence bypasses
      the organisation's regulatory audit trail requirement and may
      constitute a compliance violation.
    severity: CRITICAL
    category: Misconfiguration
    cwe: CWE-778
    owasp: A09:2021 - Security Logging and Monitoring Failures
    languages: ["java", "kotlin", "csharp"]
    remediation: >
      Remove skipAudit() immediately. All database mutations must generate
      audit events via AuditLogger. If performance is a concern, use
      AuditLogger.asyncLog() instead, which queues events without blocking
      the main thread. Contact the security team if an exemption is required.
    patterns:
      - regex: '\.skipAudit\s*\('
        confidence: HIGH
      - regex: 'AuditLogger\s*\.\s*skip'
        confidence: HIGH

Notice what this rule does that a generic tool can't: it encodes your organisation's security policy directly into the scanner. The remediation text names the correct alternative (asyncLog()). The description mentions the regulatory context. The severity is CRITICAL because in this fictional organisation, bypassing audit logging is a compliance issue, not just a best practice.

This is the highest-value type of custom rule because it's completely unavailable from any third-party source.

Multi-Pattern Rules: Increasing Coverage Without Losing Precision

One pattern rarely catches all instances of a vulnerability. The best rules use multiple patterns with appropriate confidence levels to maximise coverage while communicating certainty to the reviewer.

Here's a well-structured multi-pattern rule for detecting hardcoded database credentials in connection strings — a pattern that appears differently across languages and frameworks:

rules:
  - id: CUSTOM-DB-001
    title: "Hardcoded Database Credentials in Connection String"
    description: >
      Database connection strings with embedded credentials expose sensitive
      authentication material in source code, version control history, and
      build artifacts.
    severity: HIGH
    category: Secrets
    cwe: CWE-798
    owasp: A07:2021 - Identification and Authentication Failures
    languages: ["java", "csharp", "python", "javascript", "typescript", "kotlin"]
    remediation: >
      Move credentials to environment variables or a secrets manager such as
      AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault. Never commit
      credentials to version control.
    patterns:
      # JDBC connection strings
      - regex: 'jdbc:[a-z]+://[^/]+/[^?]+\?.*password=[^&\s"'']{3,}'
        confidence: HIGH
      # .NET connection strings
      - regex: 'Password\s*=\s*[^;"\s]{4,}\s*;'
        confidence: HIGH
      # Generic password assignment near connection context
      - regex: '(conn|connection|db).*password\s*=\s*["\'][^"'']{4,}["\']'
        confidence: MEDIUM
      # SQLAlchemy / Django database URLs
      - regex: '(postgresql|mysql|sqlite|mongodb)://\w+:[^@\s"'']{4,}@'
        confidence: HIGH

Each pattern has a different confidence because each has a different false positive profile. JDBC connection strings with password parameters are nearly always real findings. The generic connection.password = pattern might match configuration loading code where the value comes from an environment variable on the right-hand side.

Testing Your Custom Rules

Before you add a rule to your pipeline, test it against both positive and negative cases.

Create a dedicated test file with clearly labelled sections:

# test_custom_rules.py

# --- SHOULD FIRE ---
# NODE-001: exec with template literal
exec(`convert ${userInput} output.jpg`)

# CUSTOM-DB-001: hardcoded JDBC credentials
conn = "jdbc:postgresql://localhost/mydb?user=admin&password=supersecret123"

# --- SHOULD NOT FIRE ---
# Safe: spawn with args array
spawn('convert', [userInput, 'output.jpg'])

# Safe: password from environment
conn = f"jdbc:postgresql://localhost/mydb?user=admin&password={os.getenv('DB_PASS')}"

Then run the scanner and verify the output matches your expectations:

python main.py ./test_custom_rules.py --rules ./rules/custom/ --format json

Check that:

Every SHOULD FIRE comment corresponds to a finding in the output
Every SHOULD NOT FIRE comment has no corresponding finding
The confidence and severity levels match what you intended If a false positive appears, either tighten the regex or downgrade the confidence level. If a true positive is missed, your pattern isn't covering that form of the vulnerability.

The Broader Point: Rules as Institutional Knowledge

The most valuable thing about a YAML-driven rule engine isn't the rules it ships with. It's the rules your team writes over time.

Every time a security engineer finds a vulnerability in a code review, there's a question worth asking: could this have been caught by a scanner rule? If the answer is yes, write the rule. Now the scanner catches that pattern forever, across every future PR, without anyone needing to remember it.

Rules become institutional knowledge. They encode the hard-won understanding of what goes wrong in your specific codebase, your specific frameworks, your specific compliance requirements. That's something no off-the-shelf tool can give you — and it compounds over time.

The full scanner and core ruleset are at github.com/pgmpofu/sast-tool. Drop your custom rules in rules/ and they're picked up automatically on the next scan.

Next up: embedding the scanner in a CI/CD pipeline with configurable severity thresholds — how to go from zero security gates to blocking builds on critical findings without breaking your team's deployment workflow.

How I Modelled the OWASP Top 10 Into a YAML Rule Engine

Patience Mpofu — Thu, 07 May 2026 18:35:39 +0000

When I set out to write detection rules for my SAST tool, I didn't start with a list of regex patterns. I started with the OWASP Top 10.

That might sound obvious, but it matters. The OWASP Top 10 is the closest thing the AppSec world has to a universal curriculum. Every security engineer speaks it. Every compliance framework references it. When I map my rules to OWASP categories, I'm not just organising them — I'm making them legible to the people who will ultimately use them.

This article is about the thought process behind translating OWASP into a machine-readable rule engine. Not just what rules I wrote, but why I wrote them the way I did, and where the tricky ones gave me the most trouble.

The Rule Schema

Every rule in the engine follows the same structure:

- id: AUTHN-001
  title: "JWT Algorithm None Attack Vector"
  description: ">"
    The application accepts JWTs with algorithm set to 'none', allowing
    attackers to forge tokens without a valid signature.
  severity: CRITICAL
  category: Authentication
  cwe: CWE-347
  owasp: A07:2021 - Identification and Authentication Failures
  languages: ["python", "javascript", "java", "csharp", "go"]
  remediation: >
    Always explicitly specify and enforce the expected algorithm when
    verifying JWTs. Never accept 'none' as a valid algorithm. Use an
    allowlist of accepted algorithms.
  patterns:
    - regex: 'algorithm[s]?\s*[=:]\s*["\']none["\']'
      confidence: HIGH
    - regex: 'verify\s*=\s*False'
      confidence: MEDIUM

Six things matter in this schema beyond the obvious metadata:

CWE ID — links to the Common Weakness Enumeration, which is the language of vulnerability databases and CVEs
OWASP category — maps to a Top 10 entry using the 2021 version
Languages array — controls which file types the pattern is applied to
Multiple patterns — a rule can have several patterns, each with its own confidence level
Confidence — HIGH means the pattern is very likely a real vulnerability; MEDIUM means it warrants manual review
Remediation — not just "this is bad" but "here's what to do instead" That last one is deliberate. A scanner that flags vulnerabilities without telling developers how to fix them creates noise, not security. Every rule in my tool includes actionable remediation guidance.

How the 28 Rules Map to OWASP

Here's the full picture before we go deep on individual rules:

OWASP 2021 Category	My Rules
A01 — Broken Access Control	AUTHN-005 (IDOR), MISC-001 (Path Traversal)
A02 — Cryptographic Failures	CRYPTO-001 through CRYPTO-006, SEC-003, SEC-004
A03 — Injection	INJ-001 through INJ-005, MISC-003 (XXE), MISC-006 (Deserialization)
A04 — Insecure Design	MISC-004 (File Upload)
A05 — Security Misconfiguration	MISC-002 (Debug Mode), MISC-003, MISC-005 (CORS)
A07 — Auth & Identity Failures	AUTHN-001 through AUTHN-005, SEC-001 through SEC-006
A08 — Software & Data Integrity	MISC-006 (Insecure Deserialization)

Some OWASP categories are underrepresented — A06 (Vulnerable Components) is better handled by SCA tools like Snyk than a SAST scanner, and A09 (Logging Failures) and A10 (SSRF) would require data flow analysis that regex can't reliably deliver. I'll come back to this.

Deep Dive: The Rules That Required Real Thought

AUTHN-001 — JWT Algorithm None Attack Vector

This one is my favourite rule in the entire set, because it targets a specific, well-known attack that is both elegant and devastating.

The vulnerability: The JWT specification allows the alg header to be set to "none", which means "no signature required." Some libraries honour this. If an attacker intercepts a JWT, changes the payload (for example, escalating "role": "user" to "role": "admin"), sets alg: none, and removes the signature, a vulnerable library will accept it as valid.

This is CWE-347 — Improper Verification of Cryptographic Signature. It's not a cryptographic weakness in the algorithm — it's a logic flaw in how the algorithm is selected.

The detection challenge: The attack can be enabled in several ways. The most obvious is setting the algorithm explicitly:

jwt.decode(token, options={"algorithms": ["none"]})

But it can also be enabled by disabling verification entirely:

jwt.decode(token, verify=False)  # Python jwt library

Or by using a wildcard algorithm list that implicitly includes none. My rule covers the first two patterns:

patterns:
  - regex: 'algorithm[s]?\s*[=:]\s*["\']none["\']'
    confidence: HIGH
  - regex: 'verify\s*=\s*False'
    confidence: MEDIUM

The second pattern (verify=False) is MEDIUM confidence rather than HIGH because disabling verification has legitimate uses in test environments. That's an important distinction — the same code can be correct or dangerous depending on context, and the confidence level communicates that to the developer reviewing the finding.

Remediation: Always pass an explicit allowlist of algorithms when decoding JWTs and never include none. In Python's PyJWT library, that looks like:

jwt.decode(token, key, algorithms=["HS256"])  # explicit allowlist

MISC-006 — Insecure Deserialization

This is the rule I found hardest to write well, because insecure deserialization is one of those vulnerability classes where the presence of the function call isn't necessarily dangerous — it's the source of the data being deserialized that makes it dangerous.

The vulnerability: Deserializing untrusted data can lead to remote code execution. In Python, pickle.loads() will execute arbitrary Python code embedded in the serialized payload. In Java, ObjectInputStream.readObject() has been the source of countless critical CVEs. In PHP, unserialize() is a classic RCE vector.

The detection challenge: I can't tell from the call site alone whether the data being deserialized is trusted (coming from a file the application wrote itself) or untrusted (coming from a user-submitted HTTP body or a message queue). Both look identical to a regex scanner.

My decision was to flag it at HIGH confidence with a remediation note that acknowledges the context-dependence:

- id: MISC-006
  title: Insecure Deserialization
  severity: CRITICAL
  cwe: CWE-502
  owasp: A08:2021 - Software and Data Integrity Failures
  patterns:
    - regex: 'pickle\.loads?\s*\('
      confidence: HIGH
    - regex: 'ObjectInputStream\s*\('
      confidence: HIGH
    - regex: 'unserialize\s*\('
      confidence: MEDIUM
  remediation: >
    Avoid deserializing untrusted data. If deserialization is required,
    use safer formats like JSON. If using pickle, only deserialize data
    from trusted, integrity-verified sources. Consider signing serialized
    payloads. For Java, use safer alternatives like Jackson or Gson for
    JSON deserialization.

I gave unserialize() in PHP a MEDIUM confidence rather than HIGH because PHP codebases legitimately use it in contexts where the data comes from internal sources. The confidence difference is a signal to the developer: look harder at this one, but don't automatically treat it as a defect.

AUTHN-004 — Timing Attack in Auth Comparison

This is the subtlest rule in the set, and the one most likely to generate confused questions from developers who haven't encountered it before.

The vulnerability: When you compare two strings — say, a provided token against a stored token — using a standard equality operator (==), most implementations short-circuit on the first mismatched character. This means comparing a completely wrong token takes microseconds, while a token that matches the first 30 characters takes longer.

An attacker can exploit this by measuring response times to brute-force secrets character by character. It sounds theoretical. It isn't — it's been used in practice against authentication systems.

The fix: Use a constant-time comparison function. In Python, that's hmac.compare_digest(). In Node.js, it's crypto.timingSafeEqual().

The detection: I look for direct string comparison in contexts that suggest authentication:

- id: AUTHN-004
  title: Timing Attack in Auth Comparison
  severity: MEDIUM
  cwe: CWE-208
  patterns:
    - regex: '(token|secret|password|api_key)\s*==\s*'
      confidence: MEDIUM
    - regex: '==\s*(token|secret|password|api_key)'
      confidence: MEDIUM

MEDIUM severity, MEDIUM confidence. The false positive rate here is real — lots of code compares passwords or tokens with == in contexts where timing attacks are a genuine concern, but also in test code, logging, and input validation where they aren't. The finding is a prompt to review, not an automatic defect.

CRYPTO-005 — ECB Mode Encryption

This rule catches one of the most common misuses of encryption that isn't immediately obvious to developers who aren't cryptographers.

The vulnerability: AES-ECB (Electronic Codebook) mode encrypts each block of plaintext independently using the same key. This means identical plaintext blocks produce identical ciphertext blocks, which leaks structural information about the data even when it's "encrypted."

The classic demonstration is encrypting a bitmap image with AES-ECB — the overall pattern of the image remains visible in the ciphertext because regions of the same colour encrypt to the same blocks. For structured data like JSON or database rows, the same leakage applies.

The detection:

- id: CRYPTO-005
  title: ECB Mode Encryption
  severity: HIGH
  cwe: CWE-327
  patterns:
    - regex: 'AES\.MODE_ECB|Cipher\.getInstance\(["\']AES["\']|AES/ECB'
      confidence: HIGH

The pattern catches Java's Cipher.getInstance("AES") because Java's default AES mode — when you don't specify one — is ECB. This is a documentation trap that developers fall into all the time. They think they're using secure AES; they're actually using AES-ECB because they didn't know to specify AES/GCM or AES/CBC.

Remediation: Use AES-GCM for authenticated encryption (preferred) or AES-CBC with a random IV and separate HMAC for integrity verification.

MISC-005 — CORS Wildcard / Reflected Origin

This rule sits at MEDIUM severity because CORS misconfiguration is context-dependent in a way that matters.

The vulnerability: A wildcard CORS header (Access-Control-Allow-Origin: *) allows any website to make credentialed cross-origin requests to your API. A reflected origin header — where the server echoes back whatever Origin header the request sent — is even worse, because it's a wildcard that bypasses the credentials: true restriction that wildcards technically can't combine with.

The patterns:

- id: MISC-005
  title: CORS Wildcard / Reflected Origin
  severity: MEDIUM
  cwe: CWE-942
  owasp: A05:2021 - Security Misconfiguration
  patterns:
    - regex: "Access-Control-Allow-Origin['\"]?\s*[,:]\s*['\"]?\*"
      confidence: HIGH
    - regex: 'allow_origins\s*=\s*\[?\s*["\']\*["\']'
      confidence: HIGH
    - regex: 'request\.headers\.get\(["\']Origin["\']\)'
      confidence: MEDIUM

The third pattern — looking for code that reads the Origin header — is a signal that reflected origin might be happening, not a definitive finding. A developer reading the Origin header might be implementing proper allowlist validation. MEDIUM confidence reflects that ambiguity.

The Categories I Deliberately Left Out

Being honest about gaps matters as much as documenting what you built.

A06 — Vulnerable and Outdated Components belongs to Software Composition Analysis (SCA), not SAST. SCA tools like Snyk and Dependabot check your dependency versions against CVE databases. A regex scanner can't do this — it would need to parse package manifests and cross-reference them against live vulnerability feeds. I deferred this entirely to dedicated SCA tooling.

A09 — Security Logging and Monitoring Failures requires understanding what isn't in the code — which authentication events aren't being logged, which error handlers swallow exceptions silently. Pattern matching can only find things that are present in the text. Detecting absence requires semantic understanding the tool doesn't have.

A10 — Server-Side Request Forgery (SSRF) requires taint analysis. An SSRF vulnerability exists when user-controlled input reaches an HTTP request function without validation. That's exactly the kind of multi-step data flow that regex can't trace. I flagged this in the README as a known gap and a candidate for future AST-based analysis.

What Mapping to OWASP Gave Me

Structuring the rules against OWASP rather than building them ad hoc gave me three things I didn't expect.

Coverage gaps become visible. When you're mapping rules to a framework, the categories with no rules stand out immediately. That's a forcing function for honesty about what your tool actually covers.

The output speaks to security professionals. When a finding says A03:2021 - Injection and CWE-89, a security engineer doesn't need to read the description to understand what they're looking at. The taxonomy does the communication work.

It's defensible. If someone asks why I chose to flag MD5 usage, I can say: because CWE-327 maps to A02:2021 - Cryptographic Failures, and OWASP identifies weak hashing as a top-tier risk category. That's not me making a judgment call — it's me implementing an industry-standard framework.

Building your own tool is one of the fastest ways to understand why the standards are structured the way they are. You don't really understand OWASP until you've had to decide how to implement it.

The full rule set is in the rules/ directory at github.com/pgmpofu/sast-tool. Each YAML file corresponds to a rule category, and every rule follows the schema described above.

Next up: writing custom SAST rules for vulnerabilities your scanner doesn't cover — a practical tutorial using the YAML rule format to extend the tool for stack-specific patterns.

Why I Chose Regex Over AST Parsing in My SAST Tool (And When That Would Be Wrong)

Patience Mpofu — Mon, 04 May 2026 18:16:26 +0000

In my last article, I mentioned that my SAST tool uses regex-based pattern matching instead of AST parsing, and that this was a deliberate tradeoff. A few people asked me to go deeper on that decision — because on the surface, it sounds like I took a shortcut.

I didn't. Or rather — I did, but it was an informed shortcut, and there's a meaningful difference.

Let me explain what AST parsing actually is, why it's considered the "correct" approach, why I chose not to use it, and — most importantly — when that choice would be the wrong one.

First, What's the Difference?

When your SAST tool scans a file, it needs to understand what the code is doing. There are two fundamentally different ways to approach this.

The Regex Approach

Regex treats source code as plain text and looks for patterns that look like vulnerabilities. Here's a simplified version of what my SQL injection rule does:

(execute|query|cursor)\s*\(\s*["\'].*\+.*["\']

This pattern says: find any call to execute, query, or cursor that contains a string concatenation inside the parentheses. If it matches, flag it as a potential SQL injection.

It's fast, simple, and language-agnostic. The same pattern catches suspicious SQL construction in Python, Java, PHP, and JavaScript without modification.

The AST Approach

AST stands for Abstract Syntax Tree. When a compiler or interpreter reads your code, it doesn't see text — it parses the text into a structured tree that represents the meaning of the code.

Take this Python snippet:

user_id = request.args.get("id")
query = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(query)

An AST parser doesn't just see the word execute followed by some text. It understands:

user_id is a variable assigned from request.args — a known source of user-controlled input
query is a string built by concatenating that variable — which is a taint propagation step
cursor.execute(query) is a database call receiving that tainted string — which is a sink This is taint analysis — tracking the flow of untrusted data from a source to a dangerous sink. It's the gold standard of SAST analysis because it understands context, not just surface patterns.

What Regex Gets Wrong

Let me show you a concrete example of where regex fails.

False Positive: The Innocuous MD5

My rule CRYPTO-001 flags any use of MD5 as a potential weak hashing vulnerability:

- id: CRYPTO-001
  title: Weak Hashing — MD5
  severity: HIGH
  patterns:
    - regex: '\bmd5\s*\('
      confidence: HIGH

This will correctly flag:

hashed_password = md5(user_password).hexdigest()  # BAD — MD5 for passwords

But it will also flag:

file_checksum = md5(file_contents).hexdigest()  # FINE — MD5 for file integrity

An AST-based tool with data flow analysis could potentially distinguish between these cases by understanding what type of data is being hashed. A regex tool cannot. It sees md5( and fires regardless.

False Negative: The Indirect Injection

Regex also misses vulnerabilities that span multiple lines or involve intermediate variables. Consider:

String userId = request.getParameter("id");
String sql = buildQuery(userId);           // vulnerability travels through this function
Statement stmt = conn.createStatement();
stmt.execute(sql);                         // regex might not flag this

My regex looks for string concatenation at the point of execution. If the tainted input is assembled in a helper function and passed in as a completed string, the regex never fires. The vulnerability is invisible to pattern matching.

An AST tool with interprocedural taint analysis would follow the data through buildQuery() and flag the eventual execute() call correctly.

So Why Did I Choose Regex Anyway?

Three reasons.

1. Language-Agnostic by Design

AST parsing is inherently language-specific. Every language has its own grammar and its own parser. Python's AST looks nothing like Java's. Kotlin's is different again. JavaScript has multiple competing parsers with different behaviours across versions.

To support AST-based analysis across 12 languages — Python, Java, Kotlin, JavaScript, TypeScript, C#, Go, Ruby, PHP, Shell, YAML, Terraform — I'd need 12 separate parsing libraries, each with their own dependencies, version constraints, and maintenance requirements.

tree-sitter comes closest to solving this problem. It's a parser generator that provides a unified API across dozens of languages, and it's what tools like GitHub's code scanning use under the hood. But even with tree-sitter, you still need to write language-specific query logic to express what you're looking for in each language's AST structure.

Regex patterns, by contrast, can be written once and applied across any language where the vulnerable pattern looks similar in text form. Hardcoded AWS access keys follow the same format everywhere. JWT secrets look the same in any language. That's genuine value that regex delivers cheaply.

2. The Vulnerability Surface I'm Targeting

Not all vulnerability classes require deep analysis. Some are genuinely well-served by pattern matching.

Secrets detection — hardcoded API keys, passwords, connection strings, private key material — is almost entirely a pattern matching problem. The secret has to appear literally in the source code for it to be a finding. Regex is exactly the right tool.

- id: SEC-001
  title: Hardcoded AWS Access Key
  patterns:
    - regex: 'AKIA[0-9A-Z]{16}'
      confidence: HIGH

That pattern will catch a hardcoded AWS key in any language, in any file, instantly. AST analysis adds nothing here.

Misconfiguration detection — debug mode enabled, CORS wildcards, insecure session settings — is similarly pattern-oriented. These are usually single-line declarations that look the same regardless of context.

The injection and authentication categories are where regex struggles most. But even there, high-confidence patterns — direct string concatenation in SQL calls, algorithm: "none" in JWT configurations — catch a meaningful portion of real vulnerabilities.

3. Pragmatic Scope

I built this tool to learn application security deeply, not to compete with Checkmarx. Scope matters. A tool that actually ships with 28 working rules across 6 categories is more valuable than a tool that was going to have perfect taint analysis but never got finished.

The regex approach let me build a complete, functional, deployable tool. That's not nothing.

When This Choice Would Be Wrong

I want to be direct about the scenarios where choosing regex would be the wrong call.

If you're scanning a single language at scale, the language-agnostic argument evaporates. If you're only scanning Java — which is common in enterprise AppSec programmes — you should be using a Java AST parser or a tool like SpotBugs or SonarQube that understands Java's type system.

If you need to catch data flow vulnerabilities reliably, regex will miss too much. Injection vulnerabilities that travel through multiple functions, variables, or modules require taint analysis. The indirect injection example I showed earlier is not an edge case — it's the norm in real codebases.

If you're running this in a high-security environment where false negatives are more dangerous than false positives, the calculus changes. A false negative means a real vulnerability gets missed. In a financial services or healthcare context, that might be unacceptable.

If you're trying to replace a commercial SAST tool, you need AST analysis. There's no way around it. Tools like Semgrep (which uses a hybrid AST/pattern approach), Checkmarx, and Veracode achieve their accuracy because they understand code structure. Pattern matching is a starting point, not a destination.

The Hybrid Path Forward

The most pragmatic production approach is a hybrid — which is exactly what Semgrep does.

Semgrep's rule syntax looks like pattern matching but operates on the AST. When you write a Semgrep rule that matches cursor.execute($X + $Y), Semgrep isn't doing string matching. It's matching against the AST, which means it correctly handles whitespace, string formatting variations, and code structure in ways that regex cannot.

For my tool, the natural evolution would be to keep the YAML rule engine and regex patterns as the default layer, but add an optional tree-sitter AST pass for languages where it's available. The two approaches aren't mutually exclusive — they're complementary. Regex for speed and coverage, AST for accuracy on the highest-risk patterns.

That's the architecture note I left in the README:

For a production tool, layering in tree-sitter AST analysis per language would reduce false positives.

That's not hedging. That's honest engineering — knowing where your current approach has limits and documenting the path to improving it.

The Practical Takeaway

If you're building a SAST tool or evaluating one, here's how to think about the regex vs AST question:

Scenario	Right Approach
Multi-language scanning, broad coverage	Regex or hybrid (Semgrep-style)
Single language, high accuracy	AST-based analysis
Secrets detection	Regex — it's optimal
Taint/data flow analysis	AST — regex can't do this
CI/CD gate with low false positive tolerance	AST or hybrid
Learning how SAST works	Build both and compare

The "correct" approach depends entirely on your threat model, your team's language footprint, and how much false positive noise your developers will tolerate before they disable the scanner entirely.

A scanner that developers trust and actually use is more valuable than a theoretically perfect scanner that gets switched off after the first sprint.

The full source code, including all YAML rules, is at github.com/pgmpofu/sast-tool.

Next up: how I modelled the OWASP Top 10 into a YAML rule engine — and the thought process behind some of the trickier rules like JWT algorithm confusion and insecure deserialization.

I Built a SAST Scanner From Scratch — Here's Every Design Decision I Made

Patience Mpofu — Sun, 03 May 2026 13:18:49 +0000

When most developers want to scan their code for security vulnerabilities, they install Semgrep or Snyk and call it a day. I did the opposite. I built one from scratch.

Not because the existing tools are bad — they're excellent. But because I'm transitioning from 13 years of software engineering into application security, and I wanted to understand what a SAST tool actually is underneath the hood. What decisions go into building one? What tradeoffs do you make? What does "language-agnostic" really mean when you have to implement it yourself?

This is the story of those decisions. Some were obvious. Some I got wrong the first time. All of them taught me something.

What I Set Out to Build

The goal was a tool that could:

Scan source code across any language without needing language-specific parsers
Use a rule engine that non-engineers could extend without touching code
Produce output in three formats — terminal, JSON, and HTML — so it could fit into both human workflows and CI/CD pipelines
Fail builds when findings exceeded a configurable severity threshold
Handle false positive suppression with inline annotations That's not a toy. That's a real tool with real requirements. So let's talk about how I built it.

Decision 1: Regex Over AST (And Why I'd Make the Same Choice Again)

This was the most consequential decision in the whole project, and I want to be honest about the tradeoffs.

A proper SAST tool ideally parses code into an Abstract Syntax Tree (AST) — a structured representation of the code's meaning, not just its text. AST-based analysis can understand context. It knows that password on line 42 is a variable assignment, not a string literal. It can trace data flow. It can detect that user input on line 10 reaches an unparameterised SQL query on line 87 without being sanitised in between.

Regex can't do any of that. Regex sees text.

So why did I choose regex?

Because AST parsing is language-specific by definition. Every language has its own grammar, its own AST format, its own parsing library. Java's AST looks nothing like Python's. Kotlin's is different again. If I wanted to support 12+ languages — Python, Java, Kotlin, JavaScript, TypeScript, C#, Go, Ruby, PHP, Shell, YAML, Terraform — I'd need 12+ separate AST parsers, each with its own dependencies, its own quirks, its own maintenance burden.

Regex patterns, by contrast, can be written to match suspicious code constructs across any language where those constructs look similar in text form. SQL injection via string concatenation looks recognisably similar in Java, Python, and PHP. Hardcoded AWS access keys follow the same pattern everywhere. MD5 usage reads roughly the same in most languages.

The tradeoff is accuracy. Regex-based SAST has higher false positive rates than AST-based analysis because it can't understand context. It sees md5( and flags it regardless of whether it's being used for a password hash or a file integrity check.

My answer to this was confidence scoring on rules and inline suppression annotations. Rules can declare their confidence level (HIGH, MEDIUM, LOW), and developers can annotate lines with # sast-ignore or # nosec to suppress false positives with a documented reason. That's not perfect, but it's pragmatic — and it mirrors how production tools like Bandit handle the same problem.

If I were building a production-grade commercial tool, I'd layer in AST analysis per language using something like tree-sitter, which provides a unified API across dozens of languages. But for a portfolio project built to understand the domain? Regex got me 80% of the value at 20% of the complexity.

Decision 2: YAML-Driven Rules (The Best Decision I Made)

Every detection rule in the scanner is defined in a YAML file. Not in code. Here's what one looks like:

- id: INJ-001
  title: SQL Injection — String Concatenation
  description: >
    User-controlled input is concatenated directly into a SQL query,
    bypassing parameterisation and enabling SQL injection attacks.
  severity: CRITICAL
  category: INJECTION
  cwe: CWE-89
  owasp: A03:2021 - Injection
  languages: ["python", "java", "javascript", "php", "csharp"]
  remediation: >
    Use parameterised queries or prepared statements. Never concatenate
    user input directly into SQL strings.
  patterns:
    - regex: '(execute|query|cursor)\s*\(\s*["\'].*\+.*["\']'
      confidence: HIGH

Why is this the best decision I made?

Because it separates the detection logic from the engine. The scanner engine — the part that reads files, applies patterns, generates findings, produces reports — never needs to change when you add a new vulnerability category. You just write a new YAML file and drop it in the rules/ directory. The engine discovers it automatically on startup.

This is exactly how production tools like Semgrep and Nuclei work. Rules are data. The engine is infrastructure. Keeping them separate means:

Security teams can contribute new detections without needing to understand Python
Rules are version-controlled and diff-able like any other file
Rules can be reviewed in pull requests by people who've never written a line of the engine
Custom organisational rules can be maintained separately from the core ruleset I ended up with five rule files covering 28 rules across six categories: Injection, Secrets, Cryptography, Authentication, Misconfiguration, and Path Traversal. Every rule maps to a CWE identifier and an OWASP Top 10 category. That structure matters — it's the language that security professionals and auditors actually speak.

Decision 3: Three Output Formats From Day One

I could have built a tool that prints to terminal and called it done. Instead I built three output formats simultaneously: rich terminal output, JSON, and HTML.

This wasn't vanity. Each format serves a completely different consumer.

Terminal output is for developers running scans locally during development. It needs to be immediately readable, colour-coded by severity, and show exactly the file and line number of each finding. I used Python's rich library for this, which gives you nice bordered panels with colour-coded severity labels without writing a lot of custom formatting code.

JSON output is for machines. CI/CD pipelines, SIEM systems, dashboards, and any downstream tooling that needs to process findings programmatically. The JSON schema includes everything: finding ID, title, severity, category, CWE, OWASP reference, file path, line number, matched content, and remediation guidance. That's a schema a security team could ingest into Splunk or Elastic without modification.

HTML output is for stakeholders. Developers understand terminal output. Product managers and engineering leads don't. The HTML report is a self-contained file — no server required, just open it in a browser — with severity filtering and full remediation guidance. You generate it, you email it, anyone can read it.

The design principle here is that a security tool's effectiveness is limited by how well its output reaches the people who need to act on it. Building three output formats from the start wasn't over-engineering — it was thinking about the full workflow.

Decision 4: CI/CD Exit Codes and Configurable Severity Thresholds

This is where the tool goes from "interesting project" to "actually useful in production."

The scanner exits with code 1 when findings meet or exceed a configurable severity threshold. In practice:

# Fail the build on any HIGH or CRITICAL finding
- name: SAST Scan
  run: |
    docker run --rm -v ${{ github.workspace }}:/src \
      sast-tool /src \
      --fail-on HIGH

# Audit mode — run without failing the build
python main.py ./src --fail-on none

The --fail-on flag is the key design decision here. It lets teams adopt the tool incrementally:

Start in audit mode (--fail-on none). Get a baseline of your existing findings. Don't break anything.
Tighten to --fail-on CRITICAL. Only the most severe issues block releases.
Over time, tighten to --fail-on HIGH as the codebase gets cleaned up. This reflects something I learned from running Snyk against a production Node.js codebase: you can't go from zero security gates to blocking every high-severity finding overnight. The build will fail constantly and engineers will start disabling the check to ship. Incremental adoption with configurable thresholds is how security tooling actually gets embedded into teams.

Decision 5: Docker-First Distribution

The scanner ships as a Docker image. Local Python installation is an option, but Docker is the primary recommended path.

Why? Zero dependency hell.

Python dependency management is a known pain point. Different teams run different Python versions. pip install on one machine behaves differently on another. A tool that fails to install never gets used.

Docker eliminates this. One command, any machine with Docker installed, consistent results:

docker run --rm -v $(pwd):/src sast-tool /src

For CI/CD integration — which is where this tool matters most — Docker is even more natural. GitHub Actions, GitLab CI, Jenkins — they all run steps in containers. A Docker-first tool drops into any pipeline without configuration.

What I'd Do Differently

I'd add tree-sitter for at least two or three languages. Python and JavaScript are well-supported, and adding AST-based passes for those two languages would dramatically reduce false positives on the most commonly scanned codebases. The regex engine would remain the fallback for everything else.

I'd add a findings baseline. The first time you scan a legacy codebase, you might get 200 findings. That's not useful — it's noise. A baseline file that records the current state of findings and only alerts on new ones since the last scan is critical for real-world adoption. Snyk does this. I didn't build it.

I'd invest more in the HTML report. The current version is functional but basic. A proper interactive report with trend data across multiple scans, drill-down into individual findings, and a remediation progress tracker would make it genuinely compelling for security leadership conversations.

What Building This Taught Me

Understanding how SAST tools work made me a better consumer of them. When I run Snyk or Semgrep now, I have a much clearer mental model of what's happening under the hood, why certain findings are false positives, and what "confidence level" actually means.

The design decisions in a security tool aren't just engineering decisions — they're security decisions. Choosing regex over AST isn't just a technical tradeoff; it's a decision about your false positive rate, which is a decision about how much friction you introduce into developer workflows, which determines whether the tool actually gets used.

Building something from scratch is still one of the fastest ways to understand a domain deeply.

The full source code is on GitHub at github.com/pgmpofu/sast-tool. The rules are all in rules/, the engine is in sast/, and there's a vulnerable_sample.py you can use to test it immediately.

If you want to see it in action against real vulnerable applications, I wrote about that in my previous article.

Next up: the regex vs AST debate in depth — when pattern matching is good enough, and when it'll get you into trouble.

I Built a SAST Scanner from Scratch and Ran It Against 4 Famous Vulnerable Apps — Here's What It Found

Patience Mpofu — Wed, 04 Mar 2026 04:47:10 +0000

Static Application Security Testing (SAST) tools are a staple of any mature AppSec programme. Tools like Semgrep, Bandit, and SonarQube are used daily by security engineers to catch vulnerabilities before code ships to production. But how do they actually work under the hood?

As part of my transition from 13 years of software engineering into application security, I built my own SAST scanner from scratch in Python and ran it against four of the most well-known intentionally vulnerable applications in the OWASP ecosystem. This post covers what I built, how I tested it, and what the results tell us about real-world vulnerability patterns.

What I Built

The tool is a language-agnostic, regex-based static analysis scanner with a YAML-driven rule engine. The core design decisions were:

YAML rules over hardcoded logic. Every detection is a YAML file — no code changes required to add new vulnerability patterns. This mirrors how production tools like Semgrep work, and means a security team could extend the ruleset without touching the engine.

Language-agnostic by design. Rather than building AST parsers per language (which is how deeper tools work), the scanner uses regex patterns that fire across any file type. This trades some precision for breadth — it can scan Java, TypeScript, PHP, Python, Kotlin, Go, and more in a single pass.

Three output modes. Terminal output for quick scans, JSON for CI/CD pipeline integration (with configurable exit codes to fail builds), and an HTML report for sharing findings.

Docker-first. The entire tool runs as a container — no local Python environment needed. Mount your codebase, get a report.

The scanner covers 27 rules across five categories mapped to CWE identifiers and OWASP Top 10:

Injection (INJ): SQL injection, command injection, XSS, SSTI, LDAP injection
Secrets (SEC): AWS keys, hardcoded passwords, private keys, JWT secrets, database connection strings
Cryptography (CRYPTO): MD5/SHA-1 usage, insecure random, ECB mode, disabled TLS verification
Authentication (AUTHN): JWT algorithm confusion, insecure session cookies, timing attacks, IDOR
Misconfiguration (MISC): Path traversal, debug mode, XXE, unrestricted file upload, CORS wildcards, insecure deserialization

The full source is on GitHub: github.com/pgmpofu/sast-tool

The Test Targets

I chose four intentionally vulnerable applications maintained by OWASP — each written in a different language, each targeting a different slice of the vulnerability landscape:

App	Language	Files Scanned	Scan Duration
WebGoat	Java	562	6.70s
OWASP Juice Shop	TypeScript/Node.js	805	12.62s
DVWA	PHP	189	1.17s
NodeGoat	JavaScript/Node.js	34	1.49s

Results at a Glance

App	Critical	High	Medium	Total
WebGoat	31	61	0	92
Juice Shop	3	63	1	67
DVWA	0	12	2	14
NodeGoat	0	9	0	9
Total	34	145	3	182

182 findings across four codebases in under 23 seconds of total scan time.

WebGoat — 92 Findings (31 Critical)

WebGoat is a Spring Boot Java application built by OWASP specifically to teach developers about security vulnerabilities. It had the highest finding count by far, which makes sense — it's a structured learning platform with one lesson per vulnerability type.

SQL Injection was the dominant finding. The scanner flagged string concatenation in SQL queries across multiple lesson files. A representative example from SqlInjectionLesson6a.java:

query = "SELECT * FROM user_data WHERE last_name = '" + accountName + "'";

This is textbook SQLi — user input concatenated directly into a query string with no parameterization. The fix is straightforward: use PreparedStatement with ? placeholders. What's notable here is that the same pattern appeared in 8 separate lesson files, each demonstrating a different variant of the attack (blind injection, union-based, error-based).

Insecure deserialization showed up as Critical. In InsecureDeserializationTask.java:

new ObjectInputStream(new ByteArrayInputStream(Base64.getDecoder().decode(b64token)))

Java's ObjectInputStream is one of the most dangerous APIs in the language. Deserializing untrusted data with it can lead to remote code execution — this class of vulnerability was at the heart of the Apache Commons Collections exploit chain that affected thousands of Java applications. The scanner correctly flagged both the task file and the SerializationHelper utility class.

Command injection via Runtime.exec() was caught in VulnerableTaskHolder.java:

Process p = Runtime.getRuntime().exec(taskAction);

Passing unsanitized user input to exec() is equivalent to os.system() in Python — an attacker who controls taskAction can run arbitrary OS commands on the server.

Private key material hardcoded in source. The scanner found PEM key headers in CryptoUtil.java — a reminder that even educational codebases can demonstrate the exact mistakes they're teaching against.

Coverage verdict: Partial. WebGoat covers lessons across the full OWASP Top 10. The scanner did well on the categories it has rules for — SQL injection, deserialization, command injection, and cryptographic failures. However, several vulnerability classes present in WebGoat went undetected:

Vulnerability	In WebGoat	Scanner Detected	Gap Reason
SQL Injection	✅	✅	Regex matched string concatenation patterns
Command Injection	✅	✅	`Runtime.exec()` pattern matched
Insecure Deserialization	✅	✅	`ObjectInputStream` pattern matched
Hardcoded Private Key	✅	✅	PEM header pattern matched
XXE (XML External Entity)	✅	❌	Scanner has XXE rule but WebGoat's parser config is in XML files, not Java — rule needs expanding
Path Traversal	✅	❌	WebGoat's path traversal uses Spring's `@RequestParam` binding, not direct `open()` calls — SAST missed it
Broken Access Control / IDOR	✅	❌	Requires understanding of authorization logic — not detectable by regex alone
CSRF	✅	❌	No CSRF token rule exists in current ruleset
JWT Vulnerabilities	✅	Partial	`JWTHeaderKIDEndpoint` SQLi was caught; algorithm confusion attack was not
Insecure HTTP Communication	✅	❌	Runtime/config issue, not detectable in source code

OWASP Juice Shop — 67 Findings (3 Critical)

Juice Shop is a modern Node.js/TypeScript e-commerce application and the most widely used security training platform in existence. Its 805 files took the scanner 12.6 seconds — the largest codebase of the four.

The most interesting Critical finding was a private RSA key hardcoded in lib/insecurity.ts:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDNwqLEe9wgTXCbC7+RPdDbBbeqjdbs4kOPOIGzqLpXvJXlxxW8...

This is intentional in Juice Shop's case — it's used to sign JWTs as part of a challenge. But in a real application, committing an RSA private key to a public repository means every JWT the application has ever issued can now be forged by anyone who cloned the repo. This is exactly the kind of finding that would be Severity 1 in a real penetration test.

SQL injection appeared in the challenge fix files — specifically in codefixes/dbSchemaChallenge_1.ts. This is a meta-finding: Juice Shop includes intentionally wrong "fix" options as part of its challenge mechanic, and our scanner correctly identified that one of the proposed fixes still contained vulnerable code:

models.sequelize.query("SELECT * FROM Products WHERE ((name LIKE '%" + criteria + "%'...")

The bulk of findings (63 HIGH) were insecure random number generation — Math.random() used throughout data generation scripts. These are mostly false positives in context (seeding test data doesn't require cryptographic randomness), which is an important lesson about SAST tuning in practice. A production deployment of this tool would add # sast-ignore annotations or exclude data generation files from scans. SAST tools always require triage — raw finding counts are never the whole story.

Coverage verdict: Low — but not because the scanner is weak. Juice Shop encompasses vulnerabilities from the entire OWASP Top Ten and beyond, including categories that are fundamentally undetectable by static analysis:

Vulnerability	In Juice Shop	Detected	Gap Reason
SQL Injection	✅	✅	String concatenation in challenge files caught
Hardcoded Private Key	✅	✅	PEM header in `insecurity.ts` caught
Insecure Random	✅	✅ (mostly FP)	Correct pattern, wrong context — test data seeding
Broken Access Control / IDOR	✅	❌	Requires understanding which basket belongs to which user — dataflow, not regex
Broken Authentication	✅	❌	Logic flaw enforced at runtime, not visible in source
XSS (DOM-based)	✅	Partial	`innerHTML` rule fires on some cases; Angular template bindings missed
Security Misconfiguration	✅	❌	Express security headers are a runtime/config concern
NoSQL Injection	✅	❌	No NoSQL injection rules in current ruleset
Prototype Pollution	✅	❌	Requires AST-level analysis of object property assignments
SSRF	✅	❌	Requires taint tracking from user input to HTTP call

The most important gap here is the entire class of logic vulnerabilities — IDOR, broken auth flows, business logic abuse. These are the vulnerabilities that cause real breaches and they are essentially invisible to regex-based static analysis. They require DAST (dynamic testing against a running application) or manual review.

DVWA — 14 Findings (0 Critical, 12 High)

DVWA (Damn Vulnerable Web Application) is a classic PHP application. Its smaller codebase (189 files) and simpler architecture produced a tighter, more focused set of findings.

XSS via innerHTML assignment was the most frequent pattern, appearing 5 times in vulnerabilities/authbypass/authbypass.js. Each instance directly assigned user-controlled data to innerHTML — the canonical XSS pattern:

cell0.innerHTML = user['user_id'] + '<input type="hidden" ...>';

An attacker who can influence user['user_id'] can inject arbitrary HTML and JavaScript. The fix is to use textContent for plain text or sanitize with DOMPurify before any HTML rendering.

CORS wildcard was flagged twice in the API vulnerability module:

header("Access-Control-Allow-Origin: *");

A wildcard CORS policy allows any website to make cross-origin requests to the API. When combined with sensitive endpoints, this enables cross-site request forgery at scale.

One genuinely interesting false positive: the scanner flagged $password = "password"; in vulnerabilities/sqli/test.php as a hardcoded credential. It is technically a hardcoded password — but it's a test fixture, not an application secret. This illustrates a core challenge in SAST: the tool can't understand intent, only pattern. A mature AppSec workflow would suppress this with an inline comment and document the reasoning.

Coverage verdict: Moderate. DVWA has 14 named vulnerability categories. The scanner caught XSS and CORS-related issues, but missed the majority:

Vulnerability	In DVWA	Detected	Gap Reason
XSS (DOM, Reflected, Stored)	✅	Partial	`innerHTML` caught in JS files; PHP `echo` XSS patterns not in ruleset
CORS Wildcard	✅	✅	Wildcard header pattern matched
SQL Injection	✅	❌	DVWA's SQLi is in PHP — our PHP SQL injection pattern (`$_GET`, `$_POST` concatenation) missing from ruleset
Command Injection	✅	❌	DVWA uses `shell_exec()` and `system()` in PHP — no PHP command injection rule exists
CSRF	✅	❌	No CSRF token validation rule exists
File Inclusion (LFI/RFI)	✅	❌	PHP `include($_GET['page'])` pattern not in ruleset
File Upload	✅	❌	`move_uploaded_file()` without MIME validation — no PHP upload rule
Brute Force / Weak Session IDs	✅	❌	Runtime behaviour, not detectable statically
Blind SQL Injection	✅	❌	Same as above — PHP SQL patterns missing
CSP Bypass	✅	❌	Runtime/header concern

The DVWA results reveal a specific gap: the current ruleset underserves PHP. Most of DVWA's vulnerabilities are in PHP server-side code using functions like shell_exec(), include(), mysql_query(), and move_uploaded_file(). Adding PHP-specific rules for these functions would significantly improve coverage.

NodeGoat — 9 Findings (0 Critical, 9 High)

NodeGoat is a smaller Node.js application (34 files) that maps directly to the OWASP Top 10. Its low finding count reflects its size rather than its security posture.

All 8 code findings were Math.random() usage in financial contexts — generating stock quantities and fund amounts:

const stocks = Math.floor((Math.random() * 40) + 1);
const funds = Math.floor((Math.random() * 40) + 1);

In a real financial application, predictable random number generation for account values would be a significant finding. An attacker who can predict the seed could game the system. Here it's test data seeding, but the scanner correctly flags the pattern.

The ninth finding was particularly interesting — it came from package-lock.json, where a deprecated dependency's own warning message mentioned Math.random():

"deprecated": "Please upgrade to version 7 or higher. Older versions may use Math.random()..."

The scanner flagged the deprecation warning itself as a finding. This is a genuine false positive — useful as a demonstration that SAST tools scan all files indiscriminately unless you configure exclusions. In practice, package-lock.json and similar lockfiles should be excluded from scans.

What This Tells Us About SAST in Practice

Running the tool across four codebases surfaced some clear patterns worth highlighting for any engineer new to application security:

Injection vulnerabilities are everywhere, even in educational apps. SQL injection via string concatenation is one of the oldest vulnerabilities in existence — it was in the OWASP Top 10 when it was first published in 2003 and it's still there today. The fact that it appears across Java, PHP, and TypeScript codebases in the same scan demonstrates that it's a language-agnostic problem rooted in developer habit, not language design.

False positives are inevitable and manageable. Of the 182 findings, a meaningful portion are context-dependent: Math.random() seeding test data, hardcoded values in test fixtures, private keys that are intentionally public for training purposes. A SAST tool's job is to surface candidates for human review, not to replace it. The value is in the signal-to-noise ratio and the speed — 182 candidates across 1,590 files in 23 seconds.

SAST is most powerful as a prevention tool, not a detection tool. Every finding in these codebases was already known — they're intentionally vulnerable. The real value of SAST is catching these patterns before they reach a code review, not after they've been running in production. Embedding this kind of scanner as a pre-commit hook or CI/CD gate means developers get feedback at the moment they write the code.

Regex-based scanning has limits. Several real vulnerabilities in these apps weren't caught — NoSQL injection in NodeGoat's MongoDB queries, prototype pollution patterns, and some of the more subtle authentication bypass issues in DVWA. These require either AST-level analysis or semantic understanding of data flow that regex alone can't provide. Tools like Semgrep's taint tracking address this, and it's the natural next step for evolving this scanner.

What Would Full Coverage Require?

Across all four apps, a pattern emerges around three distinct gaps. Each requires a different technical approach to close.

1. Missing Rules (Fixable Now)

The simplest gaps — vulnerabilities the scanner could detect with regex but currently has no rule for. These are straightforward YAML additions:

Missing Rule	Target Apps	Example Pattern
PHP SQL Injection	DVWA	`mysql_query("SELECT * FROM users WHERE id=" . $_GET['id'])`
PHP Command Injection	DVWA	`shell_exec($_GET['cmd'])` or `system($_POST['input'])`
PHP File Inclusion	DVWA	`include($_GET['page'])`
PHP File Upload	DVWA	`move_uploaded_file()` without MIME validation
NoSQL Injection	NodeGoat, Juice Shop	`db.collection.find({$where: req.query.input})`
CSRF Token Absence	DVWA, WebGoat	State-changing forms/endpoints without token validation
Open Redirect	DVWA, Juice Shop	`res.redirect(req.query.url)` without validation
Server-Side Template Injection (PHP)	DVWA	`eval()` or `preg_replace()` with `/e` modifier

These could be added to the ruleset in an afternoon and would immediately improve detection on PHP codebases.

2. Taint Tracking (Requires Architecture Change)

Several missed vulnerabilities involve user input flowing through multiple functions before reaching a dangerous sink. For example, in NodeGoat:

// Input enters here (source)
router.get('/profile', function(req, res) {
  var userId = req.params.userId;

  // ...flows through several functions...

  // ...reaches the sink here
  db.collection('users').findOne({_id: ObjectId(userId)}, callback);
});

Regex can detect patterns at the sink (findOne with a variable), but can't verify whether userId actually came from user input without following the data flow across function boundaries. This is the core limitation of regex-based scanning.

What's needed: A taint analysis engine that tracks data from sources (HTTP request parameters, headers, cookies) to sinks (SQL queries, shell commands, file paths, HTML output). This is how tools like Semgrep's Pro engine, CodeQL, and Checkmarx work. Implementing this would require moving from regex to an AST-based approach using a library like tree-sitter for cross-language parsing.

3. Runtime/Logic Vulnerabilities (DAST Territory)

Some vulnerabilities simply cannot be found by reading source code. They require observing the application's behaviour at runtime:

Broken Access Control / IDOR — can only be confirmed by making requests as User A and observing whether User B's data is returned
Brute Force / Rate Limiting — requires actually sending repeated requests and observing the response
Weak Session IDs — requires generating multiple sessions and analysing their entropy statistically
Security Headers — requires making an HTTP request and inspecting the response headers
Business Logic Flaws — requires understanding the intended workflow and deviating from it

These are the domain of DAST tools (project #10 and #11 on the portfolio list) and manual penetration testing. No amount of SAST improvement will close this gap — it's a fundamental constraint of static analysis.

The Takeaway: SAST + DAST + Manual = Defence in Depth

The industry consensus is that no single tool type provides complete coverage. The standard approach in mature AppSec programmes is layered:

SAST (this tool)           → Catches code-level flaws early, in the IDE or CI pipeline
SCA (project #3)           → Catches vulnerable dependencies
DAST (projects #10, #11)   → Catches runtime behaviour, logic flaws, config issues  
Manual Review              → Catches everything that requires human judgement

Each layer has different strengths and blind spots. The goal isn't a single perfect tool — it's defence in depth across the entire SDLC.

Running It Yourself

The tool is open source. To scan any codebase:

# Clone the scanner
git clone https://github.com/pgmpofu/sast-tool
cd sast-tool
docker build -t sast-tool .

# Scan any project
docker run --rm \
  -v /path/to/your/project:/src \
  -v $(pwd)/reports:/reports \
  sast-tool /src \
  --exclude "node_modules" "build" "dist" \
  --format html \
  --output /reports/report.html

The HTML report includes severity filtering, CWE/OWASP references, and remediation guidance for every finding.

Contributions and additional rule PRs are welcome — particularly for Terraform misconfiguration patterns, Kubernetes YAML security issues, and deeper Java deserialization gadget detection.

This is part of a series documenting my transition from software engineering into application security. Next up: building a dependency vulnerability auditor that cross-references your pom.xml, build.gradle, and package.json against the NVD and OSV databases.

DEV Community: Patience Mpofu

Why I Built an ML-Powered Secrets Detector Instead of Just Using Regex

The Two Failure Modes of Existing Tools

Failure Mode 1: The Regex Gap

Failure Mode 2: The Entropy False Positive Flood

What ML Adds: Context-Aware Classification

The Feature That Changed Everything: Key Name Risk

Why Random Forest, Not a Neural Network

Synthetic Training Data: The Ethical Constraint

The Three-Layer Detection Architecture

What This Actually Catches

Where This Fits in a Security Programme

What Building a SAST Tool Taught Me About AppSec That 13 Years of Software Engineering Didn't

I Knew How to Write Secure Code. I Didn't Know Why It Was Secure.

Security Is an Adversarial Discipline

Tools Are Amplifiers, Not Answers

False Positives Taught Me About Risk Tolerance

The Gap Between Writing Secure Code and Finding Insecure Code

What I'd Tell Someone Starting This Transition

Where This Goes Next

False Positives in SAST — How I Built Suppression Into My Scanner and Why It Matters

What a False Positive Actually Costs

The Three Sources of False Positives

1. Context-Blind Pattern Matching

2. Safe Framework Usage That Looks Dangerous

3. Test and Configuration Code

What I Built: The Suppression System

Inline Suppression Annotations

Suppression With Justification

The Suppression Inventory in JSON Output

Confidence Levels as Pre-Emptive Noise Reduction

The Suppression Review Process

Tuning Rules to Reduce Systemic False Positives

The False Negative Trade-off

What a Healthy Suppression Profile Looks Like

The Bigger Point

The Adoption Trap to Avoid

Writing Custom SAST Rules for Vulnerabilities Your Scanner Doesn't Cover

Before You Write a Rule: The Four Questions

The Rule Format (Quick Reference)

Rule 1: Java — Spring @Transactional on Public Methods Exposing Sensitive Data

Rule 2: Node.js — child_process.exec with Template Literals

Rule 3: Organisation-Level — Internal Audit Logger Bypass

Multi-Pattern Rules: Increasing Coverage Without Losing Precision

Testing Your Custom Rules

The Broader Point: Rules as Institutional Knowledge

How I Modelled the OWASP Top 10 Into a YAML Rule Engine

The Rule Schema

How the 28 Rules Map to OWASP

Deep Dive: The Rules That Required Real Thought

AUTHN-001 — JWT Algorithm None Attack Vector

MISC-006 — Insecure Deserialization

AUTHN-004 — Timing Attack in Auth Comparison

CRYPTO-005 — ECB Mode Encryption

MISC-005 — CORS Wildcard / Reflected Origin

The Categories I Deliberately Left Out

What Mapping to OWASP Gave Me

Why I Chose Regex Over AST Parsing in My SAST Tool (And When That Would Be Wrong)

First, What's the Difference?

The Regex Approach

The AST Approach

What Regex Gets Wrong

False Positive: The Innocuous MD5

False Negative: The Indirect Injection

So Why Did I Choose Regex Anyway?

1. Language-Agnostic by Design

2. The Vulnerability Surface I'm Targeting

3. Pragmatic Scope

When This Choice Would Be Wrong

The Hybrid Path Forward

The Practical Takeaway

I Built a SAST Scanner From Scratch — Here's Every Design Decision I Made

What I Set Out to Build

Decision 1: Regex Over AST (And Why I'd Make the Same Choice Again)

Decision 2: YAML-Driven Rules (The Best Decision I Made)

Decision 3: Three Output Formats From Day One

Decision 4: CI/CD Exit Codes and Configurable Severity Thresholds

Decision 5: Docker-First Distribution

What I'd Do Differently

What Building This Taught Me

Rule 1: Java — Spring `@Transactional` on Public Methods Exposing Sensitive Data

Rule 2: Node.js — `child_process.exec` with Template Literals