TL;DR — I took an intentionally vulnerable Android application, ran the static analysis engine of MobSF (Mobile Security Framework) via a local Docker container, and immediately identified critical flaws like hardcoded API keys and insecure local data storage. In mobile development, catching these issues at the source code level is vital before the APK is compiled, signed, and distributed.
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.
Demo repository (code + CI workflow): https://github.com/GianfrancoArocutipa/psalm-sast-demo(#)
Top comments (1)
Really solid demo, Fabrizio. What strikes me is the contrast with source-level SAST tools: I used Psalm on PHP, which needs the original source and tracks taint from $_GET to a sink — MobSF doesn't even need the source, it decompiles the APK and audits what an attacker would actually see. Your SharedPreferences example is essentially the same source→sink model (userToken flowing into an unencrypted store), just applied at the binary level. One thing worth adding for readers: the fix — EncryptedSharedPreferences from Jetpack Security — is a two-line change, which makes it even less excusable to ship without it. Also, heads-up: the demo repository link at the end seems to point to the wrong repo. Nice work with the Docker deployment, two commands and zero dependency hell is a great selling point.