Case study · Banking
In-app runtime protection live in a customer banking app
I led the Zimperium in-app protection rollout for a leading private bank’s mobile app: policy tuning, SDK integration support for the bank’s developers and third-party SDK conflicts.
A leading private bank’s mobile app
- Zimperium
- Mobile apps
The setup
The architecture, simplified.
- A leading private bank’s customer mobile banking app, built by the bank’s own developers.
- Platform: Zimperium in-app protection (RASP). Delivered by Innov8’s AppSec BU, which I head.
- Scope: policy tuning, SDK integration support and third-party SDK conflict resolution.
The challenge
What made this hard.
- A device the bank does not controlRooted phones, hooking frameworks and repackaged clones all attack the app on the customer’s side.
- Security without locking customers outStrict root detection stops some attackers but also blocks real customers on older or custom devices.
- SDKs competing for the same hooksOther SDKs in the app can hook the same system functions, causing start-up crashes or false detections.
- Fitting someone else’s buildThe bank’s developers own the code and release cycle, so protection had to fit their build and signing.
The approach
How the work ran, step by step.
- 01
Threat-to-response matrix
Agreed with the bank which detections should block, restrict, warn or only report, threat by threat and feature by feature.
- Response per threat and per feature
- Security, fraud and digital teams aligned
- 02
SDK integration support
Worked with the bank’s developers to integrate the protection SDK into their build and release process.
- Build order and signing checked
- Start-up time measured on low-end devices
- 03
SDK conflict resolution
Resolved conflicts between the protection SDK and other third-party SDKs already in the app.
- SDKs added one at a time on test builds
- Both vendors involved early
- 04
Report-only release
Released with detections reporting rather than blocking, so the bank saw its real device population first.
- Telemetry by device and OS version
- Apparent false positives investigated
- 05
Policy tuning
Tuned the policy and enforced the highest-confidence detections first, such as active hooking or a repackaged app.
- Strongest signals enforced first
- Customer messaging ready before root rules
The outcome
What changed.
Real numbers only where they exist. Everything else is stated plainly, without invented percentages.
- In-app protection liveZimperium runtime protection live in the bank’s customer mobile app.
- Policy tuned for real customersProtection policy tuned to the bank’s customers and risk rather than left at vendor defaults.
- SDK conflicts resolvedConflicts with third-party SDKs resolved, so protection and app features run together.
- Developers supportedThe bank’s developers supported through SDK integration into their own build.
Lessons
What I would tell the next team.
- Lesson 01
Report first, enforce threat by threat
Release in report-only mode, read the telemetry by device model and OS version, then enforce the strongest signals first.
- Lesson 02
Integrate SDKs one at a time
Security, fraud, analytics and screen-sharing SDKs can clash. Add them one by one on test builds and bring both vendors in early.
- Lesson 03
Shielding does not fix the backend
An attacker does not have to use your app. API authorisation, transaction checks and fraud monitoring must assume the client is compromised.
Related
Where this experience shows up in my work.
What is RASP in a mobile banking app?
Runtime application self-protection (RASP) runs inside the app and checks, while it is running, for rooted or jailbroken devices, hooking frameworks, debuggers, emulators and tampering. When a check fires, a policy the bank defines decides the response: close the app, disable a feature, warn the user or report silently. On this programme, tuning that policy was a core part of the work.
Why do mobile security SDKs conflict with other SDKs?
Security, anti-fraud, analytics, crash reporting and screen-sharing software development kits (SDKs) can hook the same system functions inside an app. The result can be start-up crashes or false detections. Resolving third-party SDK conflicts was part of this bank’s rollout. The practical approach is to integrate SDKs one at a time on test builds and bring both vendors in early.
Does app shielding make a banking app secure on its own?
No. Shielding raises the cost of attacking the app on the device, but an attacker can call the bank’s application programming interfaces (APIs) directly and skip the app entirely. Server-side authorisation, strong authentication, transaction validation and fraud monitoring still have to assume the client may be compromised. I assess both sides when I review a mobile banking app.
More case studies
- 112applications migrated112 bank applications moved to cloud WAAP, wave by waveBanking · A leading Sri Lankan private bankF5 Distributed CloudRead the case
- 120applications protectedAround 120 applications under WAAP, API and bot protectionManufacturing · A global apparel group headquartered in Sri LankaImpervaRead the case
- T1bank vulnerability programmeTier-1 bank scanning upgraded and extended to web applicationsBanking · A Tier-1 Sri Lankan commercial bankTenable Security CenterRead the case
- SIEMtelemetry pipelineWAAP security events arriving in the bank’s SIEM, reliablyBanking · A leading Sri Lankan private bankF5 → Logstash → Trellix SIEMRead the case