MobSF Integration with DefectDojo

MobSF Integration with DefectDojo

Mobile Security Framework (MobSF) is an open source mobile application security testing tool for Android, iOS, and Windows apps. It performs static analysis of app binaries such as APK and IPA files, and also offers dynamic analysis, with results available in its web interface and through a REST API that returns JSON. The same project maintains mobsfscan, a command line static analyzer for Java, Kotlin, Android XML, Swift, and Objective-C source code that can write JSON output. DefectDojo imports both JSON formats, and it can also import the security scorecard (the appsec summary) that newer MobSF versions include in the JSON report.

MobSF Integration with DefectDojo

Our mobile teams scan every release build with MobSF and run mobsfscan against the source in pull requests. DefectDojo collects both. A MobSF report covers permissions, manifest settings, certificates, binary hardening, and code patterns for a single build, which is a lot of detail to act on from a browser tab. Imported into DefectDojo, each issue becomes a Finding on the app's Asset with a severity, an owner, and an SLA. Rescans of the next build are deduplicated, and reimport closes what the team fixed. On DefectDojo Pro, the MobSF connector pulls static-analysis results for every app scanned on our MobSF instance, so release builds show up without an export script.

Why MobSF Matters

Mobile apps ship to devices you don't control, so mistakes in the binary are visible to anyone who downloads it.

• MobSF analyzes the built app, so it catches problems introduced by build settings, third-party SDKs, and manifest configuration, not only source code.
• It flags dangerous Android permissions, exported components, debuggable or backup-enabled builds, weak certificate signing, and missing binary protections.
• mobsfscan brings similar checks to source code, with findings mapped to CWE, OWASP MASVS, and the OWASP Mobile Top 10.
• Both are free and self-hosted, which suits teams that can't upload unreleased apps to a third-party service.
• A MobSF report is tied to one build. Without a platform behind it, there is no record of which issues were fixed between versions.

Advantages of This Integration

What we get from running MobSF and mobsfscan results through DefectDojo:

• Two inputs, one parser. The MobSF Scan scan type detects whether a file is a MobSF API report or a mobsfscan report and parses either one.
• Grouping within a report. Repeated issues with the same title, severity, description, and category are merged into a single Finding with an occurrence count, which keeps large app reports readable.
• Deduplication across builds. MobSF Scan findings hash on title, description, severity, and file path, so the same issue in the next build is matched instead of duplicated.
• Reimport lifecycle. Reimporting the next build's report into the same Test mitigates issues that were fixed and reactivates any that come back.
• A scorecard view when you want fewer, broader findings. The MobSF Scorecard Scan type imports MobSF's own App Security Scorecard entries (high, warning, info, secure, hotspot) and records the app's security score, package name, and version in the Test description.
• No report plumbing on DefectDojo Pro. The MobSF connector discovers every scanned app, creates a Record for each, and imports its findings on a schedule.
• Mobile risk alongside everything else. Findings sit on the same Asset as backend SAST, SCA, and DAST results, and can be assigned, risk-accepted, or pushed to Jira.

How This Integration Works

DefectDojo provides two scan types for this parser. Use MobSF Scan for new work. Mobsfscan Scan is the older name for mobsfscan imports, kept so deduplication keeps working for existing Tests; the docs encourage moving to MobSF Scan.

A third scan type, MobSF Scorecard Scan, has its own parser and reads the scorecard section of the same MobSF JSON report.

1a. Get a MobSF report. After MobSF has scanned an uploaded app, request the JSON report from its REST API (/api/v1/report_json), passing the scan hash and authenticating with your MobSF API key in the Authorization header. Save the response as mobsf-report.json.

1b. Or run mobsfscan on source code. Write JSON output to a file:

mobsfscan --json -o mobsfscan-report.json ./app/src

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select MobSF Scan, and upload the file. For automation, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=MobSF Scan" \
  -F "file=@mobsf-report.json" \
  -F "product_name=android-app" \
  -F "engagement_name=Release Builds" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "MobSF Scan" \
  --report-path "./mobsf-report.json" \
  --product-name "android-app" \
  --engagement-name "Release Builds" \
  --auto-create-context

3. Reimport per build. Send each new build's report to /api/v2/reimport-scan/ against the same Test. Keep MobSF app reports and mobsfscan source reports in separate Tests, since they describe different things.

Option: import the scorecard. To track MobSF's App Security Scorecard instead of section-level detail, import the same report_json file with scan_type=MobSF Scorecard Scan (UI, API, or Universal Importer, as above). The parser reads the appsec object, so the report must come from a MobSF version that includes it. Use a separate Test, because the scorecard and MobSF Scan describe the same issues at different granularity.

Option: MobSF connector (DefectDojo Pro). The connector uses the MobSF REST API to import static-analysis results for APK and IPA apps. Copy the REST API key from the API section of the MobSF home page, then set:

• Location: your MobSF base URL (for example https://mobsf.example.com).
• Secret: the MobSF REST API key, which is sent on every request and never logged.
• Minimum Severity (optional): limits which findings are imported.

DefectDojo creates a Record for each app scanned on the instance and imports that app's findings.

Data Granularity: What Gets Imported

MobSF API report. The parser reads these sections: permissions, insecure connections, certificate analysis, manifest analysis, code analysis, binary analysis, Android API, manifest, and findings. Sections such as trackers, secrets, network security, and domains are not imported.

MobSF Scorecard Scan. One Finding per entry in the appsec severity lists; identical entries (same severity, section, title, and description) collapse into one.

MobSF connector (DefectDojo Pro). The connector maps each scanned app to a Record and imports findings from the JSON report's permissions, code analysis, signing certificate, Android manifest, Android API, and binary analysis sections. Each finding gets CWE 919 and MobSF's own severity rating, with dangerous permissions treated as High. Findings are static and de-duplicated on scan, section, title, severity, and file path.

mobsfscan report.

Use Cases

For release builds: The mobile CI job uploads each release candidate to a self-hosted MobSF instance, pulls the JSON report, and reimports it into a Test per app. Before a store submission, the release manager checks DefectDojo for active High findings on that Asset.

In pull requests: mobsfscan runs against the source tree and its report is reimported into a separate Test. Developers see source-level issues such as hardcoded values or weak crypto usage while the change is still in review.

When adding third-party SDKs: A new analytics SDK can bring new permissions and manifest entries. Comparing the next MobSF reimport with the previous Test shows exactly which Findings the SDK introduced.

For portfolio reporting: Teams with several Android and iOS apps import each into its own Asset and use DefectDojo metrics to compare open mobile Findings by app and severity.

Operational Tips

• Choose MobSF Scan or MobSF Scorecard Scan per app and stay with it. Their titles differ, so switching scan types starts a new finding history.
• The scorecard has no file path and hashes on description, so wording changes in a MobSF upgrade can reopen entries as new findings.
• Use MobSF Scan for new Tests. Only keep Mobsfscan Scan for existing Tests whose deduplication history you want to preserve.
• Expect a lot of Info Findings from permissions and secure checks. Set minimum_severity=Low on import if you don't want them in developer queues.
• API report Findings all use CWE 919, so CWE-based reports won't break mobile issues down further. Use titles and the category label in the description instead.
• Merged repeats append their descriptions, so one Finding can list many files or entries. Check the occurrence count before assuming a single instance.
• Risk-accept permissions the app genuinely needs (for example camera access in a scanning app) with a note explaining the business reason, so they stop resurfacing in triage.
• Tag imports with the platform and version (for example tags=android,4.2.0) to filter Findings by release.