TL;DR: Open source now makes up 70% to 90% of many codebases, but the same dependency model expands mobile attack surface through compromised packages, transitive dependencies, and unpatched vulnerabilities, according to Guardsquare. Mobile app teams need MAST, SCA, SBOM discipline, and runtime protections because visibility without lifecycle control still leaves exploitable gaps.
At a glance
What this is: Guardsquare argues that open source software expands mobile app attack surface through compromised packages, transitive dependencies, and delayed patching, making MAST a core control rather than an optional scan.
Why it matters: IAM and application security teams need visibility into third-party code because hidden libraries, hardcoded secrets, and runtime abuse can turn an ordinary mobile dependency chain into a supply chain exposure.
Context
Open source software reduces development friction, but it also broadens the trust boundary around mobile code. Once third-party libraries, transitive dependencies, and update lag enter the build, security no longer depends only on first-party code quality. In mobile environments, that creates a governance problem as much as a technical one, because compromised dependencies can reach production before teams notice.
The article’s core identity-security intersection is not human IAM but the control of secrets, dependencies, and runtime trust inside mobile applications. That matters to practitioners because mobile apps often hold API keys, tokens, certificates, and backend connectivity patterns that can be abused once a dependency is compromised or a vulnerable library remains in place.
Key questions
Q: What breaks when a mobile app relies on transitive open source dependencies without full inventory?
A: Security review breaks because teams can miss the actual library that introduces risk. A top-level package may look clean while nested components carry the vulnerable code, malicious payload, or outdated crypto logic that reaches production. The result is false confidence, because the app appears reviewed even though part of its attack surface was never examined.
Q: Why do compromised mobile libraries create both supply chain and secret exposure risk?
A: A compromised library runs in the app’s trusted runtime context, so it can execute code, inspect local storage, and look for embedded secrets. That makes the same event both a supply chain problem and an identity problem, because API keys, tokens, and cloud credentials can be harvested from the client before back-end controls can respond.
Q: What do security teams get wrong about MAST and open source risk?
A: They often treat MAST as a point-in-time scan instead of part of a dependency lifecycle. MAST can detect weaknesses in the app, but it does not replace SBOM coverage, SCA validation, or dependency update governance. Without those controls, teams may keep shipping known-vulnerable libraries even after disclosure and patch release.
Q: How should teams respond when a mobile app ships with a vulnerable third-party library?
A: They should remove or patch the library, verify whether the vulnerable version is present in direct or transitive form, and confirm whether any secrets or customer data were exposed through runtime execution. If the app is already released, containment should focus on revocation, release control, and runtime hardening before the next build ships.
Technical breakdown
How transitive dependencies expand mobile attack surface
Transitive dependencies are libraries pulled in indirectly by other packages, often several layers deep. They matter because a team may review the top-level dependency list and still miss the actual component that introduces risk. In mobile software, this means a package that looks legitimate can still bring in vulnerable code, malicious payloads, or outdated cryptographic logic through nested relationships. MAST and SCA complement each other here: one finds security issues in the app’s behaviour, while the other inventories what the app is built from.
Practical implication: Map nested dependencies explicitly so hidden components are not left outside review scope.
Why compromised packages can expose secrets and user data
A compromised package executes in the app’s runtime context, which gives it the same practical visibility as legitimate code. That makes it possible to inspect local storage, intercept sensitive flows, and look for hardcoded secrets such as API keys, tokens, or cloud credentials. In mobile environments, that risk is amplified because malicious code can act on the user device before backend controls have any chance to intervene. Runtime inspection and hardening are therefore part of dependency risk management, not separate concerns.
Practical implication: Assume any imported library can access local secrets unless runtime protections constrain what it can read or transmit.
Why unpatched vulnerabilities still reach production
A vulnerable library often becomes dangerous only after an exploit exists, but the window between disclosure and developer update is enough for attackers to weaponise it. The failure is not only in the library author’s code. It also sits in the consuming application’s release process when teams do not validate whether the patched version is actually in use. MAST, SCA, and SBOM discipline work together to shorten that window by showing what is present, what is outdated, and what still needs remediation.
Practical implication: Treat dependency update lag as an exposure window and verify vulnerable versions are removed before release.
Threat narrative
Attacker objective: The objective is to monetise trusted mobile software by turning legitimate dependency execution into secret theft, wallet theft, and device compromise.
- Entry begins when attackers compromise a popular open source package and insert malicious code into the dependency stream.
- Credential access follows when the infected package runs inside mobile apps and searches for stored credentials, tokens, or cloud secrets on the device.
- Impact occurs when infected apps are distributed at scale, leading to malware installation, credential harvesting, and cryptocurrency theft.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Open source mobile app risk is now a software supply chain governance problem, not just an AppSec testing problem. When transitive dependencies can introduce malicious code or unpatched flaws, teams are no longer judging only the quality of their own source. They are governing the trustworthiness of an inherited software graph, which means inventory, provenance, and release discipline become security controls. Practitioners should treat dependency trust as part of application governance.
Mobile apps create a secret exposure layer that many build pipelines still under-manage. The article’s examples of API keys, tokens, cloud credentials, and stored user credentials show why mobile runtime compromise often becomes identity compromise by another route. Once secrets are embedded in client code or recoverable at runtime, credential theft can happen without any back-end login event. Practitioners should align MAST with secrets governance and runtime containment.
MAST only becomes meaningful when it is paired with SBOM and SCA discipline. Testing can find flaws, but it cannot prove what was never inventoried or never updated. That is the governance gap this article exposes: visibility without authoritative dependency control still leaves mobile apps exposed to known-vulnerable libraries and compromised packages. Practitioners should use MAST as one layer in a lifecycle control model, not as a standalone gate.
Runtime protection matters because mobile supply chain attacks do not stop at release. The article’s emphasis on RASP and code hardening reflects a practical reality: a compromised dependency can execute on the device even after code review and pre-release testing are complete. That makes mobile runtime controls part of resilience, not just detection. Practitioners should assume build-time assurance is necessary but insufficient.
Open source adoption has shifted the burden of proof onto the consuming organisation. The article is clear that developers remain responsible for the libraries they ship, even when the maintainer originally introduced the flaw. That means third-party code cannot sit outside the app’s accountability model. Practitioners should re-evaluate ownership boundaries for dependency risk and release approval.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
What this signals
Dependency visibility is now a release-quality issue as much as a security issue. Mobile teams that can inventory libraries but cannot govern update timing still leave themselves exposed to known vulnerabilities and compromised packages. The practical shift is from asking whether a dependency is visible to asking whether its trust status is continuously enforceable.
Open source mobile risk now sits at the intersection of AppSec and identity governance. When a compromised package can harvest API keys or cloud credentials from the device, secret protection becomes a mobile control surface rather than a back-end-only concern. Practitioners should align dependency governance with secret handling, runtime containment, and release approval.
MAST should be treated as a control layer, not a compliance checkbox. The most useful programmes connect scanning, SBOM accuracy, and runtime hardening into one operating model, because each one closes a different part of the exposure window. That is the difference between finding problems and actually reducing mobile supply chain risk.
For practitioners
- Inventory transitive dependencies in every mobile release Build and maintain an SBOM that includes nested packages, not just direct libraries, so hidden dependencies are visible before release.
- Block known-vulnerable libraries before production Wire SCA into CI/CD so disclosed CVEs and unpatched versions fail builds until the affected dependency is updated or removed.
- Scan for hardcoded secrets in mobile code and libraries Use static analysis to find API keys, tokens, cloud credentials, and other embedded secrets that a malicious package could harvest.
- Apply runtime containment to mobile binaries Pair code hardening with RASP so tampering, reverse engineering, and suspicious network behaviour are constrained on the device.
Key takeaways
- Open source libraries expand mobile app reach and also expand the trust boundary, so dependency governance is now part of application security.
- Compromised packages and unpatched vulnerabilities can expose secrets, user data, and revenue through the mobile runtime itself.
- MAST is most effective when it is paired with SBOM inventory, SCA validation, and runtime protections that limit what a malicious dependency can do.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article highlights hardcoded secrets and credentials exposed by compromised mobile code. |
| NHI-07 — Long-Lived Secrets | The article stresses that persistent API keys and tokens remain exploitable when embedded in apps. | |
| Recommendation — Scan mobile apps for exposed secrets and revoke any credentials found in code or runtime logs. Replace long-lived mobile secrets with short-lived credentials and rotate anything embedded in client code. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen tokens and cloud credentials turn compromised app code into authentication abuse. |
| API9 — Improper Inventory Management | SCA and SBOM needs map directly to inventorying mobile dependencies and third-party components. | |
| Recommendation — Harden mobile API authentication so leaked tokens cannot be reused for privileged calls. Maintain a complete inventory of mobile dependencies and block releases when unknown components appear. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Mobile apps often store credentials and sensitive data locally, which the article flags as harvestable. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on controlling what third-party code can reach inside the app runtime. | |
| Recommendation — Encrypt sensitive data on mobile devices and minimise what remains recoverable at rest. Limit app and component access to only the permissions and data paths each dependency truly needs. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The cited supply chain attack used injected code to steal credentials and enable downstream theft. |
| Recommendation — Map mobile supply chain detections to credential access and exfiltration techniques to prioritise containment. | ||
| SLSA | L3 — Build Integrity | The article’s supply chain theme depends on protecting artefact integrity from source to release. |
| Recommendation — Adopt verifiable build provenance so malicious dependency changes are detected before mobile release. | ||
Key terms
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- Mobile Application Security Testing: Mobile Application Security Testing is the process of finding security weaknesses in smartphone and tablet apps before attackers do. It examines code, runtime behavior, data storage, network traffic, authentication, permissions, and device interactions to identify flaws such as insecure APIs, weak encryption, exposed secrets, and abuse paths across iOS and Android environments.
- Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect identity controls to broader application and supply chain security decisions.
Published by the NHIMG editorial team on September 2, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org