Most of the code inside a typical mobile app was written by someone else, and every SDK, plugin and build tool that touches the binary can ship a vulnerability, a hidden credential or malicious code to every user under your signature. OWASP ranks this as M2 in the Mobile Top 10 2024, under the official name "Inadequate Supply Chain Security". This guide goes deeper than the OWASP Mobile Top 10 Guide: it explains what M2 covers, which MASVS controls and platform features apply, how to build an SDK governance and signing programme, and how to evidence it. It is written for mobile engineering leads, AppSec teams and assessors working on Android and iOS apps.
Key takeaways
- M2 covers the whole path to the user, not just open-source libraries: third-party SDKs, vendors, build pipelines, signing keys and app store distribution are all in scope.
- OWASP rates M2 as hard to detect (detectability: difficult) with severe technical and business impact, so prevention and inventory matter more than post-release testing.
- Your signing key is your identity on every device. Anyone holding the Android upload or signing key, or the Apple distribution certificate, can ship code users will trust; treat these keys as high-value non-human credentials.
- SDKs carry credentials and data flows you did not write. Symantec traced shared cloud keys in 53% of affected apps to common libraries and SDKs, so vet what an SDK embeds and transmits, not only its CVEs.
- Platform features now help: Apple privacy manifests and SDK signatures, Play App Signing with separate upload keys, APK Signature Scheme v2 and later, and SLSA provenance give you concrete controls to adopt.
What it is and who it applies to
OWASP describes M2 as attackers manipulating app functionality by exploiting weaknesses in the mobile supply chain: inserting malicious code, altering the build, or abusing vulnerable third-party libraries, SDKs and vendors. OWASP notes that hard-coded credentials in third-party components can also give access to the app or its back-end servers. The OWASP risk page gives the following ratings.
| OWASP factor | Rating | What it means in practice |
|---|---|---|
| Exploitability | Average | Needs either a vulnerable dependency or access to the build or signing process, but both are common. |
| Prevalence | Common | Nearly every app ships analytics, advertising, crash reporting, payments or cross-platform framework code. |
| Detectability | Difficult | Malicious or leaky SDK behaviour often looks like normal network traffic and survives store review. |
| Technical and business impact | Severe | Data breach, malware on user devices, unauthorised server access, fines and reputational damage. |
OWASP lists two main attack vectors: an insider or outsider injects malicious code during development and then uses compromised signing keys or certificates to sign it as trusted, and an attacker exploits a vulnerability in a third-party component the app uses. Its example scenario is malware injected into a popular app during development, signed with a valid certificate and distributed through the store, where it steals user credentials.
Who it applies to: any organisation that builds mobile apps in-house or through an agency, publishes SDKs used by other apps, or relies on cross-platform frameworks such as Flutter, React Native or Cordova. OWASP's "Am I vulnerable?" list is broad: unvetted or outdated components, malicious insiders such as a rogue developer or supplier, inadequate testing of the app and its supply chain, and low developer security awareness. If you outsource development, the agency's build machine and its handling of your keys are part of your supply chain.
Structure and key requirements
OWASP's prevention guidance has five parts: secure coding, code review and testing across the lifecycle; a secured signing and distribution process; only trusted, validated third-party libraries; security controls for updates, patches and releases; and monitoring for supply chain incidents with prompt response. The OWASP Mobile Application Security Verification Standard (MASVS) turns this into testable controls. The table maps each M2 concern to the MASVS control and the platform feature that implements it.
| M2 concern | MASVS control | Implementation on Android and iOS |
|---|---|---|
| Vulnerable components | MASVS-CODE-3: the app only uses software components without known vulnerabilities | Software composition analysis in CI (for example OWASP Dependency-Check on Gradle builds), SBOM per release, remediation time frames |
| Users stuck on vulnerable builds | MASVS-CODE-2: the app has a mechanism for enforcing app updates | Server-driven minimum version check; Android in-app updates; forced update screen on iOS |
| Outdated platform dependencies | MASVS-CODE-1: the app requires an up-to-date platform version | Raise minSdkVersion and the iOS deployment target on a published schedule |
| Repackaged or backdoored builds | MASVS-RESILIENCE-2: the app implements anti-tampering mechanisms | Signature and integrity checks, server-side app attestation (Play Integrity appRecognitionVerdict) |
| SDKs collecting data without consent | MASVS-PRIVACY-1: the app minimises access to sensitive data and resources | Gate SDK initialisation on consent; Apple privacy manifests; Google Play Data safety form |
| SDK traffic weakening transport security | MASVS-NETWORK-1: the app secures all network traffic according to current best practices | Network Security Configuration on Android and App Transport Security on iOS apply to SDK traffic too; check SDKs that bring their own HTTP stacks |
Signing and distribution requirements
- Android signing schemes: APK Signature Scheme v1 (JAR signing) does not protect parts of the APK such as ZIP metadata. v2, introduced in Android 7.0, signs the whole file so any change outside the APK signing block invalidates it, and v3 (Android 9) adds information to the signing block. Android recommends signing with v1, v2 and v3 for compatibility.
- Play App Signing: Google holds the app signing key and you keep a separate upload key. If the upload key is lost or compromised you can request an upload key reset in the Play Console without changing the app signing key. Key upgrade allows a new app signing key for installs and updates on Android 13 and higher.
- Keystore hygiene: Android's guidance is to use strong, separate passwords for the keystore and each key, keep upload and signing keys different, and keep signing details in a keystore.properties file excluded from source control. Keys for Google Play must be valid beyond 22 October 2033.
- Apple SDK signatures and privacy manifests: since WWDC23, Xcode checks that a new version of a signed third-party SDK was signed by the same developer. For SDKs on Apple's list of commonly used SDKs (around 100, including Firebase components, Alamofire, FBSDKCoreKit and Flutter), a privacy manifest is required, and a signature is required when the SDK is a binary dependency. Apple states that you remain responsible for all code an SDK includes.
Build integrity requirements
SLSA v1.0 gives a vocabulary for build integrity. Build L1 means provenance exists; Build L2 requires a hosted build platform that signs provenance; Build L3 requires hardened builds where runs cannot influence one another and provenance signing secrets are unreachable from user-defined build steps. For most mobile teams, reaching L2 (no release builds from developer laptops, signed provenance) is a realistic first target. See the CI/CD Security Guide.
Identity and NHI requirements
Mobile supply chain attacks usually succeed through a non-human credential: a signing key, a store API key, a CI token or a cloud key embedded in an SDK. Treat each as a managed machine identity with an owner, scope, storage location and rotation plan.
| Credential | What an attacker gains | Control |
|---|---|---|
| Android upload key (keystore) | Ability to upload builds Google will re-sign and ship | Store in HSM or CI secret store, never in the repo; restrict who can trigger release jobs; know the upload key reset process |
| Self-managed app signing key | Updates indistinguishable from yours; loss means no further updates | Enrol in Play App Signing or protect in an HSM with offline backup and dual control |
| Apple distribution certificate and provisioning profiles | Signed iOS builds under your team identity | Limit Apple Developer account roles; keep signing in CI on dedicated runners; revoke certificates on staff exit |
| App Store Connect and Play Console API keys | Ability to submit or release builds and alter listings | Least-privilege roles, per-pipeline keys, expiry and rotation, alert on use outside CI |
| CI tokens and package registry tokens | Ability to alter dependencies or build steps | Short-lived OIDC federation instead of static tokens; scoped publish rights |
| Cloud or API keys inside SDKs | Direct access to the SDK vendor's or your back end | Secret scanning of built binaries; contractual ban on embedded privileged keys |
Symantec's 2022 research found hard-coded AWS credentials in 1,859 Android and iOS apps, and traced the shared keys in 53% of them to common libraries and SDKs, including a digital identity SDK used by five iOS banking apps whose keys exposed more than 300,000 biometric fingerprints. See the Mobile Apps Hard-Coded AWS Keys 2022 analysis, the sibling OWASP Mobile Top 10 M1 Improper Credential Usage Guide and the Code Signing Security Guide.
Implementation steps
- Inventory first (weeks 1 to 2): generate an SBOM for each app from Gradle, CocoaPods, Swift Package Manager and any JavaScript bundles. Add binary SDKs that package managers miss (frameworks dropped into the project). Record for each: owner, purpose, data collected, network endpoints, licence and update cadence. See the SBOM Guide.
- Classify SDK risk: rate each SDK by permissions it uses, data it reads, whether it runs before consent, whether it loads remote code or configuration, and vendor security posture. Mark advertising, analytics, attribution and remote-config SDKs as higher risk by default.
- Gate new dependencies: require a short review before any new SDK is added: vendor questionnaire, privacy manifest or Data safety disclosures, maintenance history, and a check that dependencies resolve from expected repositories (ASVS 5.0 V15.2.4 addresses dependency confusion). See the Malicious Package and Dependency Confusion Guide.
- Add scanning to CI in report-only mode: run software composition analysis and secret scanning on every pull request and on the built APK, AAB and IPA. Run report-only for two to four weeks to baseline findings, then fail builds on new critical vulnerabilities and any detected secret.
- Lock and pin: commit lock files (Podfile.lock, Package.resolved, Gradle dependency locking or verification metadata) so builds are reproducible and an upstream change cannot silently enter a release.
- Move signing off laptops: enrol in Play App Signing, keep upload keys in the CI secret store or an HSM, run iOS signing on dedicated release runners, and restrict release pipelines to protected branches with required review. Document the rollback: if a pipeline change breaks signing, the previous release job definition and key reference are restored from version control.
- Enforce consent before SDK start-up: initialise analytics and advertising SDKs only after the consent signal, as MASVS-PRIVACY-1 expects, and verify with traffic capture that no SDK calls out before consent.
- Add update enforcement and attestation: implement a minimum supported version flag on the server (MASVS-CODE-2) so you can force users off a compromised build, and use server-side app attestation to reject repackaged clients.
- Prepare the incident path: define who can pull a release, revoke a key, request an upload key reset and push a forced update, and rehearse it once a year. See the Supply Chain Compromise Response Playbook.
Decision guidance
| Decision | Option A | Option B | Choose A when |
|---|---|---|---|
| Android signing key custody | Play App Signing (Google holds key) | Self-managed key in your HSM | You ship only through Google Play and lack HSM operations; choose B if you distribute outside Play and must sign identically everywhere |
| SDK delivery | Source or package-manager dependency | Pre-compiled binary framework | You need reviewable code and SCA coverage; binaries need vendor SBOMs and Apple SDK signatures to compensate |
| Feature from a vendor SDK vs own build | Vendor SDK | Thin in-house client calling the vendor's API from your server | The SDK is well maintained and needs device access; choose B for analytics and attribution where server-side integration removes device data collection |
| Team size | Small team: managed signing, platform scanners, quarterly SDK review | Large estate: central SDK allowlist, internal mirror, SLSA L2 or L3 builds | Fewer than a handful of apps; move to B as app count and agency use grow |
Evidence and assessment
Because OWASP rates detectability as difficult, assessors should look for process evidence as well as findings in the binary.
- Inventory evidence: a current SBOM per released version, including binary SDKs, matched to the shipped artefact rather than the repository head (ASVS 5.0 V15.1.2 expects an inventory such as an SBOM).
- Vulnerability evidence: SCA reports with documented remediation time frames for third-party components (ASVS 5.0 V15.1.1) and proof that releases did not exceed them (V15.2.1).
- Signing evidence: output of the Gradle signingReport task or apksigner verification showing v2 or later schemes; Play Console App signing page showing separate upload and signing certificates; a list of people and pipelines with access to keys.
- Binary review: decompile the release build and confirm the libraries match the SBOM, no unexpected native libraries or dynamic code loading are present, and no secrets are embedded.
- Runtime review: intercept traffic on a test device and list every SDK endpoint contacted before and after consent; compare with the privacy manifest and Data safety form.
Metrics
- SBOM coverage: percentage of production app releases with a complete SBOM including binary SDKs (target 100%).
- Vulnerable component age: median days a known critical or high vulnerability in a shipped component stays unremediated.
- SDK review coverage: percentage of SDKs with a completed risk review in the last 12 months.
- Signing key exposure: number of people and systems able to use an upload or distribution key (trend down).
- Pre-consent calls: count of SDK network calls observed before consent in release testing (target zero).
- Forced update reach: time for 95% of active users to move off a withdrawn build.
Mapping to other frameworks
| Framework | Reference | Relevance to M2 |
|---|---|---|
| OWASP MASVS | MASVS-CODE-1, CODE-2, CODE-3, RESILIENCE-2, PRIVACY-1 | Testable controls for components, updates, tampering and SDK consent |
| OWASP ASVS 5.0 | V15.1.1, V15.1.2, V15.2.1, V15.2.4 | Remediation time frames, SBOM inventory, dependency confusion (useful for the app's back end and SDK review) |
| NIST SP 800-53 Rev 5 | SR-3, SR-4, SR-6, SR-11, SA-15, CM-14, SI-7, RA-5 | Supply chain processes, provenance, supplier reviews, component authenticity, development process, signed components, integrity, vulnerability scanning |
| NIST CSF 2.0 | GV.SC-05, GV.SC-07, ID.RA-01, PR.PS-02 | Supplier requirements, supplier risk, vulnerability identification, software maintenance |
| NIST SP 800-218 (SSDF 1.1) | Protect the Software (PS) and Produce Well-Secured Software (PW) practice groups | Protecting code from tampering, release integrity verification, reuse of well-secured software |
| CIS Controls v8.1 | Safeguards 16.4 and 16.5 | Inventory of third-party components; up-to-date and trusted components |
| ISO/IEC 27001:2022 Annex A | A.5.21, A.8.25, A.8.28 | ICT supply chain, secure development life cycle, secure coding |
| MITRE ATT&CK v20 (Mobile) | T1474 Supply Chain Compromise, T1474.001, T1474.003 | Compromise of dependencies, development tools and the software supply chain |
Common pitfalls
- Scanning only the manifest: SCA tools read Gradle or CocoaPods files but miss frameworks copied into the project and code inside cross-platform bundles. Scan the built artefact as well.
- Trusting an SDK because it is popular: popularity spreads a mistake across thousands of apps, as the shared SDK keys in the Mobile Apps Hard-Coded AWS Keys 2022 case showed.
- Weak control of the distribution point: in the Twilio TaskRouter SDK Compromise 2020, a world-writable storage path let an attacker replace a hosted JavaScript SDK for about nine hours. Mobile SDK vendors and in-house SDK teams need locked-down publishing identities and integrity checks for the same reason.
- Signing keys on developer machines or in the repository: keystore files and passwords committed to source control, or a single shared Apple account, mean any laptop compromise becomes a signed release.
- No way to force an update: without a minimum version mechanism, a withdrawn build with a vulnerable SDK stays in use for months.
- SDKs starting before consent: initialisation in the application start-up method sends data before the user has chosen, creating privacy exposure as well as an M2 finding.
Practitioner checklist
- Maintain an SBOM per release that includes binary SDKs and cross-platform bundles.
- Run SCA and secret scanning on source and on the built APK, AAB and IPA, failing builds on new critical issues.
- Require a documented risk review before adding any SDK, and re-review annually.
- Commit lock files and resolve dependencies only from approved repositories or an internal mirror.
- Enrol in Play App Signing with a separate upload key, and keep upload keys and Apple certificates out of repositories and laptops.
- Restrict release pipelines and store API keys to least-privilege, named owners with rotation dates.
- Gate analytics and advertising SDK initialisation on consent and verify with traffic capture.
- Implement a server-controlled minimum app version and test the forced update path.
- Use server-side app attestation to reject repackaged clients for sensitive API calls.
- Rehearse the release pull, key revocation and upload key reset process once a year.
Standards and references
- OWASP: Mobile Top 10 2024 M2 Inadequate Supply Chain Security
- OWASP: Mobile Application Security Verification Standard (MASVS)
- Apple: Third-party SDK requirements
- Android Developers: Sign your app
- Android Open Source Project: Application signing
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- SLSA: Security levels (v1.0)
- OWASP: Dependency-Check
Related NHI Mgmt Group resources: OWASP Mobile Top 10 Guide · Software Supply Chain Security Guide · Mobile App Security Guide · OWASP Mobile Top 10 M3 Insecure Authentication and Authorization Guide · Third-Party Risk Management Guide