The Importance of MAST in the Age of Open Source Software

Building with free and open source software (FOSS) has become common practice for app developers. In 2022, it was estimated that between 70% and 90% of any given software codebase was made up of open source components. Leveraging open source projects presents many advantages:

• Speed: integrating FOSS components reduces development cycles (and costs) by eliminating the need to reinvent common functionalities.
• Quality: compared with in-house code, established open source libraries benefit from extensive scrutiny.
• Flexibility: thanks to direct access to source code, developers can customize FOSS packages while avoiding vendor lock-in.

But using open source software also comes with inherent risks. Take for example the September 2025 npm supply chain attack. Through social engineering, attackers were able to target popular free and open source packages such as chalk and debug, injecting malicious code into them. Developers unknowingly pulled these infected packages into their apps, which led to malware being installed on user devices. Ultimately, packages cumulating over 2 billion weekly downloads and more than 190 mobile apps were affected, leading to credentials harvesting and theft of cryptocurrency.

This is why, in the age of free and open source software, mobile application security testing (MAST) is imperative for securing your mobile app, and especially in identifying the use of deprecated or vulnerable third-party libraries in your app. Without in-depth testing of every component of your codebase, you may be inadvertently incorporating vulnerabilities into your mobile app, putting your users, your IP and your revenue at risk.

How FOSS increases the attack surface

While integrating open source software into your mobile app may sound attractive, it also expands the attack surface. Not only can the packages you install contain vulnerabilities or malicious payloads, but they themselves often rely on other libraries which can also be vulnerable. These are called “transitive dependencies”, and can go several levels deep. In the case of the npm attack, many of the affected applications had compromised packages as transitive dependencies, not direct dependencies, which can make malicious payloads harder to detect.

Compromised legitimate package

The most common way 3rd-party libraries can affect your mobile app is if they get compromised. This is what happened with the npm supply chain attack. Attackers gain access to legitimate packages and inject malicious code that will execute inside the mobile app on the user device. For the end user, this can have serious consequences: a crypto-stealing payload might intercept transactions and redirect them toward the attacker’s wallet, or scan the device’s storage locations for saved credentials.

Beyond the impact on the end user, a compromised package can also directly impact the app developer. A malicious payload can for example scan your mobile app for any hardcoded secrets such as API keys, tokens or cloud credentials. In addition, if the Apple App Store or Google Play Store detect suspicious behavior inside your app, they can remove it, leading to substantial revenue loss.

Exploitation of known vulnerabilities

Another common way FOSS libraries can affect mobile apps is through unpatched CVEs. Contrary to compromised packages, this attack vector originates in an unintentional security flaw, not a direct malware insertion. Here is how this vulnerability generally plays out:

• The library author releases a version of their FOSS library with an undiscovered vulnerability.
• The vulnerability is discovered by researchers and disclosed, and the maintainer releases a patch.
• However, a mobile app developer still uses the vulnerable version because they didn’t update to the patched version.
• Attackers publish exploit code targeting the vulnerability, and compromise the app by sending malicious input that triggers the vulnerability.

OWASP calls out this threat explicitly in their Mobile Application Security Testing Guide (MASTG), under the knowledge reference MAST-KNOW-0004: Third-Party Libraries, as well as under their Mobile Application Security Weakness Enumeration (MASWE) under the reference MASWE-0044: Dependencies with Known Vulnerabilities. While the maintainer bears the primary blame for the vulnerability, the developer who incorporates the library is also responsible if they do not update timely to the patched version. This is reiterated in Google and Apple’s guidelines, which state that app developers are responsible for their code, including 3rd-party dependencies.

Software Composition Analysis (SCA)

With such widespread use of free and open source software, it has become more important than ever for developers to understand how their code is structured. Software Composition Analysis (SCA) is the process of scanning your mobile app, inventorying all open-source libraries and third-party components, and identifying any known vulnerable components against a database of well-known published vulnerabilities. This is exactly what OWASP’s Dependency-Check tool aims to achieve:

• Dependency-Check attempts to identify each dependency thanks to its Common Platform Enumeration (CPE).
• It then produces a list of associated Common Vulnerability and Exposure (CVE) entries for that CPE.

This helps developers ensure that the code they push to production does not include third party libraries with known vulnerabilities.

The importance of Mobile Application Security Testing (MAST)

In addition to Software Composition Analysis, Mobile Application Security Testing (MAST) is a vital component of secure software development. MAST is the practice of identifying security issues in a mobile app that could be exploited by attackers. This process is generally automated with a dedicated scanning tool such as AppSweep which integrates directly into the CI/CD pipeline. Scans run periodically and uncover a broad range of issues including insecure data storage, weak encryption, improper TLS/SSL implementation, and more.

Static Application Security Testing (SAST)

Static Application Security Testing (SAST) scans your mobile app code without executing it. This approach allows developers to identify security flaws early in the development lifecycle, shifting security left before code reaches production. SAST tools parse the code to detect insecure coding patterns, hardcoded credentials, and weak cryptographic implementations. Static analysis will also uncover findings contained in third-party libraries. By catching these issues during the coding phase, teams reduce the cost and complexity of remediation.

Interactive Application Security Testing (IAST)

Interactive Application Security Testing scans the mobile app while it is running, simulating real-world attack scenarios. Unlike static analysis, IAST focuses on the application’s behavior during execution. By examining the mobile app while it is running, developers can identify security issues such as insecure data transmission, improper session management, and server-side logic errors that only manifest when the app interacts with backend APIs. It can also be a useful mechanism for analyzing communication traffic to ensure the application and its dependencies are not connecting to any unexpected API endpoints.

For mobile applications, dynamic testing is critical for verifying TLS/SSL configurations and detecting data leakage through network traffic. By testing security controls while the app runs, organizations ensure their application can resist attacks before release.

MAST as a compliance requirement

It is also worth noting that several regional and industry-specific regulations mandate mobile app developers to test their mobile apps in-depth before release.

For example, the EU Cyber Resilience Act (CRA), which comes into full effect in December 2027, explicitly requires app developers to “carry out the chosen conformity assessment procedures”, i.e. security testing and vulnerability assessment, and that this should be done “before placing a product with digital elements on the market”, i.e. pre-release. Similarly, the FDA requires extensive testing documentation for any medical device apps, mandating a “systematic vulnerability scanning of all software components and third-party libraries”.

For highly regulated industries like financial services, AppSweep supports adherence to security audits and trade association standards such as those issued by the PCI Security Standards Council. By identifying vulnerabilities early in the development lifecycle, AppSweep contributes to audit readiness and ongoing security validation before app release.

Mitigations strategies

For all the advantages that free and open-source software presents for developers, it is undeniable that it also increases the attack surface. To mitigate for these, OWASP lays out several strategies:

• Use a software bill of materials (SBOM). An SBOM is an inventory tracking all components and transitive dependencies, ensuring you always keep visibility and accountability on any 3rd-party libraries.
• Update dependencies responsibly. Regularly monitor all 3rd-party dependencies for security-related updates, and apply updates when a known vulnerability has been disclosed and patched. For this, a Software Composition Analysis (SCA) tool, such as OWASP’s free Dependency-Check tool for Android, is useful.
• Remove unused or obsolete dependencies. Maintain proper software hygiene by removing unused or legacy libraries to reduce your dependency footprint and the associated attack surface.
• Use trusted sources. Always download libraries and SDKs from reputable sources and ensure that open-source projects that your mobile app relies on remain active and well-maintained to minimize the risk of introducing malicious or vulnerable code.

It’s also worth noting that, while MAST identifies weaknesses in your codebase, proactive measures to harden and protect your mobile app at runtime should also be taken. Multilayered code hardening makes your mobile app binary harder to reverse engineer, and RASP (Runtime Application Self-Protection) protects it from active tampering while the app is running, defending it even if an underlying FOSS component is compromised.

Time to step up your Mobile Application Security Testing

Mobile Application Security Testing is essential for securing open-source components. Far from delaying launches, automated MAST accelerates delivery by resolving vulnerabilities early. AppSweep integrates seamlessly into your CI/CD pipeline, ensuring continuous validation and audit readiness without sacrificing speed.

Reach out to learn more and discover how Guardsquare provides industry-leading testing for mobile apps.