A signed mobile app can still be malicious. Code signing proves which identity signed an artifact; it doesn’t prove that the source, dependencies, compiler, build runner, or signing decision deserved trust.
Mobile supply chain security: the controls that protect source, third-party packages, binary SDKs, build tools, CI identities, signing keys, artifacts, and store delivery from unauthorized change. Android and iOS add distinctive risks: opaque AAR and XCFramework binaries, Gradle and Swift package resolution, CocoaPods scripts, native toolchains, app-store signing, and SDKs that inherit host-app permissions.
This control plan adds three artifacts basic checklists omit: a trust-transition map, a dependency removal budget, and a release evidence bundle that links the shipped APK, AAB, or IPA to reviewed inputs. It also treats binary SDK behavior and emergency SDK removal as first-class engineering work.
Map Every Trust Transition
A trust transition occurs whenever software, metadata, or authority crosses from one owner or system into another. Inventorying packages without mapping transitions misses build scripts, runner images, signing services, and store consoles.
Start at the developer workstation and end at an installed application. Include source hosting, pull-request automation, package registries, mirrors, lockfiles, toolchain downloads, CI actions, base images, secrets, artifact storage, signing, notarization, Play Console, App Store Connect, and over-the-air content systems.
| Transition | Evidence | Failure to prevent |
|---|---|---|
| Registry to build | Pinned version and checksum | Dependency substitution |
| Source to runner | Reviewed commit and isolated job | Unreviewed code theft |
| Runner to artifact | Signed provenance | Unknown build origin |
| Artifact to store | Digest and approval | Wrong binary upload |
For each edge, name an owner, verification control, retained evidence, and emergency action. A diagram without ownership is decoration.
Include human and vendor authority
People cross trust boundaries too. A maintainer transfer, contractor offboarding, vendor acquisition, or app-store administrator change can alter release authority without changing source. Inventory who can approve workflows, publish packages, rotate verification metadata, request certificates, change store listings, or bypass branch protection.
Separate routine maintenance from exceptional authority. A developer who updates an analytics package shouldn’t also approve its new checksum, modify the release workflow, and upload the resulting binary alone. Use role separation around the few changes that can redefine what the pipeline trusts.
Review dormant access and recovery paths. A forgotten service account, backup email, personal package-registry token, or former vendor portal can outlive the project that created it. Test revocation and account recovery because an attacker will choose the least observed route, not the architecture diagram’s main line.
Pin Dependencies and Toolchains
Deterministic input selection limits what can enter a release without review. Pin direct and transitive dependencies, verify checksums, and control repositories in precedence order.
Gradle dependency verification can reject artifacts whose checksums or signatures don’t match trusted metadata. Commit lock state and verification metadata. For Swift Package Manager, commit Package.resolved for applications and review source-control locations. CocoaPods projects should commit Podfile.lock and avoid unreviewed script phases.
<?xml version="1.0" encoding="UTF-8"?>
<verification-metadata xmlns="https://schema.gradle.org/dependency-verification"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://schema.gradle.org/dependency-verification https://schema.gradle.org/dependency-verification/dependency-verification-1.3.xsd">
<configuration>
<verify-metadata>true</verify-metadata>
<verify-signatures>true</verify-signatures>
</configuration>
<components>
<component group="com.example" name="payments-sdk" version="4.2.1">
<artifact name="payments-sdk-4.2.1.aar">
<sha256 value="REPLACE_WITH_REVIEWED_ARTIFACT_SHA256"/>
</artifact>
</component>
</components>
</verification-metadata>
Pin Xcode, Android Gradle Plugin, Gradle, Kotlin, NDK, JDK, Ruby tooling, and runner image references. Download Apple and Android toolchains only from controlled official paths. XcodeGhost remains a durable lesson: a trusted application can inherit malicious compiler behavior.
Automation should propose updates through review, not mutate release inputs silently. Group routine updates, but isolate high-risk build plugins and SDKs for deeper review.
Defend dependency resolution itself
Repository order can create dependency confusion even when a version appears pinned. If an internal package name can resolve from a public registry with higher precedence or version, an attacker may publish a substitute. Restrict groups or namespaces to approved repositories and fail the build when a component comes from an unexpected origin.
Build scripts deserve the same verification as runtime libraries because they execute with runner permissions. Gradle plugins, CocoaPods hooks, Ruby gems, npm lifecycle scripts, and code generators can read environment secrets or modify output. Review newly introduced execution, sandbox jobs where possible, and avoid exposing signing authority to dependency-resolution stages.
Cache integrity matters after verification. Key caches by locked inputs, make trusted release caches read-only to untrusted jobs, and verify restored artifacts. A poisoned shared cache can bypass a clean registry fetch. When an incident occurs, invalidate caches as evidence-bearing infrastructure rather than treating them as harmless speed optimizations.
Classify Dependencies by Capability
Risk follows capability and execution position, not package count. A tiny build plugin can execute in CI, while a large pure formatting library may have no runtime authority.
Classify each component as build-time executable, source library, runtime SDK, native binary, code generator, test-only tool, or remote content interpreter. Record permissions, network destinations, data access, maintainer, release channel, license, update path, and removal owner.
Mobile SDKs execute inside the host app sandbox and may inherit camera, microphone, location, contacts, advertising identifiers, files, and network access. The operating system doesn’t isolate an analytics SDK from the application that embedded it.
Use a criticality score based on privilege, opacity, reach, update control, and replaceability. High scores require a threat model, binary review, vendor evidence, runtime observation, and an exit plan.
Inspect Binary-Only Mobile SDKs
Source-level software composition analysis can’t fully describe an AAR, XCFramework, static library, or obfuscated binary. Treat opaque code as a vendor-delivered executable product.
Unpack mobile artifacts and inventory native libraries, manifests, entitlements, URL schemes, privacy declarations, embedded frameworks, symbols, certificates, and network indicators. Compare every new version with the previous binary. A one-line vendor changelog doesn’t explain a new microphone permission or host.
set -euo pipefail
artifact="vendor-sdk.aar"
expected_sha256="REPLACE_WITH_APPROVED_SHA256"
actual_sha256="$(sha256sum "$artifact" | cut -d' ' -f1)"
if [[ "$actual_sha256" != "$expected_sha256" ]]; then
printf 'SDK digest mismatch\n' >&2
exit 1
fi
rm -rf /tmp/vendor-sdk-review
mkdir -p /tmp/vendor-sdk-review
unzip -q "$artifact" -d /tmp/vendor-sdk-review
printf 'Verified and unpacked %s\n' "$artifact"
Run the SDK in a controlled test app. Exercise initialization, consent denial, backgrounding, logout, and network failure. Observe destinations, payload classes, file access, dynamic loading, and behavior before consent. Don’t intercept real customer data.
A vendor questionnaire complements evidence; it doesn’t replace it. Contractual patch timelines, breach notice, subprocessor disclosure, and artifact retention help when incidents arrive.
Generate SBOMs From Source and Final Binaries
An SBOM lists components, but its value depends on coverage, identity quality, and connection to the shipped artifact. Generate one during dependency resolution and compare it with binary analysis of the final APK, AAB-derived APKs, or IPA.
Use CycloneDX or SPDX, retain package URLs and cryptographic hashes where available, and include native libraries. Resolve naming differences so vulnerability systems don’t treat one component as several unrelated records.
A source SBOM can include test dependencies absent from release. A binary SBOM can reveal bundled components missing from source manifests. Reconcile the difference and document justified exclusions.
Use SBOM identity that survives an incident
Component names alone are weak join keys. Preserve ecosystem, namespace, version, package URL, supplier, and artifact hash where available. Record dependency relationships so responders can distinguish a directly selected SDK from a native library embedded three levels below it. Keep the raw generated inventories as well as the normalized result.
Attach the SBOM to one release digest, not just a marketing version. Android split APKs derived from an AAB complicate what users receive, while iOS processing can alter store-delivered packaging. Retain the submitted artifact and store evidence, and document which transformations occur after submission.
Vulnerability matching needs human triage. A version match doesn’t prove exploitability, and absence of a match doesn’t prove safety. Record reachability, configuration, platform, mitigations, owner, decision date, and expiry. Revisit accepted risk when code paths, advisories, or threat intelligence change.
Sign or attest the SBOM and bind it to the artifact digest. An unsigned inventory stored beside a binary can be replaced during the same compromise. OWASP’s MASVS code control provides a mobile verification baseline, while CycloneDX defines a widely used BOM format.
Harden CI as a Production System
CI runs untrusted project code while holding valuable tokens and access. Separate pull-request testing from trusted release jobs and minimize what each job can reach.
Use ephemeral isolated runners for releases. Pin third-party CI actions by immutable commit, not a moving tag. Restrict outbound network where practical. Issue short-lived workload identities instead of static cloud keys. Protect caches from writes by untrusted branches.
Release jobs should accept a reviewed commit, controlled toolchain, locked inputs, and explicit parameters. They should emit the artifact, logs, SBOM, provenance, test results, and digest without manual file replacement.
Two-person review matters most for workflow files, build plugins, signing configuration, entitlement changes, and dependency verification metadata. A feature-code approval shouldn’t automatically authorize new CI execution.
Make secret access stage-specific
A release pipeline shouldn’t expose every secret from its first step. Dependency resolution needs registry credentials, testing may need disposable service accounts, signing needs artifact approval, and store upload needs a narrow publishing identity. Issue access only at the stage that uses it and revoke it when the stage ends.
Assume build code can read its environment. Masked logs don’t stop exfiltration through a network request, artifact, test report, or cache. Network policy, isolated runners, short-lived credentials, and separate trust zones provide stronger controls than secret-name conventions.
Record which identity requested and used each credential. Alert on release credentials outside expected branches, runner pools, times, and repositories. Rotate immediately after suspected exposure, then inspect what the identity could reach. Rotation without scope analysis leaves the incident unanswered.
Protect Signing and Store Authority
Signing keys and store accounts can convert a compromised build into a trusted update. Isolate them from ordinary development and require auditable release authorization.
For Android, understand the separation between upload key and Google Play App Signing key. Protect the upload path, console roles, service accounts, and recovery process. Verify the digest uploaded to the store against the approved release evidence.
For Apple, restrict App Store Connect roles, protect distribution identities and API keys, and review entitlements and provisioning profiles. Use managed signing deliberately, with clear authority and logs.
Hardware-backed or managed signing reduces key extraction risk but doesn’t validate the artifact. The signing service should require provenance or an approved digest, not sign arbitrary bytes submitted by any CI job.
Create a Release Evidence Bundle
A release evidence bundle answers what was built, from which inputs, by which isolated process, after which checks, and who authorized distribution.
{
"release": "mobile-8.4.0",
"commit": "FULL_REVIEWED_COMMIT_SHA",
"artifact": {
"name": "app-release.aab",
"sha256": "ARTIFACT_SHA256"
},
"sbom": {
"format": "CycloneDX",
"sha256": "SBOM_SHA256"
},
"builder": "isolated-mobile-release-v3",
"approvals": ["release-manager", "security-policy"],
"provenance": "SIGNED_ATTESTATION_REFERENCE"
}
Store the bundle immutably and make the artifact digest the join key. The store submission record should reference the same digest. Incident responders can then identify affected releases without reconstructing a vanished runner.
SLSA’s supply-chain framework describes build provenance and increasing assurance. Apply it incrementally. Honest, signed provenance from a controlled builder is more useful than claiming a maturity level the pipeline doesn’t meet.
Budget for Dependency Removal
A dependency is controllable only if the team can disable, replace, or isolate it within the business’s incident window. This is the dependency removal budget.
For every critical SDK, estimate detection-to-disable time, code ownership, abstraction quality, data migration, legal approval, store review delay, and minimum supported app version. A remote feature flag can stop calls, but it can’t remove already shipped code.
Wrap vendor SDKs behind narrow interfaces and prevent their types from spreading through domain code. Keep a no-op or alternate implementation for nonessential services. For payments or identity, test a documented degraded mode.
Mobile release latency matters. Users may not update, and stores may delay review. Server-side containment, key revocation, endpoint shutdown, and feature disablement must complement binary replacement.
Monitor Released Dependencies Continuously
Vulnerability scanning at build time protects only the release moment. New CVEs, maintainer compromises, vendor notices, and policy changes arrive later.
Continuously match deployed SBOMs against advisories. Track which app versions and installation populations include an affected component. Add VEX-style analysis where a vulnerable function is unreachable, but require evidence and an expiry date for that judgment.
Monitor SDK network behavior, privacy reports, crash changes, and unexpected permission or endpoint drift in test environments. Runtime self-protection isn’t a substitute for removing compromised code.
Set patch service levels by exploitability, capability, exposure, and removal budget. CVSS alone doesn’t capture a deeply privileged mobile SDK or the delay of store distribution.
Practice a Mobile Supply Chain Incident
A tabletop should begin with a plausible signal: a vendor discloses compromise, a package checksum changes, an SBOM component gains a critical advisory, or production traffic reveals an unknown SDK endpoint.
- Freeze affected builds and preserve runner, registry, and store evidence.
- Identify artifact digests and app versions containing the component.
- Disable server trust, SDK features, tokens, or endpoints where safe.
- Determine whether signing or store authority was touched.
- Build a known-good replacement through a clean controlled path.
- Submit updates and communicate required user action.
- Monitor residual vulnerable versions and enforce backend minimums when justified.
Don’t destroy evidence by rerunning mutable jobs. Capture package artifacts, lockfiles, verification metadata, provenance, logs, signing records, and vendor communications.
Postmortems should improve controls, not merely add scanners. Ask which trust transition failed and why evidence didn’t stop or reveal it sooner.
Frequently Asked Questions
What is mobile supply chain security?
Mobile supply chain security protects every input and authority used to produce and distribute an Android or iOS application. It covers source, dependencies, binary SDKs, build tools, CI runners, identities, signing keys, artifacts, app-store accounts, and update channels. The goal is to make unauthorized change difficult, detectable, attributable, and containable.
How do I secure mobile dependencies?
Pin versions and repositories, verify checksums or signatures, commit application lock state, review update diffs, classify packages by capability, and scan both source resolution and final binaries. Give high-risk build plugins and SDKs stronger approval. Continuously map deployed SBOMs to new advisories and maintain an owned removal path.
Why isn’t code signing enough?
Code signing proves that a particular signing identity approved an artifact. It doesn’t prove the source was reviewed, dependencies were benign, the builder was clean, or the signer checked provenance. A compromised pipeline can produce malicious code and sign it correctly. Bind signing authorization to an approved artifact digest and trusted build evidence.
What is the difference between an SBOM and provenance?
An SBOM describes components believed to be in an artifact. Provenance describes how the artifact was built, including source and builder context. Neither alone proves complete security. Bind both to the final artifact digest, sign their attestations, reconcile source and binary inventories, and retain them with store-submission evidence.
When should a binary-only SDK be rejected?
Reject it when capability exceeds business value, the vendor can’t provide trustworthy origin and patch commitments, analysis reveals unexplained behavior, or the team can’t contain and remove it within the incident window. Opaque code isn’t automatically malicious, but it demands stronger binary inspection, runtime testing, contract controls, and an exit plan.
How can CI pipelines protect signing keys?
Use ephemeral isolated release runners, short-lived identities, restricted signing services, minimal roles, and auditable authorization. Keep untrusted pull-request code away from release credentials. A signing service should accept only artifacts whose digests match approved provenance and policy. Protect store API keys and recovery workflows with the same seriousness as signing material.
Why scan the final APK or IPA?
The final binary can contain native libraries, transitive SDK code, generated assets, entitlements, permissions, and embedded frameworks that source manifests don’t reveal accurately. Binary analysis validates what ships rather than what build files claim. Compare final inventory and behavior with the source SBOM and investigate unexplained differences before release.
When should reproducible builds be required?
Require or prioritize them for high-assurance libraries, sensitive release paths, and components where independent verification justifies the cost. Mobile toolchains may contain nondeterministic inputs, so full bit-for-bit reproduction can be hard. Remove nondeterminism incrementally and use signed provenance plus artifact digests where complete reproduction isn’t yet practical.
How quickly should a risky SDK be removable?
The answer follows business impact and store latency. Critical components need immediate server-side containment and a tested replacement release path. Estimate the full dependency removal budget: feature disablement, code change, data migration, testing, approval, store review, rollout, and vulnerable-client population. If that time exceeds risk tolerance, redesign the integration before an incident.
Is mobile supply chain security worth the pipeline cost?
Yes, because one poisoned compiler, plugin, or SDK can reach every user through a legitimately signed update. Apply controls by capability rather than making every package equally expensive. Start with locked inputs, isolated releases, artifact digests, binary-aware SBOMs, protected signing, and an incident drill. These controls also improve release reliability and audit speed.
Make Releases Verifiable and Removable
Mobile supply chain security isn’t a scanner added before store upload. It’s a chain of verifiable decisions with containment at every high-value transition.
- Map trust transitions from workstation to installed app.
- Pin and verify packages, plugins, and toolchains.
- Inspect opaque SDK binaries and their runtime behavior.
- Bind SBOM, provenance, approval, and store upload to one digest.
- Engineer every critical dependency for emergency removal.
Start with the last production artifact. Can the team prove its commit, dependencies, builder, signer, and store submission without rebuilding it? Then choose the riskiest SDK and attempt to remove it under a deadline. Those two exercises expose more truth than a long compliance checklist.
