MAST is essential for open source mobile app security

At a glance

What this is: This is Guardsquare’s case for why mobile application security testing must sit alongside software composition analysis when open source components and transitive dependencies shape most modern app code.

Why it matters: It matters to IAM and security practitioners because hardcoded secrets, exposed tokens, and third-party package compromise create identity and access risk inside mobile delivery pipelines, not just code quality issues.

By the numbers:

• In 2022, between 70% and 90% of a typical software codebase was estimated to be made up of open source components.
• Packages cumulating over 2 billion weekly downloads and more than 190 mobile apps were affected in the September 2025 npm supply chain attack.
• Only 44% of developers are reported to follow security best practices for secrets management.

👉 Read Guardsquare's analysis of MAST, open source dependencies, and mobile app risk

Context

Mobile app security has become a supply chain governance problem as much as a code testing problem. When most of an app comes from third-party libraries, the security boundary shifts from the developer’s own code to the provenance, maintenance, and runtime behaviour of upstream components. That creates direct exposure for secrets, tokens, certificates, and embedded credentials.

For identity and access programmes, this is the same control problem seen in other non-human identity estates: unmanaged secrets, stale privileges, and weak offboarding logic. MAST, SCA, SBOMs, and runtime protections each cover a different layer, but none of them alone resolves the lifecycle risk that open source introduces into mobile delivery.

The article’s starting position is typical for modern app teams: broad adoption of FOSS, limited visibility into dependency depth, and underpowered remediation discipline once a package is compromised or disclosed as vulnerable.

Key questions

Q: How should teams reduce supply chain risk in mobile apps with many open source dependencies?

A: Teams should combine SBOM-based inventory, SCA, SAST, and MAST so they can see what is in the app, what is known to be vulnerable, what is insecure in code, and what changes at runtime. The control gap is usually not one missing tool but fragmented visibility across all four layers.

Q: Why do transitive dependencies create more mobile app risk than direct libraries alone?

A: Transitive dependencies hide risk several layers deep inside packages the team did not choose directly, which makes review and patching slower. When one upstream package is compromised, many downstream apps can inherit malicious code or vulnerable behaviour before defenders see the chain clearly.

Q: What are the signs that mobile secrets management is failing in production apps?

A: Look for hardcoded API keys, tokens, or cloud credentials in source and bundled binaries, repeated dependency updates that leave old packages in place, and runtime calls to unexpected endpoints. Those signals usually show that secrets and third-party components are being shipped without lifecycle control.

Q: How can security teams tell whether MAST is enough on its own?

A: MAST is not enough when the main risk comes from vulnerable packages, embedded secrets, or compromised dependencies that only show their effect after deployment. If teams cannot answer where components came from, when they were last patched, and how they are revoked, MAST is only one layer of control.

Technical breakdown

How transitive dependencies expand the mobile attack surface

A transitive dependency is a library your app uses indirectly through another package. That matters because the code you ship may inherit risk from components you did not select, review, or update yourself. In a supply chain event, attackers can compromise a widely used package once and reach many downstream apps at runtime. The result is a detection problem, not just a code quality problem, because the malicious logic executes inside the trusted app context and can bypass assumptions built around direct dependency review.

Practical implication: inventory indirect dependencies and require SBOM coverage deep enough to expose nested package relationships.

Why MAST, SCA, and SAST answer different questions

Software Composition Analysis identifies known vulnerable components, while Static Application Security Testing looks for insecure code patterns, including hardcoded credentials and weak crypto, without running the app. Mobile Application Security Testing adds execution-time inspection of behaviour such as insecure storage, TLS misuse, and unexpected network destinations. The three controls are complementary because one finds known bad packages, one finds flawed code, and one finds runtime weakness. Treating them as interchangeable leaves gaps in either provenance, implementation, or execution.

Practical implication: place SCA, SAST, and MAST at different points in the delivery pipeline instead of choosing one control for all risks.

How runtime controls reduce the impact of compromised packages

Runtime Application Self-Protection and code hardening do not prevent a malicious library from being introduced, but they can make exploitation harder once code is running. That matters when a legitimate package is compromised or a known vulnerability is triggered after release. Runtime inspection can also reveal unexpected calls to external endpoints or suspicious data access patterns that static review will miss. In mobile environments, post-deployment protection is therefore a compensating control for upstream trust failure.

Practical implication: add runtime tamper and anomaly controls where app store review and pre-release scanning cannot fully constrain execution.

Threat narrative

Attacker objective: The attacker wants to ride trusted mobile dependencies into execution, then steal credentials, redirect value, or persist malicious behaviour inside downstream apps.

1. Entry occurs when attackers compromise a trusted open source package or exploit a known vulnerability in a dependency that mobile teams have not yet patched.
2. Escalation follows when the malicious or vulnerable code executes inside the app and accesses storage, network sessions, or embedded secrets in the user context.
3. Impact is credential harvesting, transaction manipulation, malware installation, and, in some cases, app removal from distribution stores with associated revenue loss.

NHI Mgmt Group analysis

Open source dependency sprawl now functions like non-human identity sprawl. When mobile apps inherit hundreds of direct and indirect libraries, each package can carry embedded secrets, external service access, or update trust that is never revalidated. That mirrors the NHI problem: control failure is rarely about one secret, but about the estate of dependencies around it. Practitioners should treat dependency inventories as governance objects, not just build artefacts.

MAST becomes a lifecycle control when package trust is dynamic. The article is strongest when it links pre-release testing to ongoing validation, because mobile risk changes after the first scan. A package can be safe today and compromised tomorrow, which means release-time attestation is necessary but insufficient. Practitioners should connect MAST to update cadence, revocation logic, and release gating, not treat it as a one-time quality check.

Secret exposure inside mobile code is an identity problem before it is an application problem. Hardcoded API keys, tokens, and cloud credentials are non-human identities embedded where they are easiest to steal and hardest to govern. That is exactly the kind of drift OWASP NHI guidance is designed to surface: credentials without lifecycle, ownership, or revocation discipline. Practitioners should align appsec scanning with NHI governance rather than leaving secrets management to developers alone.

Compliance pressure is pushing mobile security toward evidence-based controls. Regulatory references such as the EU Cyber Resilience Act and sector-specific scanning expectations are forcing teams to prove that vulnerabilities are identified before release, not after incident response. That trend rewards organisations that can show inventory, scanning, and remediation discipline across dependencies. Practitioners should prepare for audit questions about how third-party libraries are approved, scanned, and retired.

Runtime protection is becoming the backstop for upstream trust failure. Once an app includes a compromised dependency, the issue is no longer whether the package should have been trusted, but how much damage it can do at execution time. That makes RASP, tamper detection, and network anomaly visibility part of the modern mobile control stack. Practitioners should view runtime defence as a containment layer, not a substitute for dependency governance.

What this signals

Secrets embedded in mobile code now need the same governance discipline as other non-human identities. If a build pipeline can ship API keys, tokens, or cloud credentials inside packages, the programme has a credential lifecycle problem, not just an appsec problem. Teams should align mobile scanning with NHI Lifecycle Management Guide practices and use OWASP Non-Human Identity Top 10 to pressure-test lifecycle and overprivilege assumptions.

Dependency visibility will increasingly drive auditability in regulated mobile environments. The most useful question is no longer whether a library is open source, but whether the organisation can prove provenance, patch status, and removal of obsolete components. That maps cleanly to NIST Cybersecurity Framework 2.0 and to the control expectations behind mobile release governance.

Open source compromise also raises a broader programme signal: runtime defence must become part of release assurance, not an emergency patch after the fact. Where app stores, customers, or regulators expect pre-release evidence, teams need to show layered control coverage from inventory through execution, not one control that only sees part of the risk.

For practitioners

• Build dependency inventories from SBOM data Track direct and transitive dependencies for every mobile release so security teams can see where risk enters the codebase and which packages remain unreviewed. Tie the inventory to release approval and incident response workflows, not just documentation.
• Separate SCA, SAST, and MAST gates Use SCA to detect known vulnerable components, SAST to catch hardcoded secrets and weak patterns, and MAST to test runtime behaviour such as insecure storage or unexpected endpoints. Each gate should produce different remediation queues.
• Remove embedded secrets before release Search mobile code and bundled libraries for API keys, tokens, and cloud credentials, then replace them with short-lived, centrally governed credentials. Treat any embedded secret as an NHI lifecycle failure because revocation and rotation become opaque once it is shipped.
• Add runtime containment for compromised packages Deploy tamper resistance, anomaly detection, and network inspection to reduce the blast radius when a trusted dependency is later compromised. This is especially important for apps distributed through public stores where patching is slower than exploitation.

Key takeaways

• Open source makes modern mobile apps faster to build, but it also expands the attack surface through hidden dependencies, embedded secrets, and compromised packages.
• The scale is material. Guardsquare cites a 70% to 90% open source share in many codebases, and the broader NHI evidence shows that secrets leaks remain common and damaging.
• Teams need layered control, not a single scanner. SBOMs, SCA, MAST, SAST, and runtime protection each close a different part of the mobile trust problem.

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 Guide (MASTG): MASTG is OWASP’s testing guide for mobile applications. It explains how to test for common weaknesses and what evidence to gather, making it useful for security testing teams, developers, and assessors who need repeatable methods rather than informal review notes.
• 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.

What's in the full article

Guardsquare's full article covers the operational detail this post intentionally leaves for the source:

• How AppSweep fits into CI/CD scanning for mobile release pipelines and periodic validation
• The step-by-step breakdown of MAST findings such as insecure storage, weak encryption, and TLS/SSL issues
• OWASP MASTG and MASWE references for third-party libraries and dependency vulnerabilities
• Regulatory and industry compliance context for mobile testing before release

👉 The full Guardsquare article covers the npm attack chain, dependency testing methods, and mitigation strategies.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect application risk to the broader identity and access problems their programmes must govern.