Key takeaways
- The average mobile app receives a release roughly every 2–5 weeks. Annual or semi-annual pentests sample at best 4–8% of the actual production attack surface across a year.
- Modern mobile threats — SDK supply-chain compromises, post-release Play Store substitutions, runtime API changes — emerge between pentest engagements, not during them.
- The 60% figure isn’t hyperbole: it reflects what we observe when we re-scan apps that were “clean” at their last manual pentest, six months earlier. The gap is real and it widens with release velocity.
- The fix is continuous testing layered with periodic deep pentest — not one or the other. This article explains the layered model and the integration patterns that work.
The mobile penetration test is a useful artefact. It is also, on its own, an inadequate security programme for any product team shipping mobile apps in 2026. This is uncomfortable to say in an industry where the annual pentest is often the single line item the security team can defend at budget time. But the gap between the pentest cadence and the release cadence is now too wide to ignore.
This post walks through the math, the structural reasons traditional pentests miss vulnerabilities, and what a layered continuous + periodic model actually looks like in practice.
The snapshot problem
A mobile penetration test produces a point-in-time assessment. The pentester scans, exploits, tests, writes the report. The report describes the security posture of that build of that app on that day.
Within hours of the report being signed, the engineering team merges the next pull request. New SDK version. New feature. New endpoint. New permission. The report is now a description of a build that no longer exists.
For apps that release infrequently — say, an internal admin app updated once a quarter — this gap is manageable. For consumer-facing apps with active development, the pentest report describes a snapshot of the past. The longer between pentest and re-test, the further the production reality drifts from the assessed reality.
The release velocity reality in 2025–2026
The numbers depend on category but the trend is consistent.
- Consumer mobile apps in the App Store and Play Store now release on average every 3–5 weeks, with leading consumer brands releasing every 1–2 weeks.
- Banking apps, historically slower to release, have accelerated. Several major UAE and Indian banks now release monthly.
- Health, e-commerce, productivity — all converging on monthly or faster.
- B2B SaaS mobile apps vary widely; the trend is toward more frequent releases as backend APIs are increasingly tied to mobile clients.
A bank shipping its mobile app every 4 weeks has 13 production releases per year. If they pentest twice annually (semi-annual VAPT under RBI Master Direction expectations), the pentest covers 2 of 13 releases — 15% sampling rate.
Worse, those 2 releases are the ones the pentest is looking at, not necessarily the ones being exploited in the wild. In the time between pentests, 11 other releases ship to production carrying changes that have never been independently security-reviewed.
Where vulnerabilities actually emerge between pentests
Five sources of new vulnerability that pentest cycles routinely miss:
1. SDK / library updates. A common Android app contains 30–60 third-party libraries. Each library has its own release cycle. A library that was clean at the time of your pentest may publish a new version with a new CVE three weeks later. If your team pulls that update on the next release (which they should, for non-security reasons), you have introduced a new vulnerability that the pentest cannot have caught.
2. New code paths. Every feature merge introduces new code. Most of it is benign. Some of it isn’t. The question is not whether your new feature has security bugs — it almost certainly does — but whether your security tooling notices before the auditor does.
3. Configuration drift. Changes to backend endpoints, authentication flows, network policies, deep-link handling, and intent filters often look like product changes. They are often security changes too. Pentest doesn’t see them between engagements.
4. Post-release Play Store / App Store actions. Google and Apple can modify what users actually install — store-side wrapping, repackaging for distribution policy compliance, automatic SDK substitution under specific conditions. Your CI artefact and the artefact a user downloads are not always identical. Continuous monitoring of the published version catches these. Pentest doesn’t.
5. Runtime backend changes. Your mobile app calls APIs. Those APIs evolve. A change in API behaviour can introduce a vulnerability in the mobile client without changing a single line of mobile code. Pentest snapshots the client; it doesn’t track the moving backend.
The 60% number, derived
The “60%” headline is a claim, so it deserves a defence.
When we re-scan apps that were “clean” at their last manual pentest 6 months earlier, against current MASVS v2.1 + Mobile Top 10 2024 with current SDK CVE feeds and current threat patterns, we find on average:
- 35–45% of new findings trace to SDK / library updates released since the pentest
- 15–25% of new findings trace to new code paths in features added since the pentest
- 5–10% of new findings trace to configuration changes (endpoints, permissions, deep-link handling)
- 5–10% of new findings trace to evolved threat patterns (e.g., banking trojan techniques disclosed publicly between pentests)
Net: 60–80% of currently-detectable findings on a given app are introduced or become detectable after the most recent pentest, regardless of pentest quality. The pentest correctly described the state of the app at scan time. The state has changed.
This is not a critique of pentesters. It is a critique of pentest-only programmes.
What “continuous mobile testing” actually means
The phrase gets used loosely. Concretely, in 2026, a credible continuous mobile testing programme has six components.
1. SAST on every CI build. Source-code-level scanning on every pull request and every merge to release branches. Catches: hardcoded secrets, weak crypto patterns, insecure storage APIs, missing pinning configuration. Not a replacement for binary analysis (some flaws only emerge from compiled output) but the first line of defence.
2. Binary analysis on every release artefact. Decompile the APK / IPA, analyse the compiled output. Catches: secrets leaked through code generation, SDK CVEs in compiled libraries, configuration baked into resources, anti-tamper coverage gaps.
3. SBOM generation on every release. CycloneDX (or SPDX) format. The SBOM is your supply-chain control surface. New CVE in a library you ship → SBOM reverse-lookup tells you which apps and which versions are affected.
4. Continuous Play Store / App Store monitoring of the published version. Independent of your CI. Detects: store-side wrapping, supply-chain substitution, post-release SDK updates pushed by vendor servers, and the gap between what your CI built and what users actually download.
5. Automated regression on the running app — DAST. Real device or instrumented emulator, authenticated flows where feasible. Catches: runtime auth bypasses, configuration changes that don’t show in static analysis, broken pinning at runtime.
6. MASVS v2.1 + Mobile Top 10 2024 mapping on every scan output. Without this, the engineering team cannot prioritise, the product owner cannot understand the risk, and the auditor cannot accept the evidence.
These six components produce a continuous stream of evidence. The volume is high. The signal-to-noise ratio is what separates a useful programme from a noise generator. This is where modern MAST platforms — including HEXMobileSuite — earn their seat.
The static + dynamic + device layer model
Different findings emerge at different layers. A serious mobile programme covers all three:
| Layer | What it sees | What it misses |
|---|---|---|
| Static (SAST + binary) | Code-level patterns, configuration in source, hardcoded secrets, SDK CVEs | Runtime behaviour, environment-dependent flaws, server-side issues |
| Dynamic (DAST on real device / emulator) | Runtime auth, network behaviour, runtime configuration, certificate pinning enforcement, deep-link handling | Pre-runtime configuration mistakes, code paths not exercised by the test, internal logic |
| Device / runtime integrity | Tamper detection, root detection, debugger attachment, Frida instrumentation, accessibility-service abuse | Pre-deployment configuration, code-level flaws, network-layer issues |
Continuous testing covers static and (most of) dynamic. Periodic deep pentest covers what tools cannot — primarily complex business logic, multi-step authorisation chains, and novel attack paths. Both are needed.
The integration patterns that work
If you are wiring continuous mobile testing into a pipeline for the first time, three integration patterns are reliable.
Pattern A: Pull request gate with non-blocking findings.
- Trigger: Every PR
- Run: Static analysis only (fast feedback)
- Output: Findings posted as PR comments; no auto-block
- Goal: Educate developers, surface findings early, don’t slow the PR queue
Pattern B: Release branch nightly with full scan.
- Trigger: Nightly cron on release branches
- Run: Full static + binary + SBOM
- Output: Signed PDF report + SARIF feed into security ticketing
- Goal: Build the per-release evidence trail without coupling to release schedule
Pattern C: Release gate with severity threshold.
- Trigger: Tag or merge to
main - Run: Full scan suite
- Block on: New Critical findings only (existing Critical findings have to be already accepted with documented rationale)
- Goal: Hard quality gate without breaking the build for known-and-managed risk
You can run all three in parallel. The combination is what produces the per-release signed evidence pack that auditors increasingly expect.
For the four major CI/CD platforms — GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure DevOps — HEXMobileSuite ships first-party integrations for all of them. See [link to /ci-cd-integrations] for the integration guides.
The hybrid model — continuous + periodic deep pentest
The right answer is not “replace pentest with scanner.” It is “stop relying on pentest as the only signal.”
A mature 2026 mobile security programme:
- Continuous scanning on every release — produces audit evidence per release
- Continuous monitoring of published versions — detects post-release supply chain changes
- Annual deep manual pentest — covers business logic, novel attack chains, multi-step exploitation
- Targeted manual pentest for major releases or threat-relevant changes — e.g. when adding payment, biometric auth, or new third-party SDKs in critical paths
- Threat-intel-driven re-testing — when a new technique disclosed in the wild affects a class of app you ship (e.g., a new banking trojan technique against accessibility services), re-scan immediately
This model is more expensive than annual-pentest-only on absolute spend. It is dramatically cheaper on actual risk. And the audit evidence it produces is what NESA, SAMA, RBI and DPDP auditors increasingly expect by default.
Metrics that actually matter
Stop measuring “number of findings.” It rewards noisy scanners. Start measuring:
- Mean time between scans — how long is the average release-to-scan gap?
- Coverage of release surface — what percentage of releases were scanned?
- Mean time to remediation by DREAD severity — Critical fixed in days, High in weeks, Medium in next release cycle, Low in backlog with documented rationale
- False-positive rate — are findings being suppressed faster than they are being fixed? (If yes, your tool needs tuning.)
- Audit evidence completeness — for any randomly selected app and release date, can you produce the signed report in under 5 minutes?
- SDK drift events — how many post-release SDK changes were detected by continuous monitoring?
- Time from CVE disclosure to fix in production — for libraries you ship
These seven metrics, tracked monthly, tell you whether your programme is working. None of them require a pentest report.
What to do this quarter
If your programme today is “annual pentest + occasional CI scan”, the practical migration to a continuous + periodic model:
Month 1. Wire continuous scanning into one of your active mobile apps. Use the PR + nightly + release-gate patterns above. [link to /free-scan] runs in 30 minutes for the initial baseline.
Month 2. Define the per-app, per-release evidence template. Map it to the regulator your auditor cares about (NESA / SAMA / RBI / DPDP). Backfill the last 90 days of releases with scans.
Month 3. Roll out across the rest of the mobile portfolio. Define the metrics dashboard. Brief the audit committee.
Quarter 2. Run the next manual pentest with your continuous scanning data already in hand. The pentest scope shifts from “find everything” to “find what tools can’t” — business logic, complex multi-step exploitation, novel attack chains. Pentest cost stays the same; pentest value increases substantially.
Quarter 3. Use the per-release evidence pack in the next audit. The conversation shifts from “show us your last pentest” (which is now stale by definition) to “show us evidence for the last 90 days of releases” (which is automated).
The 60% gap is real. The fix is not heroic; it is structural. The teams that close it in 2026 will spend 2027 and 2028 with cleaner audits, fewer surprise findings, and dramatically lower mean-time-to-detect. That is the actual value of continuous mobile testing — not the dashboard, but the time saved, the breaches avoided, and the audit cycles that stop bleeding effort.
HEXMobileSuite is built for this layered model. Continuous scanning on every release, signed evidence per scan, MASVS v2.1 + regulator mapping out of the box. Try it free against your current pentest’s findings — see what’s changed at hexmobsuite.hiesencyber.com.