DEV Community

Shifting Mobile Security Left: Applying SAST to Android Apps with MobSF

The Challenge of Mobile SAST

Static Application Security Testing (SAST) is widely discussed in web development, but mobile ecosystems bring their own unique attack vectors. In Android, an attacker isn't just sending malicious payloads to a server; they can decompile the APK, inspect the manifest, and extract hardcoded secrets directly from the binary.

When architecting mobile vulnerability analyzers-like Anzencore, for example-the primary objective is to inspect the raw code and configuration files before the build process even begins. We need to identify when developers fail to meet critical non-functional requirements, such as secure data synchronization and encrypted local storage.

Why MobSF?

The OWASP Source Code Analysis Tools catalog is extensive, but many mainstream commercial tools are heavily web-focused. I chose MobSF because it is an open-source, specialized framework designed explicitly for mobile apps (Android/iOS/Windows). While it can perform dynamic analysis, its static analysis engine is incredibly powerful for parsing AndroidManifest.xml files, reverse-engineering Dalvik bytecode, and scanning Java/Kotlin source code for insecure implementations.

Step 1: Spinning up the Analyzer

Because we want to keep our host machine clean and avoid dependency hell, we will deploy MobSF using Docker. It takes just two commands in a Linux environment to get the local server running:

# Pull the latest MobSF image
docker pull opensecurity/mobile-security-framework-mobsf:latest

# Run the container on port 8000
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Once running, the web interface is accessible at localhost:8000, ready to ingest an APK or a ZIP of the source code.

The Victim: A Vulnerable Android App

For this test, I uploaded an open-source vulnerable Android application (similar to InsecureBankv2). Instead of executing the app, MobSF decompiles it and runs its SAST ruleset against the extracted source. Within 60 seconds, the dashboard populated with critical findings.

Here are the two most dangerous vulnerabilities caught by the static scan:

1. Hardcoded Secrets (CWE-798)

MobSF flagged the res/values/strings.xml file. A developer left a production AWS access key directly in the code:

<!-- Flagged by MobSF: Hardcoded sensitive information -->
<string name="aws_access_key">AKIAIOSFODNN7EXAMPLE</string>

Why it matters: Anyone who downloads the app from the Play Store can use a tool like Apktool to extract this string in seconds.

2. Insecure Data Storage (CWE-312)

The analyzer traced a data flow in the Kotlin backend where user session tokens were being saved using SharedPreferences without the EncryptedSharedPreferences wrapper.

// Flagged by MobSF: Insecure SharedPreferences implementation
val sharedPref = activity?.getPreferences(Context.MODE_PRIVATE)
with (sharedPref.edit()) {
    putString("session_token", userToken) // Tainted data sink
    apply()
}

Why it matters: If the device is rooted, MODE_PRIVATE does not protect the XML file from being read by other malicious applications on the device. Secure storage is a non-functional requirement that must be enforced at the architectural level.

The Next Evolution: Bringing SAST to the IDE

While running a Dockerized SAST tool is great for CI/CD pipelines, the feedback loop can be tightened even further. The future of SAST isn't just in dashboards; it's in the developer's immediate workspace. The ultimate goal is to transform tools like these into VS Code extensions or AI-assisted IDE plugins. By bringing the vulnerability analyzer directly into the code editor as a language server "skill", developers receive inline warnings the exact moment they type a hardcoded secret or implement an insecure storage method.

Conclusion

Mobile applications require specialized security tooling. By leveraging MobSF's static analysis capabilities, we found critical data storage and hardcoded secret vulnerabilities without ever launching an emulator. Automating this process ensures that fundamental security requirements are met before a single line of code reaches production.

Comments

No comments yet. Start the discussion.