Software Supply Chain Security for Consumer Mobile Apps: A 90-Day Plan

Software supply chain security for a consumer mobile app company comes down to three jobs: know every SDK, framework and open source package compiled into each app version your users have installed, know who controls each of those components and what data it touches, and run a patch and review clock that can push a fix through two app stores and prove it to a store reviewer, a regulator or a board. The hard part is that you ship a binary to millions of phones you do not control, and much of the code inside it comes from SDK vendors chosen by teams outside engineering. A focused team can build the inventory, the intake rules and the release gates in about 90 days.

This guide covers what software consumer app companies run, the US rules and app store policies that apply, four recent public incidents, the people who own each piece, and a 30, 60 and 90 day plan that works with any tools. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice; your counsel and your store agreements decide what applies to you.

Key takeaways

• An app is your code plus open source from CocoaPods, Swift Package Manager, Gradle and Maven, npm or pub, plus closed third-party SDKs, plus whatever your build pipeline pulls in. The program has to cover all four, for every app version still in users' hands.
• Both app stores put the SDK problem on you. Apple's third-party SDK page says that when you use a third-party SDK, you are responsible for all the code it includes in your app. Google Play's Data safety guidance says it is your responsibility to ensure third-party code complies with Play policies.
• Apple requires privacy manifests, and signatures for binary dependencies, for a published list of commonly used SDKs. Google Play requires new apps and updates to target Android 16 (API level 36) from 31 August 2026, with extensions available to 1 November 2026.
• The amended COPPA Rule's compliance date was 22 April 2026. Section 312.8 requires a written information security program and written assurances from third parties that receive children's data. Health and fitness apps also fall under the FTC's Health Breach Notification Rule.
• The four incidents below reached app makers through code they did not write: location SDKs behind two FTC orders (January 2024), flaws in the CocoaPods package server (disclosed July 2024), a compromised GitHub Action (March 2025) and a self-replicating npm worm (September 2025).
• Six roles own the problem, including the growth and vendor teams who add many SDKs.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, software composition analysis (SCA), vulnerability management with EPSS and KEV, reachability analysis and prioritization, policies, gates and guardrails, autonomous remediation (ships switched off), license compliance, SAST, DAST, Third-Party Risk Manager (TPRM), the Compliance and GRC suite, Portal audit trails, the CLI, the local runner and the Safeguard mobile app.

What software consumer mobile app companies run

Each family below has a different owner and a different answer to the question "if this has a critical flaw tomorrow, how does the fix reach the user?"

The app itself: your code plus open source

A native iOS app is Swift or Objective C code plus libraries pulled through Swift Package Manager or CocoaPods. A native Android app is Kotlin or Java plus libraries resolved by Gradle from Maven repositories. Cross-platform apps add a second layer: React Native and Expo apps carry an npm dependency tree that is often larger than the native one, and Flutter apps resolve Dart packages from pub.dev and then pull native plugins through CocoaPods and Gradle underneath. A single consumer app can therefore have four lockfiles: Podfile.lock or Package.resolved, a Gradle lockfile or dependency verification file, package-lock.json or yarn.lock, and pubspec.lock.

The fix path is slow: change the dependency, rebuild, sign, pass review in both stores, roll out in stages and wait for users to update.

Third-party SDKs

Most consumer apps embed SDKs for product analytics, install attribution, advertising and mediation, crash reporting, push notifications, deep links, sign-in, payments and subscriptions, customer support chat, feature flags and remote configuration, and more recently AI features. Many arrive as precompiled binaries (an XCFramework or an AAR), so you cannot read what they do. Many are requested by growth or monetization teams, and the decision is often made in a vendor contract rather than a code review.

An SDK runs with your app's permissions and inside your app's identity. Whatever data it reads, the store and the regulator treat as data your app collected.

Binary frameworks, game engines and native libraries

Game engines, video players, mapping libraries and machine learning runtimes ship large native components that often bundle their own copies of libraries such as OpenSSL or SQLite. A scanner that reads only your manifest will not see a copy statically linked inside a vendor binary.

Over-the-air updates, remote config and webviews

Teams change app behavior without a store release through JavaScript bundle updates, remote configuration and webview content. Each is a channel for code or content that skipped store review. Both stores restrict it, and each needs an owner and a record of what was pushed when.

The backend the app talks to

APIs, authentication, backend-as-a-service platforms, content delivery and payment processing are built from the same open source ecosystems as any web service. A flaw there can be fixed in hours, so the backend usually gets attention first and the app binary last.

The build and release pipeline

Mobile builds run through CI workflows, Gradle and CocoaPods plugins, fastlane lanes and code signing. The pipeline holds the Apple distribution certificate, the Android upload key and store API credentials, so a compromised build step can sign and ship code with your identity.

The regulations and frameworks that apply

No single US law covers the consumer app supply chain. The duties come from the FTC, children's and health privacy rules, state privacy laws, securities law and, above all, the two app stores, which enforce their policies at every submission.

FTC Act Section 5 and FTC orders about SDK data

Section 5 of the FTC Act prohibits unfair or deceptive acts or practices, and the FTC uses it against companies whose apps or SDKs collect and share data in ways consumers did not expect. The two January 2024 orders in the incidents section concerned location data gathered through SDKs in third-party apps, and both required deletion of data and checks on suppliers.

The amended COPPA Rule (16 CFR Part 312)

If your app is directed to children under 13, or you have actual knowledge that you collect personal information from them, the Children's Online Privacy Protection Rule applies. The FTC's amendments took effect on 23 June 2025, and the compliance date for most provisions was 22 April 2026. Section 312.8 now requires operators to establish, implement and maintain a written information security program appropriate to their size and the sensitivity of the data, with a designated coordinator, annual risk assessments, safeguards, regular testing and at least annual evaluation. Before children's personal information is disclosed to a third party, including an SDK provider, the operator must take reasonable steps to confirm the third party can maintain its confidentiality, security and integrity, and obtain written assurances that it will.

For a family, education or gaming app, every SDK that receives children's data needs a written assurance on file.

The FTC Health Breach Notification Rule (16 CFR Part 318)

Health and fitness apps that are not covered by HIPAA can fall under the FTC's Health Breach Notification Rule. The FTC finalized changes on 26 April 2024 that, in its words, clarify the rule's application to health apps and similar technologies, and that make clear a "breach of security" includes an unauthorized disclosure, not only a hack. An SDK that sends health data to an advertising platform without authorization can therefore trigger notification duties to consumers, the FTC and sometimes the media.

State privacy laws and the California cybersecurity audit regulations

State privacy laws, led by the California Consumer Privacy Act as amended by the CPRA, govern how apps collect, sell and share personal information, including through advertising SDKs. California's privacy agency adopted regulations, approved on 22 September 2025 and effective 1 January 2026, that require certain businesses to conduct risk assessments and complete annual cybersecurity audits. Check the agency's pages for the dates that apply to your business, because they are phased.

SEC cybersecurity disclosure rules for listed companies

A listed company discloses a material cybersecurity incident on Form 8-K Item 1.05 within four business days of determining materiality, and describes its processes for managing cybersecurity risk, including third-party service provider risk, under Regulation S-K Item 106.

Apple's App Store rules

Apple's third-party SDK requirements page is direct about who owns the risk. It says that when you use a third-party SDK with your app, you are responsible for all the code the SDK includes, and you need to be aware of its data collection and use practices. Apple introduced privacy manifests and SDK signatures at WWDC23. Xcode combines SDK privacy manifests into one report, and when you adopt a new version of a signed SDK, it validates that the same developer signed it.

For SDKs on Apple's published list of commonly used SDKs, you must include the privacy manifest when you submit a new app that includes them, or an update that adds one, and signatures are also required where the listed SDKs are used as binary dependencies. Any version of a listed SDK, and any SDK that repackages one, is covered. The list includes common networking, image loading, analytics and messaging components and cross-platform framework pieces such as Flutter.

Apple's App Review Guidelines add a code rule. Guideline 2.5.2 says apps should be self-contained in their bundles and may not download, install or execute code that introduces or changes features or functionality of the app. That rule shapes how far an over-the-air update can go.

Google Play's rules

Google Play's Data safety guidance says developers must disclose data collected and shared through third-party libraries and SDKs, and that it is your responsibility to ensure such code complies with Play Developer Program policies. The Device and Network Abuse policy says an app distributed via Google Play may not modify, replace or update itself using any method other than Google Play's update mechanism, and may not download executable code such as dex, JAR or .so files from a source other than Google Play. The policy applies to third-party SDKs in your app as well.

Google Play also sets a target API level clock. From 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension available on request to 1 November 2026. Existing apps must target Android 15 (API level 35) or higher to remain available to new users on newer devices. Raising the target level often forces SDK upgrades.

Standards worth borrowing

• OWASP MASVS. MASVS-CODE-3 in the Mobile Application Security Verification Standard says the app only uses software components without known vulnerabilities, and its related weaknesses include dependencies with known vulnerabilities and enforced updating not implemented.
• NIST SP 800-218, the Secure Software Development Framework (SSDF). Its practices on protecting build environments and verifying third-party components apply to mobile pipelines.
• CISA's 2026 Minimum Elements for a Software Bill of Materials. This guidance updates and replaces the NTIA's 2021 minimum elements. Use it as the field list for your own SBOMs and for what you ask SDK vendors to deliver.

EU context: the Cyber Resilience Act

If you ship apps to EU users, the EU Cyber Resilience Act applies to products with digital elements, which includes software. The European Commission says reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the main obligations from 11 December 2027. It is context for this US-first guide.

Real public incidents from the last three years

The four incidents below come from official or primary sources, and the descriptions stick to what those sources say.

Location SDKs and two FTC orders (January 2024)

On 9 January 2024 the FTC announced a proposed order against the data broker X-Mode Social and its successor Outlogic. The FTC said the company collected precise location data from its own apps, from third-party apps that incorporate its SDK, and from other brokers, and sold data tied to mobile advertising IDs to hundreds of clients. The order bars it from sharing or selling sensitive location data, requires deletion of previously collected data and derived products unless consent is obtained or the data is deidentified, and requires it to assess its suppliers' consent practices. The FTC finalized it in April 2024.

On 18 January 2024 the FTC announced a proposed order against InMarket Media, which it said collected location data from its own apps and from third-party apps that incorporate its SDK, and failed to ensure those third-party apps obtained informed consent. The order prohibits selling or licensing precise location data and requires an SDK supplier assessment program. The FTC finalized it in May 2024.

For app makers, the relevance is the mechanism. In both cases the data flowed through an SDK running inside other companies' apps, and the app user saw only the app.

Flaws in the CocoaPods package server (disclosed July 2024)

CocoaPods is a long-standing dependency manager for iOS and macOS projects, and its trunk server controls who may publish each pod. On 1 July 2024, three vulnerabilities in the trunk server were published as CVE-2024-38368, CVE-2024-38366 and CVE-2024-38367. According to the CVE records, older pods that had moved from the pre-2014 workflow and were never claimed could still be claimed by someone else, the email verification step could be manipulated to run commands on the trunk server, and the session verification step could be manipulated to take over an owner's trunk account. The records reference fixes in the trunk server code and the project's own security write-up.

The relevance for an iOS team is that a dependency is only as trustworthy as the registry that serves it. The CocoaPods project has since published a plan to make trunk read-only: after a test run from 1 to 7 November 2026, it plans to stop accepting new Podspecs on 2 December 2026. Existing pods stay available, but no new versions will be published there, so a fix for a pod you resolve from trunk will have to come from somewhere else.

A compromised GitHub Action in thousands of pipelines (March 2025)

On 18 March 2025, CISA published an alert on the compromise of the third-party GitHub Action tj-actions/changed-files, tracked as CVE-2025-30066, and a related compromise of reviewdog/action-setup, tracked as CVE-2025-30154. CISA said the compromise allowed a remote attacker to discover secrets by reading actions logs, which could include valid access keys, GitHub personal access tokens, npm tokens and private RSA keys. CISA recommended identifying and rotating any secrets that may have been exposed, and pinning third-party actions to specific commit hashes.

Mobile build pipelines run third-party actions next to signing keys and store credentials.

A self-replicating worm in the npm registry (September 2025)

On 23 September 2025, CISA published an alert on a widespread supply chain compromise of the npm registry. CISA said a self-replicating worm, publicly known as Shai-Hulud, had compromised over 500 packages. After gaining access, the malware scanned for credentials, targeted GitHub personal access tokens and cloud API keys, exfiltrated them, and used compromised developer credentials to publish infected versions of other packages.

React Native and Expo apps, mobile web views and the JavaScript tooling around many native builds all depend on npm. CISA recommended reviewing dependencies, checking lockfiles for affected versions including nested ones, searching caches and artifact repositories, pinning to known safe versions, rotating developer credentials and enforcing phishing-resistant multifactor authentication.

What the four have in common

None started in an app maker's own code: SDK data practices, the registry behind iOS dependencies, a build step and a package ecosystem. In each, the first question was which of our apps, versions and pipelines include this component.

The personas who own the problem

Mobile supply chain risk is split across more teams than in most industries, because SDK decisions are often made by business teams and fixes ship through stores.

The CISO

The CISO needs one answer for the board, a regulator or, at a listed company, the Item 106 description: what third-party code runs in our apps, what data it touches, and how fast we can remove or fix it. That takes a dated inventory, a patch clock with a named owner, and evidence that exceptions were approved rather than ignored.

The VP of Engineering or head of mobile

This person owns release speed. They need one process across iOS, Android and cross-platform code, gates that fail only on the findings that matter, and fixes that arrive as pull requests rather than tickets. Their dates are the Google Play target API deadline, Apple's annual SDK and Xcode changes, and any store rejection that blocks a launch.

Mobile platform and release engineering

The platform team owns build machines, CI workflows, Gradle and CocoaPods configuration, signing and store submission. They need pinned and verified dependencies, CI actions pinned to commit hashes, signing keys out of reach of third-party build steps, and a gate that does not slow a hotfix.

The head of product security

They need findings ranked by exploitation and reachability, an exception process with expiry dates, and a fast way to check whether a new advisory affects any shipped app version.

The privacy and GRC lead

Privacy and GRC own COPPA, the Health Breach Notification Rule, state privacy laws, App Store privacy labels and the Play Data safety form. They need the SDK register as evidence: which SDKs receive which data, under which contract and written assurance, and whether the store disclosures match.

Growth, monetization and the vendor risk owner

Growth and monetization teams often add more SDKs than engineering does. They need a short intake checklist: the vendor's privacy manifest and Data safety guidance, a security contact, whether the SDK is a binary, and contract terms on data use, notification and SBOMs. The vendor risk owner needs the same records at renewal.

Step by step: a 30, 60 and 90 day plan that works with any tools

The plan assumes a handful of apps across iOS and Android, a backend and a small security team. Scale the scope; keep the order.

Days 1 to 30: see what you ship

1. List every app and every live version. Record each app's identifiers, platforms, current release and the oldest version still allowed to connect to your backend. That oldest version sets how far back the inventory goes.
2. Commit and keep every lockfile. Commit every lockfile for every app and tag it with each release. A release without its lockfile cannot be inventoried later.
3. Generate an SBOM per app, per platform, per release. Produce SPDX or CycloneDX output from the lockfiles at release time and store it with the release record. Use CISA's 2026 minimum elements as the field checklist.
4. Build the SDK register. For each third-party SDK, record the vendor, business owner, technical owner, purpose, whether it ships as source or binary, the data it collects, whether it has an Apple privacy manifest and signature, the vendor's Play Data safety guidance, the contract, and the date of the last review.
5. Record binary components you cannot scan. Engines, vendor XCFrameworks and AARs, and statically linked native libraries go into the register by name and version, with a note that their contents are vendor declared.
6. Inventory the build pipeline. List every CI workflow, third-party action, Gradle plugin, CocoaPods plugin and fastlane plugin, where signing keys live, and which steps can read them.

Days 31 to 60: control what changes

1. Turn on dependency gates in report-only mode. Scan every pull request and release branch, reporting critical and known exploited findings without failing builds for two to three weeks while you tune.
2. Then enforce on the narrow set. Fail release builds on critical findings and on any component in CISA's Known Exploited Vulnerabilities catalog, with an exception process that requires a justification, an approver and an expiry date.
3. Put an intake rule in front of new SDKs. No SDK goes into a release branch without a register entry, a named owner and the privacy and contract checks.
4. Pin and verify. Enable Gradle dependency verification, commit Package.resolved, avoid floating version ranges for SDKs, and plan where pods you still resolve from CocoaPods trunk will get fixes after it stops accepting new Podspecs on 2 December 2026.
5. Harden the pipeline. Pin third-party CI actions to full commit hashes, as CISA advised after the March 2025 compromise. Keep signing in a separate job that runs only trusted steps, and rotate tokens that ever appeared in logs.
6. Set a minimum version policy. Agree how the backend will require users to update when a shipped component is dangerous, and test that path on both platforms.

Days 61 to 90: prove it works

1. Measure the clock. Track time from advisory to merged fix, from merged fix to store approval, and from approval to the share of active users on the fixed version. The last number is the one that matters for risk.
2. Run a tabletop. Rehearse an SDK compromise: a vendor announces that a version of its SDK leaked data or contained harmful code. Walk through finding affected versions, disabling the SDK remotely if possible, shipping an update, updating store disclosures and deciding on notifications.
3. Request SBOMs from your critical SDK vendors. Start with SDKs that are binaries, receive personal data or run in child-directed apps. Ask for a format and a refresh cadence.
4. Assemble the evidence binder. Collect the SBOMs, SDK register, gate results, exception records and tabletop notes for COPPA, state privacy assessments, audits and Item 106.
5. Report to leadership. One page: apps and versions covered, SDKs reviewed, gate results, open exceptions, clock metrics and the next quarter's work.

A decision table for an SDK advisory

Illustrative scenario: an npm compromise during a release week

This is an illustrative scenario with invented round numbers, not an account of any real company. A consumer app company ships a React Native app with about 1,200 npm packages in its lockfile. A public alert names compromised package versions. The team searches its stored SBOMs and finds one affected version in a development dependency on the current release branch, and none in the last three shipped releases. Because the affected install step ran in CI, the platform team rotates the CI secrets it could read, reverts the lockfile, rebuilds and confirms the candidate is clean. The release slips one day instead of the several it would take to reconstruct what past releases contained.

How Safeguard does this

Everything above works without Safeguard. This section maps the plan to Safeguard flows from docs.safeguard.sh. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the code you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM, GA) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Safeguard's offering lists Maven and Gradle and npm among the ecosystems SCA covers, which takes in Android dependencies and the JavaScript layer of React Native apps. Per the docs, you connect repositories under Integrations, or upload files, and Safeguard creates the project and its SBOM. Per the continuous scanning docs, existing projects are re-evaluated when vulnerability data changes, so a new KEV entry is matched against releases you already scanned.

If your source code may not leave your network, the local runner (GA) in the Safeguard CLI (GA) scans on your own machine and uploads only the SBOM and findings, not source code. The docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

On a headless build machine, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS scores and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your code calls the vulnerable function. SAST (GA) covers your own code, DAST (GA) tests web targets you have verified, such as the web sign-up flow behind the app, and license compliance (GA) flags obligations in open source you ship inside the app.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the clock in the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions such as severity, CVSS, EPSS, license, component age and maintenance in the visual builder or YAML, and choose an action.

The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

For the report-only weeks in days 31 to 60, drop --fail-on critical. The API key is created under Settings › Developer with the scans:trigger and scans:read scopes. Keep this job separate from the one that signs and uploads your app.

4. Run exceptions through a recorded approval

Approval runs through exceptions, not through a gate action. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; an approver decides, and the audit trail records it.

For findings you will not fix yet, such as a vulnerable component inside a vendor SDK that has no fixed release, the Mitigations tab records the mitigation type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), the justification, the approver, an optional expiry for risk acceptances, and supporting evidence.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, for one repository or in bulk. It ships switched off, with every category set to Manual, so nothing changes in your repositories until your team turns it on. A merged pull request still has to go through your build, signing, store review and rollout.

6. Bring SDK vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the vendor risk owner and the growth team's SDK intake can live. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low). CSV bulk import moves a register that started in a spreadsheet. Contract records hold dates, SLA terms, security requirements and SBOM obligations.
2. Request SBOM, or Bulk Request for many vendors at once, sends a request specifying SPDX or CycloneDX format, required fields and a deadline, with reminders as the deadline approaches.
3. An arriving SBOM is validated for format and completeness and scanned for vulnerabilities; Request Revision sends back one that falls short.
4. Monitoring alerts on new critical vulnerabilities and CISA KEV additions that affect a vendor's SBOM, and reassessment can be triggered by contract renewals and security incidents. Reports export as PDF or Excel.

For a consumer app company, the Critical tier usually holds SDKs that ship as binaries, SDKs that receive personal, location, health or children's data, payment and identity SDKs, and the vendors whose tools sit in the build pipeline.

7. Keep the evidence in one place

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, you open a framework under Compliance › Frameworks, and its Connectors tab shows which connected systems feed its tests. The docs say a passing test is evidence toward a control, not proof that it is met. For COPPA 312.8 and store requirements, map the SBOMs, SDK records and exception logs to your own control list; do not assume a ready-made framework exists.

Portal audit trails (GA) log SBOM activity, access and administrative changes. Per the docs, you view them under Settings › Audit Logs and export as CSV, JSON or PDF for the evidence binder.

8. Approve from your phone during a release

The Safeguard mobile app (GA) for iOS and Android lets an engineer send work to a computer running the CLI and approve commands from the phone, which keeps a human approval in the loop on a hotfix night.

What Safeguard does not do

• It does not ship your app. A merged fix still needs your build, signing, App Store and Google Play review, staged rollout and user updates. Safeguard does not submit builds or force updates.
• It does not see what is not declared. This guide describes inventory built from repositories, manifests and lockfiles. Binary SDKs, engines and statically linked native libraries that do not appear in a manifest or lockfile will not show up unless you record them or the vendor supplies an SBOM. Ask Safeguard what it covers for compiled app binaries before you plan around it.
• It does not confirm every mobile package manager here. Safeguard's offering names Maven and Gradle and npm among SCA ecosystems. It does not name CocoaPods, Swift Package Manager or pub in the files we used for this guide, so confirm coverage for your iOS and Flutter projects before relying on it.
• It does not observe what SDKs do on a user's device. What an SDK sends to its vendor needs mobile testing, traffic analysis and the vendor's disclosures.
• It does not fill in store disclosures. Apple privacy labels, privacy manifests and the Google Play Data safety form remain your team's work, based on your SDK register.
• It does not hold your signing keys or store credentials. Key custody, rotation and access to App Store Connect and the Play Console stay with your platform team.
• It does not decide legal outcomes. COPPA, FTC, state privacy and SEC questions belong to counsel and executives. A passing test in Safeguard is evidence toward a control, as the docs say, not a finding of compliance.

Common mistakes

• Scanning the main branch only. The risk is in the versions users have installed. Keep SBOMs for every release still allowed to connect.
• Treating SDKs as marketing tools. An SDK runs with your app's identity and permissions. If it is not in an engineering review, it is not under control.
• Letting versions float. Version ranges in Podfiles, Gradle files and package.json mean two builds of the same commit can contain different code.
• Ignoring the build pipeline. CI actions and build plugins run with access to the keys that sign your app. Pin them and limit what they can read.
• Blocking everything on day one. A gate that fails every build gets disabled. Start in report-only mode and enforce on a narrow set.
• Forgetting the forced update path. If you cannot make users update, a fix you shipped protects only those who chose to install it.

FAQ

Are app developers responsible for third-party SDKs?

Both major stores say yes. Apple's third-party SDK requirements page says you are responsible for all the code an SDK includes in your app. Google Play's Data safety guidance says it is your responsibility to ensure third-party code in your app complies with Play policies.

What is an Apple privacy manifest and when is it required?

A privacy manifest is a file that describes the privacy practices of an app or SDK in a standard format. Apple requires the manifest for SDKs on its list of commonly used SDKs when you submit a new app that includes them or an update that adds one, and signatures where those SDKs are binary dependencies.

Does the amended COPPA Rule require an SBOM?

No. Section 312.8 requires a written information security program and written assurances from third parties that receive children's personal information. An SBOM and an SDK register are practical ways to show which third parties receive that data, but the rule does not name them.

How do I generate an SBOM for an iOS or Android app?

Generate it from the lockfiles at release time (Podfile.lock or Package.resolved, Gradle lockfiles, and the npm or pub lockfile) and store it with the release. Binary SDKs need a vendor SBOM or a manual entry.

How should a mobile team respond to an npm package compromise?

Follow the steps CISA published in September 2025: review dependencies, check lockfiles including nested dependencies for affected versions, search caches and artifact repositories, pin to known safe versions, rotate developer and CI credentials, and enforce phishing-resistant multifactor authentication. Then check which shipped app versions included the package.

What is the Google Play target API deadline for 2026?

From 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension available on request to 1 November 2026. Existing apps must target Android 15 (API level 35) or higher to stay available to new users on newer devices.

Can Safeguard scan app code without sending it to the cloud?

Yes. The Safeguard CLI's local runner, which is GA, scans on your own machine and uploads only the SBOM and findings, not source code. Safeguard also offers on-premises and air-gapped deployment and a Zero AI mode with no large language model in the loop, all GA.

In every incident above, the work after the inventory was the same: move each app and pipeline to a safe version, or work around a component that has no safe version yet. The section below describes how Safeguard helps with both, for the open source packages and container images you build, which in a mobile company means the app's package dependencies and the backend behind it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Android session with the Safeguard mobile app: send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It suits a mobile release engineer handling a hotfix away from a desk, when a fix has to move before the store review queue fills up.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: ask "fix the lodash CVE in this repo", and the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. A React Native team would run the same flow on its own JavaScript dependencies after an npm advisory.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the route for an app company whose policy does not allow a cloud service to clone unreleased app code.

Click through it at your own pace, or open it full screen.

Related reading: third-party SDK and ad library risk in iOS apps, third-party library risk in Android apps, SBOMs for iOS and Android apps, securing CocoaPods and Gradle dependencies and mobile app security testing with OWASP MASVS.

Quick check

Sources

• Apple Developer: Third-party SDK requirements
• Apple Developer: App Review Guidelines
• Google Play Console Help: Provide information for Google Play's Data safety section
• Google Play Console Help: Device and Network Abuse policy
• Google Play Console Help: Target API level requirements for Google Play apps
• FTC: FTC order prohibits data broker X-Mode Social and Outlogic from selling sensitive location data (9 January 2024)
• FTC: FTC order will ban InMarket from selling precise consumer location data (18 January 2024)
• FTC: FTC finalizes order with InMarket (May 2024)
• FTC: FTC finalizes changes to the Health Breach Notification Rule (26 April 2024)
• eCFR: 16 CFR 312.8, Confidentiality, security, and integrity of personal information collected from children
• Federal Register (govinfo): FTC final rule, Children's Online Privacy Protection Rule (22 April 2025)
• California Privacy Protection Agency: CCPA updates, cybersecurity audits, risk assessments and ADMT regulations
• Federal Register (govinfo): SEC final rule, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (4 August 2023)
• NIST SP 800-218: Secure Software Development Framework version 1.1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• European Commission: Cyber Resilience Act
• CVE record: CVE-2024-38368
• CVE record: CVE-2024-38366
• CVE record: CVE-2024-38367
• CocoaPods blog: CocoaPods trunk read-only plan
• OWASP MAS: MASVS-CODE-3
• CISA: Supply chain compromise of third-party tj-actions/changed-files and reviewdog/action-setup (18 March 2025)
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: Generate SBOM
• Safeguard docs: Continuous Scanning
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Local Runner
• Safeguard docs: GitHub Actions
• Safeguard docs: Portal Audit Trails
• Safeguard docs: PCI DSS framework and connectors

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.