Mobile DevSecOps is the practice of building security into every stage of how a mobile app is planned, coded, built, signed, released and monitored, so that each release carries evidence of what was checked. It follows the same idea as DevSecOps for web services, but the delivery model is different: the app runs on devices you do not control, releases pass through store review, and users keep old versions for months. This article explains what that changes, who owns which check, and how to evaluate a mobile DevSecOps approach on Android and iOS.
Why mobile needs its own version of DevSecOps
A web team can patch a server in minutes. A mobile team ships a binary that leaves its control the moment a user installs it. That single fact reshapes the whole pipeline.
Web service DevSecOps
- Code runs on servers the team operates
- A fix reaches every user at the next deploy
- Secrets stay on the server
- Runtime is observed with the team's own monitoring
Mobile DevSecOps
- Code runs on devices the team does not control, some rooted or jailbroken
- A fix reaches users only when they update from the store
- Anything shipped in the package can be read by whoever installs it
- Runtime is observed only through signals the app sends back
Three consequences follow. The binary itself must resist reading and modification, because attackers get a copy. The app must report on its own environment, because no one else can. And the backend must not assume a request came from the genuine, current app, because old and modified versions keep calling it.
The store policies shape the pipeline too
Mobile pipelines also answer to the stores. Several store requirements are now part of any release checklist.
- 2017
Google Play App Signing
Google introduces a model where Google holds the app signing key and developers sign uploads with a separate upload key.
- 8 Dec 2020
App Store privacy details
Apple requires privacy details for new apps and app updates.
- Aug 2021
Android App Bundle for new apps
New apps on Google Play must be published as Android App Bundles, which requires Play App Signing.
- 20 Jul 2022
Google Play Data safety section
Apps on Google Play must complete the Data safety section.
- 1 May 2024
Apple privacy manifests enforced
App Store submissions must declare approved reasons for listed APIs in a privacy manifest.
Each of these turns into pipeline work: signing keys managed differently, privacy declarations kept in step with the code, and SDK inventories reviewed before release. A mobile DevSecOps programme treats them as checks, not as paperwork at the end.
Control fit: app, operating system and backend
Mobile security is shared between three parties, and most gaps appear where a team assumes another party covers a threat. Name the owner of each control explicitly.
| Threat or task | App | Operating system | Backend |
|---|---|---|---|
| Reading and repackaging the binary | Obfuscation, anti-tampering | Signature checks at install | Refuses requests without app evidence |
| Hooking and debugging at run time | Runtime self-protection | Sandbox and process isolation | Receives the runtime signal |
| Stored tokens and data | Encrypts sensitive data | Keystore, Keychain, storage encryption | Short-lived tokens, revocation |
| Traffic interception | Hardened transport | Platform TLS and trust store | Server certificate management |
| Scripted API abuse | Attestation evidence with requests | Play Integrity or App Attest | Verifies evidence, rate limits |
| Compromised third-party SDK | SDK inventory and review | Permission model | Monitors unusual calls |
The OWASP Mobile Application Security Verification Standard (MASVS) gives these controls a shared vocabulary. Mapping its control groups to pipeline stages shows where most of the work sits.
5
Store policy changes in the timeline above that became release checks
Counted from the timeline on this page
| MASVS group | Primary pipeline stage |
|---|---|
| MASVS-STORAGE | Code and review |
| MASVS-CRYPTO | Code and review |
| MASVS-AUTH | Code and review |
| MASVS-NETWORK | Code and review |
| MASVS-PLATFORM | Code and review |
| MASVS-CODE | Build and protect |
| MASVS-RESILIENCE | Build and protect |
| MASVS-PRIVACY | Release and monitor |
Counts come from the mapping table above. Each group is placed at the stage where it is mostly enforced; most groups also need checks at other stages.
The build stage carries more weight in mobile than in web, because resilience controls such as obfuscation, anti-tampering and runtime self-protection are added to the binary itself. For how that stage runs in practice, see mobile DevSecOps.
Evaluation: what good looks like
A mobile DevSecOps pipeline is easy to describe and hard to verify. Evaluate it by what each stage produces.
Plan
Threat model per user flow, with owners for app, OS and backend controls.
Code
Static analysis and dependency review; findings tracked against MASVS groups.
Build and protect
Protection applied to every release build; the job fails if it does not complete.
Sign and test
Signing with keys the team holds; the protected build tested on real devices.
Release and monitor
Runtime signals reach the backend; old versions tracked and retired.
Three tests separate a working programme from a diagram:
- Repeatability. Can the team rebuild any release from its commit and get an equivalent protected artefact?
- Failure behaviour. When a security step fails, does the release stop, or does an unprotected build continue to the store?
- Platform honesty. Is each control described and tested separately for Android and iOS, with the supported versions written down?
User impact belongs in the evaluation too. Protection that blocks a legitimate user on an unusual device is a support ticket, not a success. Start new runtime controls in observe mode, measure how often each signal fires, then decide the response per flow.
For the build step itself, automating mobile app security in CI/CD covers credentials, sequence and failure handling.
Questions to ask before you start
- Which user flows carry the most risk, and who owns the controls for each?
- Which checks run on every build, and which only before a store release?
- Does a failed security step stop the release?
- Where do signing keys and store credentials live, and who can use them?
- How do runtime signals reach the backend, and who acts on them?
- How long do old app versions stay in use, and how are they retired?