Case Study: From MobSF 48/100 to 124 Tracked Security Fixes in Nine Weeks

Most agencies sell security as an adjective. This case study is a paper trail: a real retail bank, a real scanner score, 48 scored gaps, 124 tasks and an honest list of what is still open.

The bank’s Android app is built on a white-label banking SDK. When the bank’s own scan returned a MobSF security score of 48 out of 100, the question was not just how to raise the number. It was what the number actually meant, which gaps were real, and how to fix them in a way the bank’s security team could check.

In this article, we’ll walk through how the audit was run, what the remediation included, how the fixes were verified, and what is still open.

---

The Starting Point

A score of 48/100 sounds alarming, but a raw score says little on its own. Before any fix, we needed to answer three questions:

• Can we reproduce the score? If we cannot get the same result, we cannot prove an improvement later.

• Which findings are real? Scanners mix genuine weaknesses with build-configuration noise and false positives.

• What does the scanner miss? Automated tools see the binary, not the logic. Authentication flows, key handling and data storage need a human review.

📌 Key Insight:

A scanner score is where an audit starts, not where it ends. The useful output is a list of real, scored gaps that someone owns.

---

How the Audit Was Run

Phase 1: Reproduce the Scanner Score

We rebuilt the scan and reproduced the bank’s result. Then we split every point the app lost into categories. The finding that surprised the bank most: 6–7 of the 52 missing points came only from the build type — the scan had been run on a debug build rather than the release build users actually install. And two checks the scanner had marked as secure turned out to be false positives.

Phase 2: Manual OWASP Mobile Top 10 (2024) Audit

We reviewed the app category by category against the OWASP Mobile Top 10 (2024), from improper credential usage (M1) and supply chain security (M2) through insecure data storage (M9) and insufficient cryptography (M10). Every gap received a CVSS score, so the bank could prioritise by severity rather than by how alarming a finding sounded.

Result: 48 CVSS-scored gaps.

Phase 3: A Costed Remediation Plan

The 48 gaps were broken down into 124 tracked tasks. Each change came with a short written threat and decision memo: what the risk is, which option we chose, what we rejected and why. Where the bank decided to accept a risk instead of fixing it, that decision was recorded too.

Phase 4: Remediation and Hardening

Alongside fixing the findings, we built and tested a set of runtime and anti-abuse controls, including:

• Overlay protection in three layers, plus a classifier for accessibility-service abuse.

• Biometric login bound to a CryptoObject, so a hooked callback cannot fake a successful login.

• Root, Frida and emulator detection, with 35 tests for exact-value emulator detection and no false positives on Chromebooks.

• Anti-repackaging through a signing-certificate check and an installer check.

• Clipboard wipe after 60 seconds for copied sensitive values.

• TLS 1.3 only for network traffic.

• Envelope encryption for local data instead of SQLCipher, saving 6.5 MB of native code at a cost of about 1 ms per screen.

---

How the Fixes Were Verified

Fixes that only the developer has tested are claims, not evidence. Verification ran in two layers.

Independent QA Security Pack

QA built a security-verification pack of 79 scripted checks covering 45 security tickets. Each check confirms that a specific control works on a real build.

Testing the Tests

We then tested the QA pack itself with mutation testing: deliberately breaking security controls in test builds and confirming that the checks catch every break. The runner caught all mutants. Just as important, 13 of those mutants had survived the developers’ own tests — exactly the gaps an independent check is there to find.

Supply Chain Evidence in CI

Every release now ships with a CycloneDX SBOM, and dependencies are scanned with OWASP Dependency-Check. The first scan produced 1,388 raw CVE matches. Each was triaged and suppressed with a dated, written reason, and none turned out to be a real vulnerability in the release APK.

---

Results at a Glance

Item	Result
Starting MobSF score	48/100, reproduced
Points explained by build type alone	6–7 of 52
Scanner “secure” ticks that were false	2
CVSS-scored gaps	48
Tracked remediation tasks	124
QA security checks	79 checks over 45 tickets
Raw CVE matches triaged	1,388 → 0 real
Duration	About nine weeks

What Is Still Open

We publish the gaps with the results, because that is what makes the rest believable:

• No final re-score or external pentest yet. We do not claim a final MobSF grade, a passed penetration test or full OWASP MASVS conformance.

• Certificate pinning is prepared and waiting on the bank’s key rotation policy before it is switched on.

• The dependency scan reports but does not yet block releases on high-severity findings.

---

Mobian’s Mobile Security Teardown

This engagement became the template for our Mobile Security Teardown: two weeks, fixed price. We reproduce your scanner score, run a manual OWASP Mobile Top 10 (2024) audit, CVSS-score every gap and hand over a costed remediation plan your team — or ours — can execute.

At Mobian, we are not a compliance firm and we will not tell you an audit makes you compliant. What we deliver is evidence your auditor can follow, down to the file and line.

Conclusion

A MobSF score of 48/100 told the bank something was wrong, but not what. Reproducing the score, auditing manually against OWASP, scoring every gap and verifying every fix turned one alarming number into 124 owned, traceable tasks. If someone — a partner bank, an auditor, a regulator — has already found a problem in your mobile app, that is the place to start.

Frequently asked questions

What did the security audit cover?

Four things: a reproduction of the bank’s own MobSF scan, a manual audit of the Android app against all ten categories of the OWASP Mobile Top 10 (2024), a CVSS score for every gap found, and a costed remediation plan. Remediation and independent QA verification followed in the same engagement.

Did the app pass a penetration test after the fixes?

We do not claim that. No external penetration test and no final MobSF re-score have been run yet. What we can show is a dated, numbered trail: 48 scored gaps, 124 tracked tasks, and a QA pack that verifies the fixes and was itself tested against deliberately broken builds.

Is a MobSF score enough to judge an app’s security?

No. In this project, 6–7 of the 52 missing points came only from scanning a debug build instead of a release build, and two checks the scanner marked as secure were false positives. A score is a starting point for a manual audit, not a verdict.

Does this work make an app compliant with DORA or other regulations?

Mobian is not a compliance firm, and an audit alone does not make an app compliant. What it produces is evidence an auditor can follow: scored findings, a written decision for each change, file-level remediation, and independent QA results. Your compliance and legal teams decide what that evidence covers.

Can the same controls protect crypto or gaming apps?

Many of them, yes. Overlay protection, accessibility-abuse detection, hooking and emulator detection, and anti-repackaging checks target abuse patterns that look the same across money apps. We have not built niche-specific features such as key custody or certified geolocation, and we say so up front.