Mobile App Security Audit Checklist for CI/CD

Security isn’t a phase you bolt on at the end. If you’re shipping mobile apps through a CI/CD pipeline, vulnerabilities can slip in fast. A mobile app security audit checklist built into your CI/CD pipeline catches issues before they reach users. I’ve put together a practical set of checks that work with Flutter, React Native, or native builds.

Think of this as your baseline. Not everything applies to every project, but most teams should aim for at least these seven layers.

What Is a Mobile App Security Audit in CI/CD?

A mobile app security audit in CI/CD means running automated checks every time you build or deploy. Static analysis scans the source code. Dependency checks spot libraries with known vulnerabilities. Secret scanning prevents keys from leaking. Dynamic tests exercise the running app.

These checks run as stages or jobs in your pipeline. If any fails, the build stops. That way, you never ship a version with a critical flaw.

Why Integrate Security Checks Into the Pipeline?

Doing security audits manually is slow and inconsistent. Automating them makes security part of your everyday development. You get faster feedback, fewer regressions, and a clear audit trail.

For teams using Flutter or React Native, many vulnerabilities come from third-party packages. A pipeline scan catches those instantly. It also enforces best practices like not hardcoding API keys.

7-Step Mobile App Security Audit Checklist for CI/CD

1. Static Application Security Testing (SAST)

SAST tools analyze your source code without running it. They look for SQL injection, insecure data storage, hardcoded credentials, and broken cryptography.

For Flutter, I use Dart Code Metrics combined with custom lint rules. For React Native, ESLint with security plugins works well. Native Android projects can use SpotBugs; iOS uses SwiftLint with security rules.

Add a pipeline step that runs SAST on every pull request. Fail the build if any high-severity issue is found.

2. Dependency Vulnerability Scanning

Third-party libraries are a major source of risk. Tools like OWASP Dependency-Check or Snyk scan your package files for known vulnerabilities.

Run this after SAST. If a known critical CVE exists, the pipeline should block the merge. I also recommend generating a dependency report and storing it with the build artifact.

3. Secret Detection

Hardcoded API keys, tokens, and passwords happen to everyone. Secret scanning tools like GitLeaks or truffleHog catch them before they hit the repo.

Run this step early in the pipeline. If a secret is detected, fail the build immediately and notify the team. Never push secrets to version control.

4. Dynamic Application Security Testing (DAST)

DAST tests the running app. For mobile, this means spinning up an emulator or physical device in your CI environment and running automated attacks.

You can use MobSF (Mobile Security Framework) for dynamic analysis. It checks for insecure network communication, weak encryption, and exposed components. This step is more resource-intensive, so run it on the main branch or nightly builds.

5. Network Security Configuration

Mobile apps communicate with backends. Misconfigured SSL/TLS can expose data. In your pipeline, verify that Android’s network_security_config.xml and iOS’s Info.plist allow only secure connections.

I write a small script that parses these files and checks for pinning, certificate transparency, and disallowed cleartext. For React Native apps, also check the react-native-config or similar setup.

Learn more about API security in our guide on securing mobile app APIs against common threats.

6. Data Storage and Privacy Checks

Mobile apps often store data locally. Check that sensitive data isn’t written to shared preferences or UserDefaults without encryption. Use EncryptedSharedPreferences on Android and the iOS Keychain.

In the pipeline, run a static analysis rule that flags any use of plaintext storage APIs. For Flutter, this means looking for SharedPreferences without encryption. For React Native, check @react-native-async-storage/async-storage usage.

7. Build Integrity and Signing Verification

At the end of the pipeline, verify the build’s integrity. Check that the APK or IPA is signed with the correct certificate and that the signing hash matches your records.

This prevents tampered builds from slipping through. Add a final pipeline step that runs apksigner verify for Android or codesign -dv for iOS.

Comparison: SAST vs DAST vs Dependency Scanning

Type	When It Runs	What It Finds	False Positives
SAST	During build (source code)	Injection, hardcoded secrets, weak crypto	Moderate
DAST	On running app	Network flaws, runtime misconfigurations	Low
Dependency Scan	After package install	Known CVEs in libraries	Low

Common Pitfalls When Automating Security in CI/CD

One mistake is ignoring false positives. If your SAST tool flags too many low-severity issues, teams start ignoring them. Tune the rules to your app’s risk profile. Another mistake is running all scans only on the main branch. Shifting left means running them on every branch.

Also avoid slowing down the pipeline too much. Run lightweight scans (SAST, secrets) on every commit, and heavy scans (DAST) less frequently. The goal is to catch issues without killing velocity.

Setting Up a Security Stage in Your Pipeline

Most CI tools let you define stages. Create a security stage with three jobs: SAST, dependency check, and secrets scan. Make each job mandatory. If any fails, the pipeline stops.

Example order: lint → SAST → secrets → dependency check → build → DAST → signing verification. This catches code issues early, then verifies the final artifact.

Remember to store scan reports as artifacts for auditing. You’ll thank yourself later during compliance reviews.

How to Handle Security Scan Results in a Team

Once scans start failing builds, you need a process. First, triage each finding. Is it a real vulnerability or a false positive? For true positives, assign a team member and set a severity level. Critical issues should block the release. Medium issues can be tracked for the next sprint.

I recommend a dedicated Slack channel or Jira board for security findings. That way no one ignores a pipeline failure. Also, decide how long to wait before escalating. For example, if a critical issue isn’t fixed within 24 hours, notify the tech lead.

Choosing the Right Scanning Tools for Your Stack

Not all tools work equally well with every framework. For Flutter, Dart Code Metrics is great for SAST, but you’ll also want flutter_secure_storage checks manually. For React Native, ESLint-plugin-security catches many issues, and react-native-encrypted-storage should be enforced.

If you’re using a monorepo with multiple mobile apps, consider tools that support multiple languages. SonarQube can analyze Dart, JavaScript, Swift, and Kotlin in one place. It also tracks technical debt over time. Just be aware that SonarQube requires a server setup, which adds overhead.

Ending Takeaway

Start with at least SAST, dependency scanning, and secret detection. Run them on every build. Once those are stable, add DAST nightly. Your users and your future self will be grateful.

Frequently asked questions

What is the most important security check to add to a mobile CI/CD pipeline?

Start with secret detection. Hardcoded credentials are the most common and dangerous issue. Tools like GitLeaks or truffleHog can catch API keys, tokens, and passwords before they reach the repository. Adding this check is simple and has a high impact.

How often should I run dynamic security tests on my mobile app?

Run dynamic application security testing (DAST) at least nightly or on every main branch build. Since DAST requires an emulator or device, it’s slower and more resource-intensive. Running it less frequently than static analysis is acceptable, but don’t skip it entirely.

Can I use the same security tools for Flutter and React Native?

Not entirely. SAST tools differ by language. For Flutter, use Dart-specific linters and analyzers. For React Native, use ESLint with security plugins. Dependency scanning tools like OWASP Dependency-Check work for both since they scan the package manifest files (pubspec.yaml or package.json).

What should I do when a security scan fails the pipeline?

Investigate the issue immediately. If it’s a true positive, fix it before merging. If it’s a false positive, you can suppress the finding, but document why. Never bypass the security stage without review. Treat pipeline failures as blockers.

How do I secure secrets used in mobile app builds?

Never hardcode secrets in the source code or configuration files. Use environment variables or secrets management features in your CI/CD platform. For mobile apps, retrieve secrets at runtime from a secure backend or use encrypted storage. Always revoke and rotate secrets if one is exposed.