What Happened
Your security team might run regular penetration tests on your infrastructure and network, but what about your web applications? In this case, a team conducted quarterly tests on their infrastructure, while a different vendor handled web application scans. Both passed. Yet, six months later, attackers breached a web application, accessed internal systems using application credentials, and stole customer data from cloud storage.
The breach was discovered when cloud egress costs spiked. The team's infrastructure tests never included the web layer, and their web application scans didn't consider what an attacker could access after initial compromise.
Timeline
Month 0: A web application vulnerability scanner identified an SQL injection in the customer portal. A ticket was created and marked medium priority because the scanner couldn't demonstrate an exploitation path beyond the database.
Month 2: An infrastructure penetration test was completed, showing strong network segmentation. There were no findings related to application-layer access.
Month 3: The development team patched the SQL injection, and the scanner confirmed the fix.
Month 5: Attackers exploited a different injection point in a newly deployed feature, gaining access to an application database containing service account credentials for AWS S3.
Month 6: Attackers used these credentials to enumerate S3 buckets and download customer data. The cloud provider flagged unusual egress patterns, prompting the security team to investigate and discover the breach.
Which Controls Failed
The security validation program failed at the intersection of application security and infrastructure security. You can't stop an attack path you've never tested.
Siloed testing: Web application security testing stopped at the application boundary. The team never considered what an attacker could reach if they compromised the application. Infrastructure testing assumed the application layer was secure.
No credential validation: The application stored AWS credentials in the database, but no one tested whether database access led to cloud access. This isn't a configuration issue you find with a vulnerability scanner. It's an attack path issue that requires following attacker logic.
Missing business context: Security tools flagged the SQL injection as medium severity because they couldn't measure business impact. The team didn't realize that database access meant cloud access, which meant customer data exposure.
What Standards Require
PCI DSS v4.0.1 Requirement 11.4.7 requires multi-layered security testing, including "segmentation and scope-reduction controls." If you're testing network segmentation but ignoring application-to-infrastructure attack paths, you're not testing segmentation. You're just testing network ACLs.
NIST CSF v2.0 function PR.DS-5 calls for protections against data leaks. Testing each layer separately doesn't verify protection across layers. An attacker who starts at the web application doesn't care about your network segmentation if they can steal cloud credentials from your database.
ISO 27001 Control 8.8 requires management of technical vulnerabilities, including "regular vulnerability assessments." The standard doesn't say "run separate scans on each technology stack." It says assess vulnerabilities. An exploitable attack path from web to cloud is a vulnerability, even if no single tool flags it.
SOC 2 Type II CC7.1 requires monitoring to detect security events. If your monitoring watches network traffic but misses application-layer credential theft, you won't detect the event that matters. The control requires detection of security events, not just network anomalies.
Lessons and Action Items
Map your actual attack surface: List every web application that can reach internal systems or cloud resources. For each one, document what an attacker could access after initial compromise. Don't assume. Test it.
Test attack paths, not technologies: Your next security assessment should start where attackers start. If your customer-facing applications are web-based, your testing should begin there and follow the path an attacker would take. If the web app can query a database, test what's in that database. If the database contains credentials, test what those credentials can access.
Connect your validation tools: Your web application security testing and infrastructure testing should share findings. When a web app test discovers database access, your infrastructure team should test what that database access enables. This isn't a procurement problem. It's a workflow problem.
Validate credentials in context: Find every place your applications store credentials for other services. Test what those credentials can access. Document the blast radius. If database compromise means cloud compromise, that's a critical finding, even if the database itself is "secure."
Measure business impact: When you find a vulnerability, trace it to business impact. SQL injection that leads to cloud storage access that leads to customer data exposure is critical, regardless of what your vulnerability scanner says. Your risk rating should reflect the full attack path, not just the initial vulnerability.
Review quarterly: Attack paths change when you deploy new features, integrate new services, or modify access controls. Your validation cadence should match your deployment cadence. If you deploy weekly, you need continuous validation, not quarterly scans.
The security team in this incident did everything their compliance frameworks required. They ran regular scans. They tested their infrastructure. They patched vulnerabilities. They still got breached because they tested each layer separately while attackers moved across all of them.
Your security validation should follow the same path attackers follow: start at the exposed application, move to the systems it can reach, and map the business impact. Anything less isn't validation. It's checkbox compliance.
