DEV Community: Keelen Carrera

From Backend to Breach-Aware - Part 1: My CI Said "No Leaks Found." I Verified It Anyway.

Keelen Carrera — Tue, 13 Oct 2026 19:59:11 +0000

Continuing from the part of my series that explains the program that I helped create with a team of developers, here I pressed forward with my discovery into software engineering and cybersecurity, where I wired three security scans; dependency (SCA), static analysis (SAST), and secrets, into GitHub Actions for a codebase I'd already hand-scanned once. All three came back clean, and that should have been the end of it. Instead, I made myself answer a harder question: does "no leaks found" actually mean no leaks exist, or does it just mean the scanner didn't find any the way it's currently configured? We ought to be aware that these are not the same claim, and treating them as interchangeable is how a real gap survives behind a passing pipeline.

Testing the scanner instead of trusting it

I ran two constructed AWS-key test cases through gitleaks to see whether its detection actually behaved the way I assumed.

The first was AWS's own documentation placeholder, AKIAIOSFODNN7EXAMPLE. It didn't get flagged, which was by design. Gitleaks' default config carries a rule-level allowlist that exempts any match ending in EXAMPLE, a deliberate carve-out for AWS's own docs. This was worth knowing, but overall not alarming on its own.

The second was a key I fabricated myself, AKIAABCD1234EFGH5678. This one should have tripped the AWS-specific rule. Instead, it was only caught by the generic generic-api-key rule. This was a real signal that something was off. Digging into the why led somewhere I didn't expect: this repo's CI, using gitleaks-action@v2 with no GITLEAKS_VERSION pinned, was silently running gitleaks 8.24.3. That version predates a regex-tightening fix (merged 2025-05-27) that restricts the AWS key charset to match how AWS actually encodes tokens. Checking the Action's own source confirmed the root cause: both v2 and current v3.0.0 hardcode the same fallback version string. As a result, the Action's major version tag has nothing to do with which gitleaks binary actually runs underneath it.

The honest version of the finding isn't "we were about to leak an AWS key, and gitleaks would've missed it"; the prefix regex was actually looser, so that specific miss didn't happen. The real exposure was quieter and worse: over a year of unrelated rule improvements, new token formats for entirely different services, that this pipeline had never picked up, with nothing in place that would have surfaced it short of deliberately going and checking. I fixed it by pinning the Action to an exact tag and setting GITLEAKS_VERSION explicitly, then verified against a live CI run showing the correct version and a clean scan against the actual diff, not just "trust the new config"; I confirmed it did what it was supposed to.

The mistake that shipped anyway

The same pull request that carried this fix also carried something that should never have reached main: a deliberately vulnerable test fixture, an eval() on unsanitized input, a pinned-vulnerable dependency, a fake AWS key which was built specifically to confirm the CI jobs actually fail on bad input. That commit got merged anyway, with 2 of the 3 security jobs failing. GitHub allowed it because this repo had no required-status-check branch protection on main; nothing automated was actually gating the merge button. I only caught it by manually diffing the branch against main before treating the PR as done. Fixed with a straight revert, and all three jobs are green again in the corrected state. After the fix, I decided to leave that mistake in the write-up instead of quietly cleaning the history, because "diff the PR before you trust it" is a more convincing demonstration of the whole point than any scanner finding above it. Also, it exposed a real, still-open gap: no required checks on main at all.

When a clean SAST result isn't a gap, either

This is the same fixture, but a different tool: semgrep reported zero findings on a file containing a literal eval(userInput) call. Before assuming that was a miss, I pulled the actual community rule (eval-detected) and ran it locally against five constructed variants. The pattern that emerged: semgrep performs constant propagation before matching, so when userInput is assigned a literal string and never reassigned, eval(userInput) resolves to the equivalent of eval("literal"), which the rule's own exemption is written to treat as safe, deliberately, since a hardcoded literal isn't attacker-controlled. My test fixture's shape happened to land exactly on the one form of "bad eval" this rule is built to wave through. Not a tool gap, not a misconfiguration. It was a lesson that a hand-built adversarial test case needs the same scrutiny as a real one before its result counts as verification.

The actual takeaway

So, none of these is really about gitleaks or semgrep specifically. It's that a passing CI job is a claim, not a fact, and claims are worth checking against the thing that actually produced them: the rule source, the pinned tool version, and the diff that got merged. These all were before they get treated as evidence of anything. That standard doesn't stop at the code under test; it applies to the pipeline testing it as well. It's also the same lesson I first ran into on a much smaller scale, building this app's inventory logic in the first place. A response coming back successfully and a response coming back correct turned out to be the same distinction, just at a different layer. (That story's Part 0 of this series, if you want the origin.)

Full technical write-up with commit links: product-security-labs. Target codebase: smart-kitchen-mgmt (original team project).

From Backend to Breach-Aware Part 0: The Router That Was Built

Keelen Carrera — Tue, 08 Sep 2026 21:04:32 +0000

Dine Flow was a six-person cohort project, a restaurant inventory and order-management platform, built in about six weeks. Six people means six sets of hands in the codebase, and I want to be specific about which hands built what, rather than let a team project blur into a vague personal credit. My piece was the Express/API backend: the routers and the backend logic for stock, menu items, and orders. The strongest, most fully-owned piece of that work was the stock router, so that's what this is actually about.

What the stock router does

The stock router (Express + TypeScript, backed by Prisma/PostgreSQL) manages the inventory that everything else in the app depends on; every ingredient a kitchen has on hand, tied to expiration dates, suppliers, and the orders that consume it.

GET / returns the full ingredient/stock list with nested details, everything a kitchen manager needs to see current inventory at a glance. GET /: id returns a single stock item plus its associated ingredient name. POST / is where the real logic lives: it creates a new stock order and calculates an expiration date from the ingredient's shelf life, then branches depending on whether that ingredient has a supplier API URL on file. If it doesn't, the route creates the stock record and a matching expense record directly. That branch was part of my work. If it does, the route fires an automated reorder request to the supplier's API instead.

Inventory doesn't just sit static, either. Placing an order through the orders router automatically decrements the relevant stock, and stock can also be adjusted manually outside the order flow through the same router. The other deliberate choice here: PUT /:ingredient creates a new one, since every delivery is its own batch with its own expiration date.

A bug that changed how I read "it's fixed"

Early on, the GET /: id endpoint had a bug that's stuck with me since: requesting a single stock item was returning the entire stock table instead of the one item asked for. The response wasn't actually an error; it was a 200 with data in it, which is exactly the kind of result that's easy to glance at and assume is fine. Tracing it back, the route wasn't actually referencing the ID variable it should have been keying off of; once I mapped it to the correct field (Prisma's findUnique against the actual stock ID), it returned exactly what was requested. It's a small bug, but it's the first time I really internalized that a response coming back successfully and a response coming back correct are two different claims, and only one of them is worth trusting without a second look. That instinct has followed me directly into the security-focused work I do now.

What I verified, and what I didn't

Testing here was manual, hitting endpoints through VS Code's Thunder Client and watching browser console output during integration testing with the frontend. That's a full gap, and it's narrower on purpose: this piece is an honest account of the backend logic that was written.

One more honest note, since the whole point of this post is not trusting a clean-looking response: the fix I described above only covers the wrong-ID bug. GET /:id still has a commented-out 404 check as of today. Request an ID that doesn't exist, and it returns a 200 with null data instead of an error. Same failure shape as the bug this post is about; it is still sitting there to be fixed later.

Why I went back

That GET /: id bug is the actual reason this became a series instead of a single post. A clean 200 hiding the wrong data is a very specific kind of lie, and is not necessarily an error. It's a result that looks fine until you check what's actually in it. Months later, I went back into this exact codebase and asked a different version of the same question: "Is this actually secure?" and "If I were to place scanning methods throughout the development process, what would it return?" A scanner reporting zero findings is the same shape of claim as an endpoint returning a 200, technically true, and not automatically the same thing as correct, or safe. That's where this series actually goes next: I wired dependency, static-analysis, and secrets scanning into this app's CI pipeline, then caught the pipeline itself lying to me differently. That will be Part 1.

Dine Flow: github.com/allaboutmike/smart-kitchen-mgmt (original team repo). My fork, with later scan/remediation work: github.com/Keelen-Carrera/smart-kitchen-mgmt.