Cutting 2,800 weekly alerts to 80 on a platform doing millions of transactions a day
Scanner noise had trained the team to ignore alerts. Reporting only what had been exploited cut 2,800 findings a week to roughly 80, and caught a checkout race condition worth an estimated $2M in prevented loss.
- Customer
- Retail and marketplace platform
- Industry
- Retail & E-Commerce
- Published
- April 30, 2026
At a glance
Customer profile
- Industry
- Retail / marketplace
- Scale
- ~4M transactions per day, 12 storefronts
- Environment
- Multi-cloud, 600+ microservices
- Engagement
- Continuous, deploy-triggered
Challenge
What was not working
The platform was not untested. It was over-alerted. Three scanners between them produced thousands of findings a week, the great majority of which were not exploitable, and the engineering organisation had quietly stopped reading them.
Alert fatigue had become alert blindness
A sampled week produced 2,800 findings. Fewer than 60 were reproducible. Engineering's rational response was to deprioritise the queue, which meant the 60 waited alongside the 2,740.
Deploy velocity outpaced any review
Around 200 deploys a day across 600 services. No review process gated on a human reading a report could keep up, so the report stopped being a gate at all.
Checkout logic was tested by traffic, not by tests
Promotions, gift cards, refunds and split payments interact. Nothing in the pipeline attempted to abuse those interactions deliberately. The flaws surfaced as unexplained revenue leakage weeks later.
Ownership was ambiguous at 600-service scale
A finding without an owner is a finding that ages. Routing depended on someone recognising the service name, which failed reliably for anything outside the top twenty services.
Solution
What AIPTx did about it
The core change was refusing to report anything that had not been exploited. Everything else (routing, prioritisation, the checkout work) followed from a queue small enough that a human could read all of it.
- 1
Validation before reporting
Every findingEvery candidate finding is exploited in a sandboxed replay before it is raised. Anything that cannot be reproduced is dropped rather than downgraded, which is what took a 2,800-item weekly queue to a two-figure one.
- 2
Business logic testing on checkout
ContinuousConcurrent redemption of the same gift card, promotion stacking, price manipulation between cart and capture, refund replay and inventory oversell were each modelled as an abuse case and run continuously.
- 3
Ownership resolved from the service catalogue
AutomaticFindings inherit the owning team from the deployment metadata, so a vulnerability in an obscure service reaches its team without anyone recognising the name.
- 4
Contextual risk scoring over raw CVSS
Per findingInternet exposure, authentication requirement, data sensitivity and whether the path reaches payment infrastructure adjust the score, so an authenticated medium on the payment service outranks an unauthenticated high on the careers site.
- 5
Deploy-triggered scoping
~6 minA deploy scopes the next run to the changed service and its callers rather than re-testing 600 services, which is what makes per-deploy testing viable at 200 deploys a day.
Results
What changed
Measured over the first six months, against the previous six months of multi-scanner output.
- 99.2%
- Reproduced by the team on reviewThis engagement, first six months, re-run from the captured request
- 97%
- Fewer findings raised2,800 per week to roughly 80, with more real issues among them
- $2M
- Estimated loss preventedGift card race condition, modelled on observed abuse rates
- 24/7
- Continuous coverageAcross 600+ services and 12 storefronts
- 6 min
- Median per-deploy scanScoped to changed services and their callers
- 2 hrs
- Median time to ownerDown from 9 days for services outside the top twenty
Findings per week
Before~2,800, mostly unreproducible
After~80, all confirmed
Engineering response
BeforeQueue ignored
AfterQueue read; criticals actioned same day
Checkout abuse testing
BeforeNone automated
After29 abuse patterns run continuously
Routing
BeforeManual, by recognition
AfterFrom deployment metadata
Key takeaways
The part that transfers
Every environment differs. These are the conclusions that hold outside this one.
A finding you cannot reproduce is not a finding
Reporting unvalidated candidates does not transfer risk to the engineering team, it transfers triage cost. Dropping them outright is what made the remaining queue credible enough to act on.
Logic flaws are where the money is
Not one of the highest-value findings had a CVE. The gift card race condition was a correctly patched, fully up-to-date service behaving exactly as written.
Scope the scan to the change
Full re-tests cannot run 200 times a day. Scoping to the changed service and its callers is what makes per-deploy security testing arithmetically possible.
Routing is a security control
Time-to-owner dominated time-to-fix at this scale. Automating the routing improved remediation more than any change to detection did.
Related
Other programmes, other starting points
A four-person engineering team passing enterprise security review without a security hire
Security questionnaires were stalling every enterprise deal. Automated testing plus SOC 2 evidence turned the security review from a blocker into a differentiator.
ReadLogistics & Supply ChainEleven attack paths to domain admin, closed by four changes
A 40-site Active Directory estate had accumulated a decade of delegation. Attack chain analysis reduced 11 domain-admin paths to zero without a migration project.
ReadManufacturingFinding the dependency risk that a vulnerability count kept hiding
A 4,100-package dependency tree produced 900 CVE alerts. Reachability analysis showed 23 were exploitable, and one was in a build tool nobody had inventoried.
ReadSee Your Attack Surface in Real-Time
Run a comprehensive VAPT assessment powered by advanced security tools. Get actionable findings in hours, not weeks. No credit card required.