The problem here was never a missing signal. Every fact needed to understand this was already sitting in the logs the customer's tools had produced. The gap wasn't visibility — it was context across signals: the edge knew one thing, the application knew another, and nothing had put the two together into a single conclusion and a decision.
What we found
A wave of automated probes hit one customer's application — the generic, constant background scanning every internet-facing app receives. Their tooling had flagged 12,759 of these requests. On the dashboard: one undifferentiated pile of "suspicious traffic," all of it apparently failed, all of it apparently handled.
CodeMinder read the ALB and WAF signals together — the actions_executed value,
the target status, the processing time, the request paths — instead of the response code
alone. Read that way, the single pile splits cleanly in two, and the two halves could not be
more different.
None of the 5,590 succeeded. The specific paths they probed — generic admin-panel targets like
/manager/html and /manage/account/login — simply don't exist on this
application, so each request failed on its own. That sounds like a happy ending. It isn't.
They didn't fail because a control stopped them. They failed because the door they tried happened not to exist. Nothing in the observed edge controls stopped these probes from reaching the application — which means the next probe would be treated the same way if it targeted a path that did exist.
The evidence was already there
A 403 or a 404 tells you nothing on its own about where it
happened — both can come from the edge, and both can come from the application after the request
has already arrived. When it's app-level — a populated target IP, real processing time, a real
target_status_code — the payload reached your backend instances. When the edge
handled it, it never did.
The evidence wasn't missing. The ALB and WAF logs already contained every signal needed to tell those apart — nobody had correlated them. A sophisticated engineer could find this by querying those logs directly. The question was never whether the data existed. It was whether anyone would turn it into a conclusion and an action.
What was actually missing
The customer's question was never "can I tell whether this one 403 came from WAF." The tools can answer that. The question was: we have 12,759 suspicious requests — what does this pattern mean for our security posture, and what should we do about it? That's a different problem, and it's the one nobody's dashboard was answering.
Every one of those steps except the last is a synthesis step, not a detection step. The facts were in the logs. Turning them into 5,590 requests reached the app → this is an exposure pattern → here is the WAF rule that closes it is the work — and it's engineering decision intelligence, not security monitoring.
Your security tools tell you what happened at the edge. CodeMinder connects that with what happened in the application.
The problem isn't a lack of signals. Every fact was already in the logs. What's missing is the layer that reads them together — the edge and the application at once — and turns the pattern into one thing to do.
What this means for you
We're not competing with your WAF, and we're not claiming to see what it can't. AWS and Cloudflare will tell you, accurately, what they blocked. What they don't do is reach across the edge and the application, read the combined pattern, and hand you the engineering action it implies. That layer — above the individual tools, not replacing them — is the gap.
A pile of blocked-and-failed requests reads as one word: handled. Some of it genuinely is. Some of it only looks handled because the attack happened to miss. The signals to tell those apart already exist in your stack, scattered across systems. CodeMinder is what puts them together and tells you which is which — and what to do about the difference.