MobSF Binary Scan

Q: Can the build fail based on the security score?

Yes. A minimum security score threshold can break the build when the AppSec score falls below it, turning security posture into an enforceable release criterion alongside things like test coverage or build success.

Q: Does this step require a separate scanning server or container?

No. The scan runs directly on the runner where MobSF has been provisioned, without an always-on scanning server or container runtime, so application binaries and their reports never need to leave your environment.

Q: Where in the workflow should the scan be placed?

After the signing step. Scanning an unsigned or intermediate build produces misleading certificate and binary-protection results, since those checks reflect the exact artifact that gets analyzed.

Q: Are scan reports safe to store without extra precautions?

No, treat them as sensitive material. Binary analysis can surface hardcoded credentials and API keys, so access to reports should be restricted, and any secret the scan finds should be rotated rather than just removed from the next build.

Q: What format does the scan report use?

A single JSON report, saved as mobsf-binary-analyze.json in your output directory, containing the full finding set alongside the security score.

Q: How does this differ from MobSF Source Code Scan?

This step analyzes the compiled APK, AAB, or IPA you're about to release. To catch insecure coding patterns and hardcoded secrets in your project's source before it's built, use MobSF Source Code Scan instead.

Integrating MobSF binary scanning in Appcircle's CI/CD pipelines provides automated security analysis of the compiled APK, AAB, or IPA, producing a scored assessment of permissions, signing, binary protections, and embedded secrets for every build.

Key Benefits

Binary-Level Security Analysis: Analyzes the compiled APK, AAB, or IPA as it will be released, surfacing issues that source scanning cannot see: manifest configuration, requested permissions, code signing and certificate details, binary protections, network security configuration, embedded secrets, and third-party trackers.

Quantified Security Score: Produces an AppSec score and scorecard for every build, turning mobile security posture into a value you can track and report on rather than a document someone has to read and interpret.

Score-Based Build Gate: Applies a minimum security score threshold that can fail the build, making security posture an enforceable release criterion in the same way test coverage or build success already are.

Self-Contained Execution: Runs the analysis on your own runner without requiring a separate always-on scanning server or container infrastructure, so application binaries and their reports never leave your environment, a prerequisite for regulated and air-gapped deployments.

Points to Consider

Runner Requirements: The scan runs on a runner with MobSF provisioned and takes minutes rather than seconds, so plan workflow timeouts and runner capacity accordingly, particularly on pipelines that build multiple variants.

Workflow Placement: Position the scan after the signing step so the artifact analyzed is the one you intend to distribute; scanning an unsigned or intermediate build will produce misleading certificate and protection results.

Sensitive Report Content: Binary analysis can surface hardcoded credentials and API keys, so treat scan reports as sensitive material, restrict who can access them, and rotate any secret the scan identifies rather than only removing it from the next build.

Report Retention and Cleanup: Confirm that scan records are cleared from shared runners between builds, and align report retention with the period your audit and compliance processes need to reference, not just the current release cycle.