mobsfscan: MobSF's mobile rules, run as a static analyser over your source tree

MobSF's rules, extracted from the mobile security framework

mobsfscan is a static analysis tool that can find insecure code patterns in your Android and iOS source code. The README lists the coverage as Java, Kotlin, Android XML, iOS Info.plist, Swift and Objective-C code, and the repository description narrows it to Java, Kotlin, Swift and Objective C.

The rules themselves come from MobSF, the Mobile Security Framework MobSF, and the matching engine is semgrep with the libsast pattern matcher underneath. That provenance is the main argument for the tool. MobSF is a well known mobile security framework, and the people who write rules for it know which insecure patterns matter on Android and iOS, in the same way that a generic SAST rule set tends to be thin on platform specifics.

The tool is a Python package that installs a single command, and the README gives the requirement as Python 3.10 to 3.14, with platform badges for macOS and Linux. The setup.py metadata matches that, with python_requires of 3.10 or above and classifiers for each of 3.10 through 3.14, and it declares itself as Development Status 5, Production/Stable, which is a claim by the package metadata rather than something the README argues.

The author is Ajin Abraham, and the package entry point is a console script named mobsfscan that points at mobsfscan.__main__:main, so the tool is usable as a library as well as a command.

It is also worth knowing what this is not. It is a static analyser over source code, not a dynamic analyser over a running application, and it does not need an application binary, a device or a network to analyse.

Five output formats, and the choice is the integration decision

The output formats are the most consequential part of the command line, and they are the reason the tool is usable in an existing pipeline rather than only on a developer machine.

$ mobsfscan
usage: mobsfscan [-h] [--json] [--sarif] [--sonarqube] [--gitlab-sast] [--html]
                 [--type {android,ios,auto}] [-o OUTPUT] [-c CONFIG]
                 [-mp {default,billiard,thread}] [-w] [--no-fail] [-v]
                 [path ...]

There is a JSON format, a SARIF 2.1.0 format, a SonarQube generic issues format for SonarQube 10.3 and later, a GitLab SAST report format, and an HTML format. The first four are the ones that matter for automation: SARIF is the interchange format that code scanning tools consume, the GitLab format drops straight into a merge request, and the SonarQube format is what a SonarQube instance imports. The HTML format is for a person.

The path argument accepts files or directories with source code, and the -o and --output option sets the output filename, while -c and --config points at a .mobsf configuration file. There is also a --type option to force android or ios rules explicitly, rather than letting the tool infer the platform from the source it finds, which matters for a monorepo that contains both.

The last two options are the ones to notice in a code review checklist. The --version flag prints the version, and the multiprocessing option accepts default, billiard or thread, so you can choose how the scan is parallelised when it runs against a large tree.

Exit codes are the CI contract, and --no-fail overrides --exit-warning

Two options decide whether a finding breaks your build, and their interaction is stated precisely in the usage text.

  -h, --help            show this help message and exit
  --json                set output format as JSON
  --sarif               set output format as SARIF 2.1.0
  --sonarqube           set output format as SonarQube generic issues (10.3+)
  --gitlab-sast         set output format as GitLab SAST report
  --html                set output format as HTML

The -w and --exit-warning option gives a non-zero exit code on warning, so a scan with warnings fails. The --no-fail option forces a zero exit code, and the usage text says explicitly that it takes precedence over --exit-warning.

That precedence is the detail that saves people from a bad afternoon. If both flags are present, the scan always succeeds, which is what a team wants when they are introducing the tool to an existing codebase that has accumulated findings, and what they do not want once the findings are being tracked as a budget.

The sensible adoption path follows from the two flags. Run with --no-fail first, collect the findings as a report, and only then decide what the exit code should mean. A tool that fails the build on day one is a tool that gets switched off, and the --no-fail precedence is the escape hatch for exactly that situation.

The example in the README shows the shape of a run and its output, with a progress line for the pattern match pass and a separate line for the semantic grep pass, followed by the version banner and the findings table.

Two matching passes, and a finding with a CWE, a CVSS and an OWASP entry

The example output in the README shows two distinct passes, labelled Pattern Match and Semantic Grep, each with its own count. That is the libsast and semgrep division of labour, and understanding it tells you what kind of finding you are looking at.

The sample finding is the rule android_webview_ignore_ssl, and the table that follows it gives the payload the tool ships with each match. The description is an insecure WebView implementation where the WebView ignores SSL certificate errors and accepts any certificate, making the application vulnerable to man-in-the-middle attacks. The type field says RegexAnd, the severity is ERROR, the input case is exact, the CVSS is 7.4, the CWE is CWE-295 Improper Certificate Validation, and the OWASP Mobile entry is M3, in the category of insecure communication.

That payload is what makes the tool usable by people who are not static analysis specialists. A rule id alone is not actionable in a ticket, but a CWE identifier, a CVSS score and an OWASP Mobile category are three different vocabularies that different parts of an organisation already use, and the tool hands you all three.

The input case field, which reads exact, is the other detail worth understanding. It tells you how the pattern was matched, which is a direct statement about false positives: a rule that matches exactly is more precise and will miss refactored variants, while a loose match is the other trade. A scanner that tells you which one it used lets you judge the finding instead of taking it on trust.

Three ways to install it, and one of them is a GitHub Action

The repository is packaged in the three ways a modern team tends to need.

The plain route is the package index, and the README's installation line is a single command, pip install mobsfscan, with the Python version requirement stated next to it.

The container route is a Dockerfile at the root that is deliberately minimal:

FROM python:3.12-slim
ENTRYPOINT ["mobsfscan"]

Between those two lines the image installs a compiler with apt-get, copies the source to /usr/src/mobsfscan, and installs the package in editable mode with pip install --no-cache-dir -e ., so the entry point is the mobsfscan command itself. That makes the container directly usable as a CI step with the scan target as an argument.

The third route is the action.yml and action.md pair at the root of the repository, which is a GitHub Action definition, so a repository can run the scan on a pull request without anyone writing the container plumbing.

The dependency picture underneath is worth a glance, because it explains the size of the install. The pinned requirements.txt lists semgrep at 1.172.0 and libsast at 3.1.8 as the two heavy entries, and then a long tail including sarif-om for the SARIF output, the OpenTelemetry API, SDK and instrumentation packages, an MCP package, starlette and uvicorn, peewee, pydantic, rich, tabulate and jschema-to-python. The repository also carries a Pipfile and Pipfile.lock, a dev-requirements.txt and a tox.ini, so the project is developed with pipenv and tox alongside the pinned requirements file.

Where mobsfscan is the wrong tool

The first wrong fit is an application whose risk lives in the runtime rather than the source. mobsfscan reads code. It will not tell you whether the certificate pinning is actually enforced on the device, whether the exported component is reachable, or whether the deep link is exploitable in the version you shipped. MobSF itself covers the dynamic side, and the split between the two tools is the reason this project exists as a separate package.

The second is a codebase outside the supported languages. The rules are written for Java, Kotlin, Android XML, Swift, Objective-C and iOS Info.plist files. A React Native or Flutter application, where the interesting code is TypeScript and the platform specific code is thin, gets very little from this rule set, and for those stacks a language-aware analyser is the better buy.

The third is a team that wants more than pattern matching. The example output shows a rule type of RegexAnd, and the README describes the engine as a pattern matcher. That is honest and it is also the limit: a rule set catches the shapes of known mistakes, not the logic of your application. Nothing in the output tells you whether a finding matters in your context, which is why the tool pairs each match with a CVSS score and a CWE rather than a verdict.

The fourth is a project that cannot accept the licence. mobsfscan is LGPL-3.0 or later, with the licence file at the root of the repository, and the package classifier says the same. For a tool that is invoked in a pipeline rather than linked into a product, that is usually the easy part of the decision, but it belongs in the review.

On the state of the project: the tagged releases are 0.4.5 on 2024-11-14, 1.0.0 on 2026-08-10 and 1.0.1 on 2026-09-21, so the 1.0 line is recent, and the last push to the repository was on 2026-09-21 with the repository not archived. The example output in the README still shows v0.3.0 in the banner, so the documentation there predates the current release.

Editorial conclusion

mobsfscan fits a team that already reviews mobile source and wants the MobSF rules available in a pull request check rather than in a separate scanner. It does not fit an app whose security review is dynamic analysis, and it does not fit a codebase that is not Java, Kotlin, Swift, Objective-C, Android XML or iOS Info.plist. Before wiring it into a pipeline, run it once with --no-fail and read the findings, because the tool is a pattern matcher and its output is only as good as the rules it ships.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. MobSF/mobsfscan on GitHub
4. README
5. Releases