No scanner finds everything: broken access control, business logic and the limit of automated analysis
Why the risk class ranked first in the OWASP Top 10:2025 is also the one a scanner sees least well, where exactly pattern matching stops, and which check takes over what has no pattern: the penetration test as the counterpart of the continuous scan.
What a scanner sees
A code scanner works with patterns and known lists. A password in source text has a recognisable shape. A library with a known flaw is in a database. An input that flows unchecked into a database query follows a recognisable structure, and so does a call that assembles system commands from user input. For these classes a scan on every commit is the right tool, because it finds them as they appear and, properly assessed, documents them with a date.
Missing access checks belong here too, but only in a narrow form: an endpoint reachable without any authorisation check stands out. That is the part of broken access control that patterns capture. It is not the part that does the most damage in practice.
Why number one on the Top 10 stays partly invisible
Broken access control sits at number one in the 2025 edition of the OWASP Top 10. The class covers far more than an unprotected endpoint. It covers the case where a check exists and is still wrong: the user is verified, but not whether the requested record belongs to them. The employee may see invoices, but only those of their own site, and the software never asks about the site. The customer may change their contract, but not the price, and the field is hidden in the form instead of locked on the server.
For every one of these cases there is code that performs an access check. The scanner sees the check and is satisfied. Whether the check asks the right question is written in no pattern; it is written in the business model. That is why our code security page states that business logic errors escape automated analysis, and why we do not treat that as small print.
The second limit: design
Beside business logic there is a second class of flaw without a pattern: decisions taken before the code. Whether a component should be reachable directly from the network at all. Whether two services should share one database user. Whether a token meant to last an hour in fact never expires, because nobody specified that it should. In all these cases the source text is flawless as far as the scanner is concerned. The flaw lies in what the source text implements.
Add to that what every scanner does in reverse: it also reports findings that are not exploitable in the specific case. A person assessing each finding keeps those false positives out of the report. That person does not, however, make the scanner see what has no pattern.
What the penetration test takes over
A penetration test starts from the outside. It takes the running system as a whole, network, configuration, permissions and people included, and tries to get through. A tester logged in as user A who wants to see user B's invoices simply tries. No pattern is needed, only the business question. That is exactly why a good test finds the flaws the scan looks past, and exactly why it finds them only on the day of the test.
The test itself is not something we award to ourselves, for a reason: whoever runs the scan should not also be the one certifying that nothing slipped past it. Our role sits before and after the test. Before: settling whether a test is even the right instrument right now, and handing you the criteria for comparing providers. After: turning the report's findings into closed actions. More on our penetration testing page and in the article penetration test or vulnerability scan.
How the two work together
The division of labour is simple once it is spelled out. The scan keeps the pattern-shaped classes of flaw out of the code continuously and documents that with a date: secrets, vulnerable dependencies, unsafe patterns, unprotected endpoints. The test checks periodically whether the controls that exist ask the right question, and whether the design holds. A company that only tests has a year without checks between two dates. A company that only scans has half of number one in view.
For evidence that means: an auditor who wants to see a pentest will not accept a scan report as a substitute. And an auditor who wants to see vulnerability management in development and maintenance under Section 30 BSIG will not accept an annual test as proof of the process in between.
Frequently Asked Questions
Does the CAVRIX scan find broken access control?
The part with a pattern, yes: endpoints without any authorisation check and known unsafe constructions. The part without a pattern, whether an existing check asks the right business question, no scanner finds. The penetration test is the tool for that.
Why do you state this limit so plainly?
Because evidence pretending the scan covers everything would be wrong in an audit or after an incident. We would rather write in advance what the scan cannot do than explain afterwards why something slipped through.
Does CAVRIX offer penetration tests?
No, and deliberately so: the party running your scan should not be the party grading it. A specialised tester does the test. We help you decide if one is due, compare the offers, and work the report down to closed findings once it lands.