Teaching a black-box pentester to look inside the box

For its whole (short) life, my scanner has worked from the outside. It attacks the running application the way a real attacker would, with no access to the source, and reports what it can prove by observation alone. That's what black-box means, and it's the honest way to test something: you only claim what you could actually make happen from the outside.

But there's a limit to outside-in. The scanner can tell a customer "you have an IDOR on this endpoint." It can't tell them where in their code that IDOR comes from, because it has never seen their code. And for a small dev team without a security person, "where does this come from and how do I fix it" is the entire hard part.

The offensive side of security tooling is crowded right now. AI has made finding vulnerabilities cheap. The defensive side, the part that connects a finding to the fix, is still mostly manual. My customers started asking me to close that gap.

So the scanner learned to look inward.

The shift

After a black-box scan finds something, the scanner can now pull the customer's source, find the specific file and line that produced the vulnerability, and put it in the report. "IDOR on /api/orders" becomes "IDOR on /api/orders, caused by this code here," with a link straight to the line.

That's a real change in what the tool is. It attacks from the outside to find what's real, then reads from the inside to explain where it lives. The two perspectives check each other, which turns out to matter more than I expected.

Looking inward means holding something you shouldn't keep

Source access is the most sensitive thing I can ask a customer for, so the design assumes it and minimizes it.

A separate broker holds the credentials. The scanner never sees them. When it needs source, it gets a short-lived, read-only token scoped to one repository, reads one pinned commit, and purges the code the moment the attribution pass finishes. If the scanner were compromised tomorrow, it holds no credential that outlives a scan and no copy of anyone's source. The access is real enough to be useful and constrained enough to be safe.

Not every bug has a line of code

The most interesting part was the findings that have no causal line at all.

A missing security header isn't caused by any line of code. Neither is a weak TLS setting, or an absent rate limit at the edge. There's nothing to point at, because the problem is an absence, not a statement.

But the fix still has a home: the infrastructure config that manages that layer. So the tool now separates two questions that sound like one. Where is the bug, and where does the fix go. When there's a causal line, it points at the cause. When the cause is an absence, it points at the infrastructure where the fix belongs, and it labels that clearly so a customer never reads "here's where the fix goes" as "here's the bug." Being honest about the difference is the whole point.

Where this is

It's live. I've run the full pipeline on a real customer, attributed their findings to their actual repositories, and delivered a report with links straight to the code.

What's still ahead is the last step: the tool telling you where the bug is, and then offering to fix it. Right now it closes the distance between a finding and its cause. The next thing it should do is close the distance between the cause and the patch.

The offensive half of this market is crowded. The half that closes the loop is still wide open.