The team added a security scan to the mobile pipeline in the spring. By summer it was taking long enough that developers started merging before it finished. By fall someone had moved it to a nightly job “until we fix the performance,” and nobody read the nightly results. In November, a pentester pulled a payments secret key out of the React Native JavaScript bundle in about ten minutes. The scanner had flagged it on the day it was committed, in a report nobody opened.<\/p>\n
The scanner worked. The pipeline design did not.<\/p>\n
Most teams that try to add mobile security to CI\/CD fail the same way: they bolt one large, slow, noisy scan onto every build, developers route around it, and the security signal disappears. This guide covers how to design a pipeline that catches real issues early without becoming the reason releases slip.<\/p>\n
Web teams can often scan a service, deploy, and patch the same day. Mobile teams cannot. Once a build is in the App Store or Google Play, a fix requires a new release, store review, and users actually updating. Some will run the vulnerable version for months. That makes catching issues before release more valuable for mobile than almost anywhere else.<\/p>\n
Mobile pipelines are also heavier. A single change can produce an Android App Bundle, an iOS archive, and a shared Flutter or React Native layer, each with its own dependencies. Dynamic testing needs a device or emulator. Builds already take a while, and every minute added to a pull request check is a minute developers will try to avoid.<\/p>\n
The answer is not to scan less. It is to scan the right things at the right stage, and to block only on what matters.<\/p>\n
Here is the issue from the opening, in a React Native app:<\/p>\n
\/\/ Vulnerable: CWE-798. A server-side secret is bundled into the client app.\nimport Config from 'react-native-config';\n\nexport async function createCharge(amountCents: number, token: string) {\n return fetch('https:\/\/api.payments.example.com\/v1\/charges', {\n method: 'POST',\n headers: {\n Authorization: `Bearer ${Config.PAYMENTS_SECRET_KEY}`,\n 'Content-Type': 'application\/json',\n },\n body: JSON.stringify({ amount: amountCents, source: token }),\n });\n}<\/code><\/pre>\nValues read through react-native-config<\/code> (or any .env<\/code> approach for mobile) are compiled into the app. Anyone can unzip the APK or IPA and read them. Environment variables keep secrets out of your Git history, but they do not keep secrets out of the binary. This maps to CWE-798 (Use of Hard-coded Credentials) and to MASVS-CRYPTO-2, which requires key management according to industry best practices.<\/p>\nThe fix is architectural. Secret keys belong on your server. The app authenticates the user and asks your backend to perform the privileged action:<\/p>\n
\/\/ Fixed: the client only sends the user's session; the secret stays server-side.\nimport { getSessionToken } from '.\/auth';\n\nexport async function createCharge(amountCents: number, paymentMethodId: string) {\n const session = await getSessionToken();\n return fetch('https:\/\/api.yourapp.example.com\/payments\/charges', {\n method: 'POST',\n headers: {\n Authorization: `Bearer ${session}`,\n 'Content-Type': 'application\/json',\n },\n body: JSON.stringify({ amount: amountCents, paymentMethodId }),\n });\n}<\/code><\/pre>\nYour backend validates the session, applies its own business rules (amount limits, fraud checks), and calls the payment provider with the secret key it holds. If a provider offers publishable or restricted client-side keys, those are the only keys that belong in the app. And because the original key has already shipped in released builds, rotate it immediately. Removing it from the next build does not protect the versions already on users’ devices.<\/p>\n
This is the kind of finding a pipeline must catch at the pull request, every time, in seconds.<\/p>\n
Design the Pipeline in Tiers<\/h2>\n
The core idea is simple: match the depth of each check to how often it runs and how long developers will wait for it.<\/p>\n
Tier 1: Pull request checks (minutes)<\/h3>\n
Run fast, high-confidence checks on every pull request: secrets detection, targeted SAST rules for your highest-risk patterns, and a dependency check against your lockfiles. Aim for a few minutes end to end, and make these checks diff-aware so they only report issues introduced by the change. A developer will fix a finding in code they wrote ten minutes ago. They will ignore a list of 300 findings in code they have never seen.<\/p>\n
Tier 2: Merge to main (tens of minutes)<\/h3>\n
On merge, run the full SAST and SCA scan across the whole codebase for every platform. This is where you catch issues that span files, update your baseline, and generate the reports your security person reviews. It should not block individual developers, but it should open tickets automatically for new high-priority findings.<\/p>\n
Tier 3: Release candidates (as long as it needs)<\/h3>\n
When a release candidate is built, run the deep checks: dynamic testing of the actual binary on a device or emulator, API testing against staging, and a review of what changed in permissions, privacy declarations, and third-party SDKs since the last release. This is the release gate, and because it only runs on release candidates, it can take the time it needs.<\/p>\n
Block on Exploitability, Not Volume<\/h2>\n
The fastest way to destroy trust in a security gate is to block a release on findings that do not matter. Set explicit rules for what fails a build:<\/p>\n
Block<\/strong> on new findings that are reachable, externally exposed, and touch sensitive data or authentication: hardcoded secrets<\/a>, disabled certificate validation, exported components with sensitive behavior, and reachable dependency vulnerabilities with known exploitation.<\/p>\nWarn<\/strong> on everything else that is new. It goes into the pull request as a comment or a ticket, not a red build.<\/p>\nBaseline<\/strong> existing findings. Record them, prioritize them separately, and burn them down on a schedule. Do not hold every pull request hostage to years of accumulated debt.<\/p>\nAllow exceptions with an expiry.<\/strong> When a team needs to ship despite a blocking finding, require a named owner, a reason, and a date. An exception without an expiry quietly becomes permanent.<\/p>\nA Minimal Pull Request Check You Can Add Today<\/h2>\n
You can get a useful Tier 1 gate running with open source tooling. Here is a GitHub Actions example using Semgrep’s diff-aware mode:<\/p>\n
name: mobile-security-pr\non: pull_request\n\njobs:\n fast-security-checks:\n runs-on: ubuntu-latest\n timeout-minutes: 10\n steps:\n - uses: actions\/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Secrets and high-risk patterns (new findings only)\n run: |\n pip install semgrep\n semgrep scan \\\n --config p\/secrets \\\n --config .semgrep\/ \\\n --baseline-commit \"origin\/${{ github.base_ref }}\" \\\n --error<\/code><\/pre>\nThe --baseline-commit<\/code> flag limits results to issues introduced by the pull request, and --error<\/code> fails the job only when something new is found. Put your own high-risk rules in .semgrep\/<\/code>: patterns like trust-all certificate callbacks, android:exported=\"true\"<\/code> on activities that load URLs, or secrets read from build config into network headers. Add your platform’s dependency audit for lockfiles, keep the timeout tight, and you have a gate developers will not need to route around.<\/p>\nMake Fixing Faster Than Ignoring<\/h2>\n
Detection is only half of the pipeline. If every finding turns into a research project, developers will treat security checks as a tax, no matter how well the gate is tuned.<\/p>\n
A few practices make a large difference. Put the finding where the developer already is: an inline pull request comment on the exact line, not a link to a separate dashboard. Include the fix, not just the CWE: a two-sentence explanation and a code suggestion get resolved; a link to a 40-page standard does not. Route findings to the code owner automatically, so nobody has to triage who should fix what. And measure time to fix, not just findings found. If that number is climbing, the pipeline is producing noise, not security.<\/p>\n
Where DIY Pipelines Hit a Wall<\/h2>\n
A Tier 1 gate built on open source rules is a real improvement, and every team should have one. The harder parts come next. Deep SAST across Kotlin, Swift, Dart, and TypeScript, dynamic testing on real binaries, API scanning, dependency reachability, triage that separates the one exploitable issue from the hundred harmless ones, and writing fixes in four languages: each is a project of its own. For a Series A company with one or two security people, maintaining all of it alongside everything else is where pipelines stall, and where the nightly job nobody reads comes back.<\/p>\n
How Nandee Fits Into Your Pipeline<\/h2>\n
Nandee is an AI Mobile Application Security Engineer that plugs into your existing CI\/CD and handles the deep work in each tier.<\/p>\n
Scan at every stage.<\/strong> Nandee runs SAST, DAST, and SCA\/OSS analysis across native iOS, native Android, Flutter, and React Native apps, along with API scanning and privacy analysis. CI\/CD integrations let you run the right checks on pull requests, merges, and release candidates without building the plumbing yourself.<\/p>\n