The Conventional Wisdom
Run your SAST and DAST tools, fix what they flag, and you've secured your application. The dashboard shows green. The compliance report looks solid. Your automated security pipeline catches vulnerabilities before they hit production.
This is how many security teams measure application security posture. It's efficient, scalable, and produces metrics that executives understand. The tooling industry has built an entire ecosystem around this assumption: if the scanner doesn't find it, it probably isn't there.
Why It's Incomplete
Automated scanners are excellent at finding what they're programmed to find. They'll catch SQL injection, cross-site scripting, and authentication bypasses. But business logic flaws are subtle mistakes in an application's design or workflow, and scanners can't detect them because they don't understand what your application is supposed to do.
Here's the gap: your scanner knows that SELECT * FROM users WHERE id = ${userInput} is dangerous. It doesn't know that your refund workflow lets users request refunds for orders they never paid for. It can't tell that your account balance check happens before your concurrent transaction lock, creating a race condition. It won't flag that your password reset flow accepts tokens after they've been used once.
These aren't coding errors in the traditional sense. The code executes exactly as written. The logic itself is flawed.
The Evidence
Business logic flaws aren't flagged by automated scanners, yet they're consistently exploited in real-world breaches. The OWASP Top 10 2021 doesn't list business logic as a separate category because it's embedded across multiple risk areas, particularly in broken access control and identification/authentication failures.
Look at what scanners actually check. SAST tools analyze code patterns and data flow. DAST tools send malformed inputs and watch for error responses. Neither approach models your application's intended behavior against abuse scenarios. You can't write a regex that detects "this workflow can be exploited by a creative attacker who understands the business process."
The problem compounds with compliance frameworks. PCI DSS v4.0.1 Requirement 6.4.3 mandates review of custom code prior to release, but most teams interpret this as "run the scanner." SOC 2 Type II controls require vulnerability management, and auditors accept clean scan reports as evidence. You're meeting the letter of the requirement while missing the actual risk.
What to Do Instead
Start by mapping your application's critical workflows. Not the happy path, the money path. Where does value transfer? Where do permissions change? Where can users affect other users' data or balances?
For each workflow, ask the attacker's questions:
- What happens if I do steps out of order?
- What if I do the same step twice simultaneously?
- Can I see or modify this resource before I'm supposed to?
- What if I change my role or account state mid-workflow?
- Where does the application trust client-side data?
Document your assumptions. "Users can only refund their own orders" is an assumption. "The checkout flow prevents negative quantities" is an assumption. Write them down, then test whether your code enforces them at every step.
Build threat models specific to your business logic. Generic threat modeling frameworks like STRIDE help, but you need domain-specific abuse cases. If you're building a marketplace, model seller impersonation and transaction manipulation. If you're handling financial transfers, model race conditions and state confusion. If you're managing multi-tenant data, model cross-tenant leakage.
Integrate manual review into your security workflow, but make it targeted. You don't need to review every line of code. Focus on:
- New workflows that handle sensitive operations
- Changes to authorization checks or state transitions
- Code that processes financial transactions or user balances
- Features that let users interact with other users' data
Pair developers with security engineers for these reviews. The developer understands the intended behavior; the security engineer thinks about unintended behavior. This isn't a gate, it's a collaboration.
Create test cases for your assumptions. If your application assumes users can't access resources before payment, write an integration test that tries. If you assume concurrent requests are serialized, write a test that fires simultaneous requests. These tests belong in your CI pipeline alongside your scanner results.
For OWASP ASVS v4.0.3 compliance, look at Section 4 (Access Control) and Section 11 (Business Logic). These requirements explicitly call out the need to verify business rules and workflow sequence. Your scanner won't check V4.1.3: "Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization."
When the Conventional Wisdom Is Right
Automated scanners absolutely belong in your security program. They're essential for catching common vulnerabilities at scale. You should run them on every commit. You should fix what they find.
The conventional approach works well for:
- Injection flaws and input validation issues
- Known CVEs in dependencies
- Missing security headers and configurations
- Authentication implementation bugs
- Standard OWASP Top 10 vulnerabilities
If you're not running automated scans, start there. A clean scan report isn't sufficient, but a dirty one definitely indicates problems.
Scanners also provide consistency. They check the same things the same way every time. Human reviewers have bad days and blind spots. Use scanners for breadth; use humans for depth.
The real issue isn't that scanners are bad. It's that we've let them define what "secure" means. Your application isn't secure when the scanner says it's clean. It's secure when someone who understands the business logic has tried to break it and failed.
Stop treating security as a binary pass/fail from automated tools. Your scanner is one input. Your threat model is another. Your manual review is another. Combine them, and you might actually find the flaws that matter.
