Stop telling news apps to pin certificates: risk-calibrated mobile security scanning

Hossam Atef — Tue, 27 Oct 2026 11:08:23 +0000

If you've ever run a mobile security scanner on a news app, you know the report. Somewhere near the top, next to the real problems, it says: No certificate pinning detected. Run the same scanner on a banking app and you get the same line, at the same severity.

Those two apps should not get the same advice. For the banking app, missing pinning is a reasonable finding. For the news app, adding pinning brings outage risk (a rotated certificate or a missed backup pin can lock every user out) and very little security in return. A team that follows the scanner's advice literally ends up spending a sprint on something that makes their app more fragile.

That's the problem I wanted to fix. I built masaudit, a free, open-source scanner that reads the source of Android, iOS, React Native (JavaScript, TypeScript, and Expo config included), Kotlin Multiplatform, and Flutter apps, plus their GitHub Actions workflows. It asks one question first: "What kind of app is this?" Then it scales its advice to the answer.

The problem with one-size-fits-all reports

Most static scanners treat every rule as equally relevant to every app. That has two costs.

First, noise. When "your release build is debuggable" sits next to "consider pinning," developers can't tell what blocks a release. They either fix everything (slow, sometimes harmful) or start ignoring the report.

Second, missing context. "We don't pin because we're a content app" is a defensible position, but a report that never says why a check doesn't apply leaves you to argue it out with a reviewer, with no source to point to.

The idea: map app types to OWASP MAS profiles

The OWASP Mobile Application Security project (MASVS, MASTG, MASWE) already has a vocabulary for this. It describes security profiles:

L1: the baseline every app should meet.
L2: defense in depth for apps handling sensitive data.
R: resilience against reverse engineering and tampering.
P: privacy.

masaudit offers 13 app types and maps each one to a set of these profiles. A banking app gets L1 + L2 + R + P. A news or content app gets L1 + P. Each of the 207 rules belongs to one or more profiles, and every finding lands in one list:

Fix before release and Fix soon: the only two that can fail CI.
Check by hand: rules that often misread code; confirm before fixing.
Hardening checklist: protections your app type should add (pinning, root detection, App Attest), which are advice, not bugs.
Not needed for your app: with the reason. A finding your app doesn't need isn't hidden.
Notes: findings in test, debug, demo, or unused code.

The app type is your answer, not a guess. If clues in shipping code (a payment SDK, card-number fields) point to a riskier type, masaudit prints a "Check your app type" warning that names the evidence. It never switches the type on its own.

Every rule links to a section of my free book, Mobile Application Security: A Study Book for Engineers, which records how each claim was verified.

How calibration works: the pinning example

Pinning is the clearest case. The book's §8.8, "The decision, by application type," argues that you should reason from the threat, and lands roughly here:

Banking, fintech, trading, health: pin the SPKI of an intermediate, keep a backup pin, and monitor Certificate Transparency. The value of the data justifies the operational weight.
E-commerce: depends on whether the app handles card numbers itself or hands payment to a provider's SDK.
Marketplaces, ride-sharing, delivery: strict TLS, CT monitoring, and backend fraud detection.
Social, messaging, content: strict platform defaults. Pinning a news feed adds risk and no security.
Enterprise: trust your private CA explicitly, and pin only if you control both ends.

It also repeats a rule from OWASP's pinning cheat sheet: "if you can't update the pinset securely, don't pin."

In masaudit, the "no certificate pinning" rules (AND-007 for Android, IOS-007 for iOS) belong to MAS-L2 and apply only to banking, identity, health, and e-commerce apps whose own code handles card numbers. For a banking app, it goes on the Hardening checklist. Scan a content app and it shows up like this:

No certificate pinning (needed for high-risk apps) (AND-007). Pinning is for apps that handle money, health data, identity credentials, or card numbers. For other apps the book recommends strict TLS plus Certificate Transparency monitoring: pinning adds outage risk for little gain, and if you can't update the pins securely, don't pin (§8.8).

Calibration only goes one way, though. L1 rules, like a debuggable release build or a WebView that calls handler.proceed() on a TLS error, are "fix before release" for every app type.

Demo: same code, two app types

The repository includes a deliberately insecure demo app, Acme Wallet, with Android, iOS, and GitHub Actions code. Here's the same code scanned twice:

	As a banking app	As a news app
Fix before release	10	8
Fix soon	12	12
Check by hand	3	1
Hardening checklist	14	0
Not needed for your app	0	18

The banking app's 14 hardening items become the news app's "not needed" list: pinning, root and debugger detection, App Attest, Play Integrity, screenshot blocking, and more, each with its reason.

The top three fixes are the same either way: a debuggable release build (AND-002), a WebView that ignores TLS errors (AND-004), and a pull_request_target workflow that checks out the pull request's code (CI-003). Calibration removes noise without hiding what matters.

Read both reports: banking and news. Each finding has why it matters, how to fix it (often with paste-ready code), how to verify the fix, an effort estimate, its OWASP IDs, and the book section behind it.

Dogfooding: one real finding

Before releasing, I ran masaudit on the production Android app I work on. It found one real issue.

The app used Tink's AndroidKeysetManager without checking isUsingKeystore() after building it. That matters because when the Android Keystore fails, Tink can fall back to storing the keyset unencrypted and only log a warning. Your "encrypted" data is then protected by a key that anyone with file access can read. The book warns about this exact fallback, and it's the kind of thing that's easy to miss in code review because nothing looks wrong. The fix is small: check isUsingKeystore and record the result, so you know when the fallback happens.

One finding isn't a benchmark. But it was a real issue that a well-maintained codebase had missed, which is the kind of result I wanted.

How accurate is it?

A scanner with false alarms gets ignored. A scanner that misses things gives false comfort. So I measured both.

Precision: are the findings real? I scanned 19 open-source apps, including Signal, Bitwarden, Wikipedia, Nextcloud, DuckDuckGo, and Thunderbird, with every rule on. Reviewers who didn't write the rules opened every finding in shipping code (CI findings were sampled). Each false alarm was fixed, with a test. 79 rules fired, and 78 are at 90% precision or better. The one below, IOS-012 at 89%, is marked Check by hand. scripts/corpus.py reproduces the corpus at fixed commits.

Recall: what does it miss? For that I used four apps whose authors list the weaknesses they planted: OWASP's MASTG demos, DIVA, InsecureBankv2, and DVIA-v2. Of the 133 weaknesses a source scanner can see in them, version 0.4.3 found 70. That's 53%.

That wasn't good enough, so I went through every miss. Some were weaknesses no rule covered. Others were rules that missed a variant, such as accept-all trust code after a guard let unwrap. Version 0.5.0 adds 15 rules, fixes 20 others, and finds 126 of the 133, or 95%.

Read that 95% with care. I wrote the 0.5.0 rules from the 0.4.3 misses on these same apps, so it's recall on apps masaudit was tuned against, not a prediction for your code. The 7 remaining misses, and why, are published with the method. Some are on purpose: the keyboard-caching rules skip name and email fields, because flagging every name field would bury the real ones.

Version 0.6.0 added React Native's JavaScript and TypeScript, with the same method: 10 open-source React Native apps (Mattermost, Bluesky, Expensify, MetaMask, and others), every new finding judged by reviewers who didn't write the rules (57 of 63 real), and 21 of 28 planted weaknesses found in three deliberately vulnerable React Native apps, up from 6. There's also a rule-by-rule comparison with rnsec, the other free React Native scanner.

The new rules also went through the precision check. On the 19 real apps they added 3 findings, all real, and removed none.

On apps it has never seen, it's noisier, and I published that too. Everything above was measured on apps the rules were tuned on. So in five rounds I scanned 87 open-source apps no rule was written for, alongside the other free scanners (mobsfscan, Semgrep's free rules, and rnsec) on the same commits, and judged random samples of every tool's findings blind, with tool names removed.

The honest result: about 1 in 3 findings in masaudit's fix lists on unseen code is a false alarm. In the latest round (0.7.0, 16 apps), 29% of the sampled app-code findings in Fix before release and Fix soon were false, against 1 in 10 on the tuned apps. CI workflow findings held up: 1 of 30 false. The other tools did worse on the same apps: 90% of mobsfscan's sampled findings were false, 80% of rnsec's.

Each round changed the tool. Missing protections moved to the Hardening checklist, the rules most often wrong moved to Check by hand, and 0.7 reads the Gradle module graph, Xcode targets, and call sites, so findings in demo apps, test modules, and functions nothing calls stop failing CI. One caveat: the judges were AI reviewers that wrote no rule, not human experts. Every verdict and reason is published so you can check them: Benchmark on unseen apps.

Speed: DuckDuckGo for Android, about 10,000 files, scans in about 5 seconds on an Apple M5 laptop. The parsers are fuzzed in CI, and crafted inputs scan in linear time.

Using it with an AI assistant (optional)

The scanner has no AI in it and needs no account. If you use Claude Code, there's a plugin:

/plugin marketplace add hossam9k/masaudit
/plugin install masaudit@masaudit
/masaudit:scan

The same skill works in Codex, Copilot, Cursor, Gemini CLI, and other Agent Skills tools, and any chat assistant can use the fix plan at the end of every report. The assistant confirms each finding in your code and fixes one at a time. It asks before any change that alters behavior and never commits.

Limits

masaudit reads source and configuration. It can't see your server, runtime behavior, or business logic, which is where many real breaches happen. Every report has a Residual risk section that says so. It doesn't read APK or IPA files or do dynamic testing; MobSF does both, so use it alongside masaudit.

The app-type mapping is a judgment call grounded in the book and in OWASP MAS. If your app doesn't fit a type cleanly, pick the riskier one, or tell me where the mapping is wrong.

On safety: it never builds or runs the project, makes no network calls (a test enforces it), sends no telemetry, and masks secrets in every output, so it's safe to run on code you don't trust. The project has the OpenSSF Best Practices passing badge and an OpenSSF Scorecard, and releases ship with signed build provenance and SHA256SUMS.

Try it in 60 seconds

You need Python 3.9 or newer. No other dependencies.

uvx masaudit .                           # or: pipx run masaudit .
uvx masaudit . --app-type news           # skip the question
uvx masaudit --explain AND-024           # what a rule checks, offline

No installer? Download masaudit.pyz from the latest release and run python3 ~/Downloads/masaudit.pyz . (Windows: py $HOME\Downloads\masaudit.pyz .). It writes SECURITY-AUDIT.md with the top fixes first.

For teams: a GitHub Action that uploads SARIF to code scanning, writes a job summary with the verdict and top fixes, and takes a baseline so CI fails only on new findings; copy-paste setups for Bitrise, GitLab CI/CD, CircleCI, Travis CI, and Docker; a pre-commit hook; and --import-sarif to sort results from Android Lint, mobsfscan, Semgrep, and zizmor by the same app type.

Links

Repository: https://github.com/hossam9k/masaudit
Getting started (about ten minutes, on the demo app): https://github.com/hossam9k/masaudit/blob/main/docs/getting-started.md
Accuracy and speed: https://github.com/hossam9k/masaudit/blob/main/docs/precision.md
Rules (207: 70 Android, 47 iOS, 20 React Native, 48 cross-platform, 8 Flutter, 8 CI and supply chain, 6 KMP; they cover 52 of the 78 weaknesses in OWASP's MASWE catalog): https://github.com/hossam9k/masaudit/blob/main/docs/rules.md
The book: https://github.com/hossam9k/mobile-app-security

masaudit is free: code under Apache-2.0, fix snippets under MIT-0, explanations under CC BY-SA 4.0. It's not an OWASP project, and OWASP doesn't endorse tools. If a rule fires where it shouldn't, please open an issue. False-positive reports are the most useful contribution, because a rule that raises false alarms gets ignored.

DEV Community: Hossam Atef