Source code penetration testing has always been the most thorough form of security testing there is and, candidly, also the slowest. That’s why many organizations save it for their high-stakes systems instead of running it everywhere. That’s starting to change.
From the Perspective of Matt Zamat, OnDefend Lead Application Penetration Test
Where the Reading Bottleneck Hits Hardest
I recently wrote about how OnDefend’s red teams use AI across the offensive workflow, and it ended up being our most-read post of the month. The point of that blog was exposing the tedious part of every offensive security teams job, reading.
Reading disassembly, reading decompiled mobile code, reading traffic across a hundred endpoints to find the one that handles authorization a little differently than the rest.
Now let’s talk about where that plays out most: source code analysis. If reading is the bottleneck, then the engagement where a client hands us the actual source code, hundreds of thousands of lines of it, is the one that typically kept most of us up at night (literally). It’s also the one where AI has made the biggest difference.
What Black-Box Testing Can’t Reach, Source Code Can
Most penetration tests are black-box or gray-box. We approach your application the way an outside attacker would, from the edge, with no special access, working with only what we can see. That’s a useful simulation, and for plenty of engagements it’s the right call.
It also has a built-in blind spot. Black-box testing can only find what it can reach from the outside in the time it has. Think about a bug that only fires after a specific sequence of five states, or an authorization check that is right on 19 endpoints and quietly missing on the 20th, or a hardcoded credential sitting in a config file that never produces anything visible on the wire. None of those show up from the outside.
An attacker with unlimited time might trip over them eventually. A tester working against a fixed deadline usually will not.
Source code access takes that blind spot away. When we have the code, we aren’t guessing at how your authentication works, we’re reading it. We aren’t assuming an input gets sanitized, we’re looking at the exact function that does or does not sanitize it and tracing every path that reaches it. We end up finding the things black-box testing can’t get to, and we find them with certainty instead of a hunch.
What Source Access Turns Up
Our team of testers reviews billions of lines of code every year, these are the categories that personally have seen continuously showing up in breach reports. They’re invisible from the outside and obvious the moment you read the file.
Hardcoded Secrets
API keys, database credentials, signing keys, and tokens committed straight into the source or baked into a build. An outside attacker has to catch one in transit or find where it leaked. When you have the code, it’s sitting right there on the line.
Broken Authorization Logic
The endpoint that confirms you’re logged in but never checks who you actually are. From the outside it looks like every other endpoint that returns data. In the code, the missing check is sitting right next to the 19 that got it right.
Dead and Dangerous Code Paths
Debug routes, backdoored admin functions, staging logic that was never supposed to ship. An attacker has to go find the door. With the source code, we’re reading the blueprint.
Injection Traced from the Source
Instead of firing off thousands of payloads and hoping one lands, we follow untrusted input from where it enters to where it gets used. We can tell whether the sink is exploitable before sending a single request.
None of this is new. Source review has been the most thorough kind of testing in the industries existence, nobody is arguing with that, the problem was that it took foreverrrr.
Why Source Review Was Rare, and Why That’s Changing
A modern application is hundreds of thousands of lines of code, sometimes millions, spread across dozens of files, frameworks, and dependencies. A person reading all of that line by line is the most thorough tester on the team and also the slowest one. That’s why source-code-enabled testing has usually been reserved for the highest-stakes systems and the biggest budgets. The value was obvious. The hours were the problem.
This is the same bottleneck discussed in my last post, just in its most concentrated form. Source review is reading and nothing but reading, which is exactly why it gains the most from putting AI in the loop.
Here’s how it works in practice. We point AI at the codebase, and it reads the whole thing, not a sample, not just the files someone had time for, all of it. It flags every hardcoded secret, every place untrusted input flows into a dangerous function, every authorization check that doesn’t match its neighbors, every dependency with a known CVE. It traces data flow across files faster than anyone can scroll. Work that used to eat up 60-70% of an engagement now takes a fraction of that.
Then our testers do the part only people are good at. AI hands us a candidate and says this looks like a missing authorization check. From there a human decides whether it’s real, whether it’s actually reachable, whether it affects anything downstream, and whether it chains into something worse.
AI is great at pointing you at the thing worth a second look and no help at all in giving context for what that thing means. That judgment call is the job. It always has been. We’ve just stopped burning the whole day getting to it.
You No Longer Have to Trade Depth for Speed
For most of this industry’s history, you’ve had to choose between fast, thorough, and cheap, and you only ever got two of the three. Source code review was the thorough one, and you paid for it in time and budget. So, most organizations saved it for their most important systems and ran black-box tests on everything else, treating the blind spots as the price of covering more ground.
That trade-off is falling apart. Once AI takes over the reading, source-enabled testing stops being the slow, expensive, once-a-year exercise you save for the one system you can’t afford to get wrong. It turns into something you can run across your whole portfolio on a regular schedule at a cost that actually makes sense. You get the deepest testing we know how to do on a turnaround that fits a release cycle instead of a fiscal year.
For a buyer, this is pretty direct. If you’re paying for a penetration test and your provider can work from source but is still doing it the slow way, reading whatever they have time for and sampling instead of covering, then you’re paying for the blind spots. You’re getting last decade’s depth on last decade’s timeline.
The Other Side Is Already Reading Your Code
I made this point in the last post too, and it matters even more here. Attackers don’t need your repository to get value out of these tools. The moment they get a foothold, whether that’s a leaked credential, an exposed bucket, a compromised dependency, or a decompiled mobile app, they can point the same AI at whatever code they’ve gotten hold of and have it read every line looking for the next move. They aren’t waiting on budget approval or rationing the review to the systems that matter most. They’re reading all of it.
The Bottom Line: Combining AI Speed with Human Expertise
Source code review has always been the deepest test we as a pentester can run, it was just slow. Which is why it only ever got used on the systems you really can’t afford to get wrong. AI handles the reading now but not the judgment, figuring out what’s real and actually reachable is still the job. The pentester is now the orchestrator, or a conductor if you want to look at it like that. The AI’s are confused and useless without the conductor, which provides guidance and corrections. Theres no reason source code review should be a special occasion test anymore, especially when attackers are already reading code the “same way”.
As far as we’re concerned, the deepest test we know how to run should be the standard one.
Ready to See What a Source-Code-Enabled Pen Test Surfaces?
That combination of AI-powered source code review paired with hands-on expert validation is what source-code-enabled penetration testing looks like in practice. If your last source code penetration testing engagement only covered what there was time to read, it’s worth a conversation.
OnDefend’s Source-Code-Enabled Penetration Testing pairs full-codebase AI analysis with hands-on expert validation to find what black-box testing can’t, and to get it to you on a timeline that fits how you actually ship.
