Sonar moves the pen tester's access-control checklist into the build pipeline

Picture the first failing build. The pipeline stops on an account settings endpoint because a member role can change another member's email address: the role check runs after the write instead of before it. No rule fired on a dangerous function, because nothing in that code looks wrong on its own. The reviewer's first job is not fixing code, it is finding out whether anyone ever wrote down what that endpoint was supposed to allow.

Sonar's own framing draws the line honestly. Khasriya told devops.com that deterministic scanners are good at injection, unsafe data flows and insecure patterns, and that some vulnerabilities simply are not detectable in code ^[6]; a privilege escalation, he said, becomes visible only once you understand how the code is meant to function ^[7]. Hold the two lists side by side and none of the three categories Hunter targets is one the deterministic list covers ^[11]. That is a real coverage gap. It is also a gap most teams already had a line item for, because the same categories are the ones a penetration test was booked to cover ^[3].

The delta worth planning around is cadence and the cost of being wrong. A false positive from a rule engine is a suppression comment with a rule ID next to it. A false positive about intent is a conversation between a security engineer and the service owner about what the product is supposed to do, and the devops.com writeup carries no false-positive rate, no benchmark and no pricing to size that load with ^[9]. Attribution sharpens it further: the agent can name the developer who wrote the code ^[10], so a probabilistic finding arrives on a pipeline with somebody's name attached to it.

Two questions decide whether this belongs on a gate in your repo, and they make a serviceable grid. First axis: is the intended behaviour written down anywhere, in a role matrix or an authorization spec? Second axis: does a finding come with something a human can reproduce, a request that demonstrably does the thing it should not?

Written intent plus reproduction is the only cell where blocking a build is fair, because the argument is settled before the developer sees it. Reproduction without written intent belongs in an advisory queue routed to the service owner, and the useful output is a specification, not a patch. Written intent without reproduction is a design review on a weekly rhythm, not a pipeline event. Neither one, and a gate makes the security team the arbiter of undocumented behaviour, which is a slow way to lose the pipeline's credibility.

The urgency case rests on Khasriya's claim that exploitation windows have collapsed to hours ^[8], set against the older rhythm devops.com describes, where a team spent a few hours a month producing a patch that might not deploy for months ^[12]. Both can be true and still leave a team in the bottom-left cell of that grid. Where the answer to the first question is "nowhere", the honest early value of an agent like this one is a written account of what the application actually permits, and the gate comes later.