Open Source Software is everywhere. Is your mobile app secure? 

Open source software has changed the way developers build mobile applications. Instead of creating everything from scratch, development teams can use existing libraries, frameworks and third-party components to build applications faster. This gives teams access to proven technologies and can reduce development time. 

But there is a trade-off. The more components an application depends on, the more difficult it can become to understand and manage its security. An application may contain code that the development team did not write and may not fully control. This is where visibility and mobile application security become important. 

What is inside your application?

Modern mobile applications rarely consist entirely of code written by a single development team. An application may use multiple open source libraries, third-party SDKs and other components. These components can also depend on additional libraries, creating what are known as transitive dependencies. Open source itself is not the problem. It is an essential part of modern software development. 

The challenge is knowing what is actually inside your application. 

• Which open source and third-party components are being used? 

• Are any dependencies outdated? 

• Do any components have known vulnerabilities? 

• What happens if a third-party component is compromised? 

• Can your team quickly identify and respond to the issue? 

Without proper visibility into both application code and its dependencies, these questions can be difficult to answer.  

Understanding the Security Risks 

The three categories are good: 

• Vulnerable components 

• Outdated dependencies 

• Software supply chain attacks 

Vulnerable components

A library may contain a known security vulnerability that attackers could exploit. Even when a security update is available, an application can remain exposed if it continues to use the vulnerable version. 

Outdated dependencies

Applications may continue to use older versions of open source libraries or third party components that contain known security vulnerabilities. Identifying these vulnerabilities can help development teams investigate whether an update or other remediation is required. 

Software supply chain attacks

Attackers can also target the software supply chain. A legitimate third-party component can potentially be compromised and used to introduce malicious code into applications that depend on it. 

The security challenge is simple: 

You need to understand what is inside your application before you can protect it. 

Understanding Open Source Vulnerabilities Through SAST

Software Composition Analysis (SCA) is commonly used to analyse open source and third party components within an application. It can help teams understand their dependencies and identify known vulnerabilities associated with those components. However, SCA does not need to be treated as a separate step from application security testing. When analysing application, SAST can also identify vulnerabilities introduced through open source libraries and other third-party components.  

This means developers can look beyond vulnerabilities in their own code and also understand security issues associated with the components their application depends on. Dependency related vulnerabilities are only one part of application security. A mobile application can have weaknesses within its own code, configuration, communication and runtime behaviour. This is where Mobile Application Security Testing (MAST) provides a broader approach to assessing mobile application security.  

Where does MAST Fit?

MAST is not a single security technique. It brings together different approaches to assess the security of a mobile application. 

Security testing can help identify weaknesses such as: 

• Insecure coding practices 

• Sensitive data exposure 

• Weak encryption 

• Hardcoded secrets 

• Insecure communication 

• Authentication weaknesses 

• Runtime vulnerabilities 

The earlier a security issue is identified, the easier it can generally be to investigate and address. 

Two important approaches within application security testing are Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). 

SAST: Find Issues Earlier

SAST analyses application code and other application artefacts without requiring the application to be running. It can identify security weaknesses and insecure patterns during development, helping teams investigate issues before an application reaches productions.  

SAST can also help identify vulnerabilities introduced through open source libraries and third party components used by an application. This gives development teams visibility into security issues that may not come directly from code written by their own developers. Think of SAST as looking inside the application to identify potential security problems before release. 

DAST: Test the Application in Action

DAST takes a different approach. Instead of analysing only the application code, DAST tests the application while it is running. It can identify weaknesses that may only become visible during runtime, including issues related to application behaviour, communication, authentication and data handling. Think of DAST as testing the application from the outside, similar to how an attacker may interact with it. 

Why Use Both?

SAST and DAST provide different perspectives. 

SAST: What potential security weaknesses can be identified within the application?

DAST: How does the application behave when it is running?

Using different testing approaches can give development and security teams a broader view of their application’s security posture. But finding vulnerabilities is not the end of the security process. 

A Security Scan Is Not the Finish Line

Mobile applications operate in environments developers do not control. Once an application is deployed, attackers can use techniques such as reverse engineering, debugging, tampering, repackaging and runtime manipulation to target it. This means mobile application security needs to go beyond pre-release testing. A more complete approach looks like this: 

Find vulnerabilities → Fix vulnerabilities → Protect the application → Monitor what happens after deployment. 

This is where technologies such as Runtime Application Self-Protection (RASP) can complement security testing. RASP can help an application detect certain threats while it is running and respond according to configured security controls. 

From Scan to Shield to Supervise 

Quixxi takes a layered approach to mobile application security, helping teams address security across different stages of the application lifecycle. 

Scan: Find vulnerabilities

Quixxi Scan provides SAST and DAST capabilities for Android and iOS applications, helping development teams identify potential security vulnerabilities and understand the issues that need attention. 

Through SAST, Quixxi can also identify vulnerabilities introduced through open source libraries and third party components used within an application. This helps teams understand not only the risks within their own application code, but also security issues associated with the components their application relies on. Scanning provides visibility into potential weaknesses before and during deployment. But identifying a vulnerability is only one part of the process.  

Shield: Protect the application

Quixxi Shield adds protection at runtime through capabilities including RASP, code obfuscation, anti-tampering and reverse engineering protection. It is designed to help protect mobile applications when they are running on devices and in environments outside the developer’s direct control. 

Supervise: Monitor after deployment

Security does not stop when an application is released. 

Quixxi Supervise provides ongoing visibility into deployed applications, helping teams monitor application security and identify potential threats beyond the development environment. Together, these capabilities support a layered approach to mobile  

Open Source Is Not the Problem. Lack of Visibility Is

Open Source software is here to stay. It helps development teams build faster, access existing technologies and reduce the effort required to create modern applications. The goal is not to stop using open source, but to understand what your application depends on and identify the security risks those components may introduce.  

SAST can help identify vulnerabilities in application code as well as vulnerabilities introduced through open source libraries and third party components. DAST provides another perspective by testing the application while it is running. For mobile applications, security also needs to extend beyond testing. Runtime protection can help defend the application when it is operating environments outside the developer’s direct control, while ongoing monitoring can provide visibility after deployment.  

Because mobile application security is not just about finding vulnerabilities. It is about understanding what is inside your application, identifying potential weaknesses, protecting the application in the real world and continuing to monitor it after release.