Free resource

Mobile app audit-readiness checklist

16 checks a security review will actually probe, drawn from MASVS-style resilience concerns and written in plain language. Tick them off right here — nothing to download, no sign-up required.

0 / 16 complete

1 · Runtime protection

Reviewers probe what happens after launch, not just at it.

Integrity checks run continuously through the session, not only at startup.A launch-only check can pass before anything worth catching shows up later in the session.You detect runtime tampering — and can state clearly what your detection can't see.Every detection method has limits; auditors respect a stated boundary far more than a blanket claim.Every check that can trigger has a response someone chose on purpose: report, degrade, or block.Detection with no decided response is telemetry, not protection.

2 · Dependencies & SCA

What ships in the released app can differ from what's in the repo.

You can list the exact third-party libraries and versions inside your released app — not just your repo's lockfile.Build-time resolution and transitive graphs mean the shipped set isn't always the committed set.New CVE disclosures are matched against that shipped inventory on a schedule, with severity triage.A CVE published after your release date still applies to the build your users are running today.You can prove a field build's dependency inventory matches the build of record from your CI.A repackaged app can carry a swapped or edited dependency list; comparing against the build of record catches it.

3 · Keys & attestation

Where keys live, and who verifies the claim, both matter.

Session and signing keys live in hardware-backed storage where the device supports it.Keys in app memory or files are readable by anything that compromises the process.Attestation verdicts are computed off-device — never trusted from a flag the device reports about itself.A compromised device can assert anything about itself; a verdict computed off-device from evidence it can't forge can't be spoofed the same way.Device enrollment uses a fresh, server-issued challenge, and the key never leaves hardware.A fresh challenge is what keeps a genuine, one-time attestation from being reused later.

4 · Network & pinning

TLS alone doesn't decide which certificates you trust.

Certificate pinning is enforced on sensitive endpoints, with backup pins so a planned rotation doesn't brick the app.Pinning without a rotation story becomes an outage generator, and teams quietly remove it.High-value flows rely on more than one independent trust check, not a single point one bypass can remove.A single check is one step away from being neutralized; independent layers have to be defeated together.

5 · Monitoring & telemetry

A control nobody watches fails silently.

Triggered checks from the field surface somewhere a human actually looks — a dashboard or alert route.The gap between 'the SDK detected it' and 'someone saw it' is where incidents live.There's a stated policy for devices that stop reporting, rather than an assumption of health.A device that goes silent should be treated as a signal, not assumed healthy.You can document exactly what the app sends, and reporting is disclosed and opt-in where required.Privacy review is part of security review; undocumented telemetry fails both.

6 · Response plan

The audit question isn't 'can you detect it' — it's 'then what?'

Severity levels map to actions: who is paged, what the app does, and what gets revoked.A CRITICAL that pages nobody and revokes nothing is a MEDIUM with better branding.You've rehearsed the resign/repackage scenario: how a cloned build circulating in third-party stores would be detected and handled.Tamper and installer-source signals only help if someone has decided in advance what to do with them.

Where SecDog fits

Several of these are exactly what SecDog does.

Continuous runtime protection, a live inventory of what actually ships in your released app with known-vulnerability matching, independently verified device trust, a live fleet console, and went-dark flagging — that's the product. The response plan and the humans are still yours.

Request a demo See the architecture