Module 18 — Third-Party SDKs

Por

Scope & ethics: This module is for authorized, lab-only testing and for defensive hardening of your own apps. We’ll cover inventorying and testing third-party SDKs, tracking transitive dependencies, vetting privacy/telemetry behavior, and securing your build/signing pipeline end-to-end. Emphasis is on evidence-driven analysis, repeatable labs, and CI/CD enforcement—not exploitation of systems outside written scope.

18.0 Learning objectives

By the end, you will be able to:

  • Produce a complete SBOM (Software Bill of Materials) of your Android app (direct + transitive).
  • Identify risky SDKs (over-privileged, ad/analytics, webview wrappers, crash reporters) and their network endpoints.
  • Test SDK behavior dynamically (network/IPC/storage) and validate privacy assertions.
  • Audit code signing, release keys, and Android App Signing settings; lock down keystore access.
  • Implement reproducible builds, artifact integrity, and supply-chain controls (pinning, verifications, attestation of provenance).
  • Enforce CI/CD gates for dependency risk, signature/verifier checks, and tamper resistance.
  • Create a remediation plan with owners, timelines, and measurable acceptance criteria.

18.1 Threat model (SDKs & build chain)

  • Dependency risk: A benign SDK update introduces sensitive data capture, trackers, or exploitable code (RCE, webview bridge exposure).
  • Transitive drift: A sub-dependency pulls in vulnerable libs (e.g., outdated OkHttp, crypto misuse).
  • Build system compromise: Malicious plugin/Gradle script executes during build.
  • Key compromise: Release keystore leak or misconfigured Android App Signing enrollment.
  • Artifact tampering: Re-signed APKs, modified bundles, or CI artifacts altered post-build.
  • Telemetry/privacy: SDKs exfiltrate PII/device IDs outside policy or region.

18.2 Inventory & SBOM (what you ship)

18.2.1 Generate SBOM (CycloneDX or SPDX)

Gradle (CycloneDX plugin) example:

plugins {
  id "org.cyclonedx.bom" version "1.8.2"
}
cyclonedxBom {
  includeConfigs = ["releaseRuntimeClasspath"]
  skipConfigs = ["debugCompileClasspath"]
  projectType = "application"
  schemaVersion = "1.5"
}

Run:

./gradlew :app:cyclonedxBom
# Output: app/build/reports/bom.json (CycloneDX)

What to include: group:artifact:version, checksums, licenses, PURLs, and source repositories when available.

18.2.2 Lock files & reproducibility

  • Gradle version catalogs (libs.versions.toml) with strict versions.
  • Dependency lock:
./gradlew dependencies --write-locks
  • Check lock files into VCS; block builds that resolve new versions without a PR.

18.2.3 Map owners & purpose

Create an SDK registry:

LibraryOwner (team/vendor)PurposeVersionPerms usedNetwork domainsData types touched

Populate from SBOM + static scan (see §18.4).

18.3 Policy & risk classification

Define a simple, enforceable rubric:

  • Tier 0 (Allowed, core): essential frameworks (AndroidX, Kotlin Stdlib).
  • Tier 1 (Low-risk): small utilities, no network/PII.
  • Tier 2 (Medium): analytics/crash libs with data minimization and DPAs.
  • Tier 3 (High): adtech/monetization, webview wrappers, device fingerprinting.
  • Forbidden: SDKs with dynamic code loading, obfuscated network egress, or known CVEs without remediation.

Every SDK must have:

  • Owner and business justification.
  • Data minimization statement (fields collected, retention).
  • Update SLA (how fast to patch CVEs / major updates).
  • Offboarding plan (how to remove cleanly).

18.4 Static analysis of SDKs

18.4.1 What to scan

  • Permissions: Compare AndroidManifest.xml from AARs/merged manifest to your intent.
  • Exported components: Activities/Services/Receivers/Providers added by SDKs (check android:exported, permissions).
  • WebView usage: addJavascriptInterface, file access flags.
  • Native libs: .so files (ABI coverage, dangerous syscalls in NDK code).
  • Crypto & RNG: look for AES/ECB, static IVs, MD5/SHA1.
  • Dynamic code loading: DexClassLoader, reflection for network-fetched code.

18.4.2 Commands / steps

Merged manifest inspection:

./gradlew :app:processReleaseMainManifest
cat app/build/intermediates/merged_manifests/release/AndroidManifest.xml | sed -n '1,300p'

Decompile AAR/JAR for SDKs:

unzip -l ~/.gradle/caches/modules-2/files-2.1/<group>/<artifact>/<version>/*.aar
# extract classes.jar and inspect with JADX
jadx -d out classes.jar
grep -RIn "@JavascriptInterface|DexClassLoader|Cipher.getInstance|addJavascriptInterface" out/

Permissions diff:

  • Capture before/after merged manifest; fail CI if SDK inflates permissions beyond policy.

18.5 Dynamic analysis of SDK behavior (lab)

18.5.1 Network egress mapping

  • Run app through mitmproxy/Burp (lab CA installed).
  • Exercise screens using each SDK feature; export HTTP history.
  • Classify endpoints (analytics, crash, ad, config, feature flags).
  • Record payload schema: fields sent, identifiers (GAID/AAID, Android ID, vendor IDs), any PII.

Evidence to keep: proxy project file, PCAPs, annotated endpoints table, timestamps (UTC), app/SDK versions.

18.5.2 Storage & device artifacts

  • Inspect app private storage for SDK caches, databases, crash attachments.
  • Look for PII in plaintext or long-lived unique identifiers.
  • Verify data deletion on logout and on “Delete account” flows.

18.5.3 IPC & component exposure

  • Attempt to start/bind exported components from SDKs (see Module 14 commands).
  • Confirm signature/permission guards.

18.5.4 Feature toggles & remote config

  • Capture SDK bootstraps (config JSON).
  • Validate that remote flags cannot enable hidden debugs, logging of PII, or dynamic code without app update.

18.6 Privacy & data governance

  • Maintain a data inventory per SDK: what fields, lawful basis, retention, region routing (e.g., EU vs. US).
  • Enforce user consent gates before initializing telemetry (IAB TCF 2 for ads where applicable).
  • Support opt-out paths and Do Not Track where required.
  • Configure crash/analytics SDKs to scrub secrets (beforeSend hooks).
  • Ensure child/age gates if app may serve minors.

Deliver a Privacy Controls Matrix:

SDKInit gated by consent?PII collectedRegionRetentionScrubbing hooks

18.7 Build & signing integrity

18.7.1 Keystore hygiene (self-managed)

  • Store release keystore in HSM/KMS or a sealed secrets store; never in repo.
  • Use per-environment signing configs; restrict access by role.
  • Rotate upload keys and signing keys per policy; document procedures.
  • Enforce sig alg: e.g., SHA-256 with RSA-2048+/ECDSA-P256.

Gradle (safe loading via env):

android {
  signingConfigs {
    release {
      storeFile file(System.getenv("KEYSTORE_PATH"))
      storePassword System.getenv("KEYSTORE_PASS")
      keyAlias System.getenv("KEY_ALIAS")
      keyPassword System.getenv("KEY_PASS")
      enableV3Signing true
      enableV4Signing true
    }
  }
}

18.7.2 Android App Signing (Play)

  • Understand upload key vs app signing key.
  • Enforce 2FA, restricted console roles, and signing key upgrade plan.
  • Keep off-store distribution (enterprise) with separate key lineage.

18.7.3 Provenance & tamper detection

  • Use reproducible builds: fixed timestamps, stable ordering, documented environment (JDK, AGP, R8).
  • Verify APK Signature Scheme v2/v3/v4 presence.
  • Check integrity post-build:
apksigner verify --print-certs app-release.apk
jarsigner -verify -verbose -certs app-release.apk
  • Hash artifacts and publish checksums/SLSA provenance (see §18.11).

18.8 Reproducible & deterministic builds

  • Pin Android Gradle Plugin, Gradle, JDK versions.
  • Use Docker/remote build runners with immutable images.
  • Normalize file timestamps (Gradle supports reproducibility for many tasks).
  • Avoid embedding build time or git SHA directly into app unless isolated under a single resource (documented) to compare.

Provenance record (example fields): AGP version, Gradle version, JVM, OS image hash, dependency lock hash, commit SHA.

18.9 Dependency risk management (CI gates)

18.9.1 Automated scanners

  • OWASP Dependency-Check, Snyk, OWASP DC Gradle plugin, or commercial equivalents.
  • Fail on CVSS ≥ threshold; create ticket with affected SDK, loaded code paths, SLA.

18.9.2 Allowlist/denylist

  • Maintain a permit list for approved SDK coordinates.
  • Denylist classes/APIs (e.g., DexClassLoader, addJavascriptInterface) unless justified with a waiver.

18.9.3 Release checklist

  • SBOM attached to release artifact.
  • Signatures verified in CI.
  • Diff of merged manifest vs previous release (permissions, exported comps).
  • Network endpoint diff (from lab capture) signed off.

18.10 Runtime defenses & anti-tamper (client-side)

  • Integrity signals: Use Play Integrity/Key Attestation (Module 12) to tie app identity and signing cert digest to server policy.
  • Pinning: SPKI pin to your API; don’t pin to SDK endpoints you don’t control (or do so only with vendor coordination).
  • Self-checks: Optional code to verify embedded SDK code hashes at runtime—treat as telemetry only; decisions remain server-side.

18.11 Build provenance & artifact supply-chain

  • Adopt SLSA (Supply-chain Levels for Software Artifacts) level appropriate to your org.
  • Produce attestations (in-toto) that bind SBOM + source + builder identity to the artifact.
  • Store release artifacts and provenance in an immutable registry (e.g., OCI-style, artifact repository).

Minimal provenance JSON (example fields):

{
  "builder": "gh-runner-image@sha256:...",
  "source": "git@repo#commit:abc123",
  "dependencies_lock": "sha256:...",
  "sbom": "cyclonedx@sha256:...",
  "apksigner_cert_shas": ["sha256:..."],
  "time_utc": "2025-09-27T15:00:00Z"
}

18.12 Evidence model & severity rubric

18.12.1 Evidence to collect

  • SBOM (JSON) + checksum.
  • Merged manifest diff (permissions/components).
  • Proxy/PCAP logs annotated with SDK endpoint mapping.
  • Storage artifacts showing SDK caches/PII (hashed).
  • Signing verification output & cert chain details.
  • CI logs for dependency scans and signature checks.
  • Team approvals/waivers tied to release.

18.12.2 Severity (examples)

  • Critical: SDK exfiltrates credentials/PII without consent; dynamic code loading from untrusted origin; signing keys exposed; tampered build shipped.
  • High: SDK adds exported component enabling unauthorized actions; serious CVE in active code path; analytics sends stable device ID + PII without controls.
  • Medium: Over-collection of metadata; missing consent gating; inflated permissions unused by app.
  • Low: Non-actionable metadata gaps; outdated SDK with no known exploitable vector.

18.13 Practical labs (authorized, reproducible)

Lab 18-A — SBOM + permission drift

  1. Generate CycloneDX SBOM for releaseRuntimeClasspath.
  2. Build baseline manifest and a build with a new SDK; diff permissions/exported components.
  3. Output an alert in CI if drift detected.

Deliverables: SBOM JSON, manifest diff, CI log snippet.

Lab 18-B — SDK network behavior

  1. In a lab device, enable proxy and exercise screens using SDK features.
  2. Export Burp/mitm session; tag flows per SDK.
  3. Produce endpoint inventory with payload schemas; mark PII.

Deliverables: proxy project, endpoints CSV, screenshots, hashes.

Lab 18-C — Crash/analytics PII scrubbing

  1. Trigger handled/unhandled exceptions.
  2. Verify beforeSend scrubber masks tokens/passwords.
  3. Prove opt-out path prevents telemetry init.

Deliverables: SDK config, request samples before/after scrub, app logs.

Lab 18-D — Signing & provenance

  1. Verify APK signature with apksigner, extract signer cert SHA-256.
  2. Rebuild in clean runner; compare SHA/size diffs and record provenance JSON.
  3. Validate reproducibility criteria or explain deviations (R8 mapping, timestamps).

Deliverables: apksigner output, provenance record, notes on determinism.

18.14 Developer hardening checklist (copy-paste into PR template)

  • SBOM generated; no unapproved SDKs introduced.
  • Merged manifest reviewed; no unexpected permissions/exported comps.
  • SDKs initialized after consent; telemetry scrubbers configured.
  • No dynamic code loading; no DexClassLoader without waiver.
  • WebView settings in SDK UIs audited; no bridges on remote content.
  • Storage review: SDK caches don’t store PII in plaintext; cleared on logout.
  • Dependency scan: no High/Critical CVEs unresolved.
  • Signing setup: keys not in repo; CI uses env-injected secrets; v2/v3 signing on.
  • Provenance & checksums attached to artifacts.
  • Endpoint inventory updated; privacy matrix updated.

18.15 CI/CD guardrails (ready-to-adopt)

  • Step 1 (SBOM): generate CycloneDX; upload as artifact.
  • Step 2 (Deps scan): run Snyk/OWASP DC on SBOM; fail on thresholds.
  • Step 3 (Manifest diff): parse merged manifest and compare to previous release; fail on drift without SECURITY_APPROVED=true.
  • Step 4 (Sign verify): run apksigner verify; capture signer cert SHA-256; compare to allowlist.
  • Step 5 (Provenance): emit JSON attestation with environment hash; publish alongside APK/AAB.
  • Step 6 (Waiver ledger): PR labels with risk tier and expiry date; require security sign-off.

18.16 Communication & vendor management

  • Maintain vendor contacts, DPAs, and security advisories subscription for each SDK.
  • Request changelogs and data maps before version upgrades.
  • For high-risk SDKs, require security review call and a sandbox test prior to rollout.
  • Establish rollback plans and feature flags to disable SDK runtime.

18.17 Common pitfalls & how to avoid them

  • “It’s only analytics” → still can exfiltrate PII; gate by consent; scrub aggressively.
  • Silent permission creep → always diff merged manifest.
  • Unpinned, silent updates → pin versions; require PR to bump.
  • Keystore in repo → move to KMS/HSM; rotate keys; restrict access.
  • Builds on dev laptops → move to hardened, reproducible CI runners.
  • Opaque vendor behavior → insist on endpoint lists, data dictionaries, and SDK privacy modes.

18.18 Deliverables

  • SDK Registry & Privacy Matrix (owners, endpoints, data).
  • SBOM (CycloneDX/SPDX) + dependency risk report.
  • Manifest & endpoint diffs for each release.
  • Signing/provenance bundle (apksigner output, provenance JSON, checksums).
  • CI policy files (lockfiles, deny/allow lists, scan configs).
  • Waiver ledger with expiry and mitigation plan.

18.19 “At a glance” cheat-sheet

  • Know what you ship: SBOM + endpoint inventory.
  • Gate everything: consent, permissions, manifests, versions.
  • Least data: scrub, minimize, regionalize.
  • Lock the chain: signed, reproducible builds; keys in KMS; provenance attached.
  • Automate drift detection: manifest/endpoint diffs in CI.
  • Own your SDKs: named owners, update SLAs, offboarding paths.