Continuous Mobile Security Testing at Release Velocity with Ostorlab
Bumble validates security in every iOS and Android release using a combination of tooling, including Ostorlab, embedded directly into their release process. Scans run continuously through CI-initiated workflows and are complemented by scheduled scans, ensuring Bumble assesses security as the app changes over time, not only at major milestones.
Mobile product teams ship frequently. Bumble needed a way to validate security in every release while balancing security risk with product cadence. The approach had to support the following:
- Scale consistently across multiple apps and product teams
- Standardize expectations for what is scanned, when it runs, and what blocks a release
- Avoid blocking releases for lower-risk findings while still ensuring they are fixed
- Reduce variability and ambiguity during triage so engineers can move quickly
Continuous security testing in the release workflow
Bumble runs security scans consistently as part of the iOS and Android release process. This is primarily done through CI-initiated scans, complemented by scheduled scans to maintain ongoing coverage.
This model helps ensure the team continuously assesses the app's evolving attack surface, rather than relying solely on last-minute, manual review.
Severity-based release gating
Bumble uses clear guardrails to protect users without slowing product delivery.
- High or Critical findings: release is blocked until remediation is completed and the issue is confirmed resolved
- Medium, Low, or Informational findings: release is not automatically blocked; remediation work is created and prioritized through the fix pipeline
This approach avoids stop-the-line dynamics for lower-severity findings while ensuring issues still get tracked and addressed.
Bumble follows the same overarching security testing process across its portfolio. Standardization comes from:
- Running the same CI-initiated scans and the same scheduled scans across apps
- Applying centralized severity thresholds so release decisions are consistent across teams
- Making outcomes predictable so teams know what will run, what constitutes a blocker, and how non-blocking findings will be handled
This reduces variability across apps and teams and helps scale security practices without reinventing the process for each product.
By using a consistent scanning approach and centralized severity thresholds, we reduce variability between apps and between teams in how findings are interpreted and acted upon.
— Bumble
For Bumble, automation needs to reduce cycle time without adding headcount. That requires more than running static checks. It requires testing that is relevant, reproducible, and engineered for fast triage.
Requirement 1: Testing that exercises the application
Bumble emphasized that automated continuous security testing must intelligently exercise the application and perform fuzzing in a controlled way, rather than relying only on static analysis.
Requirement 2: Relevance to real endpoints
A key requirement is the ability to target Bumble's own endpoints so results remain relevant and actionable for engineering teams.
Requirement 3: Traceability from summary to raw evidence
Bumble also emphasized traceability at two levels:
- High-level overview: what ran, which endpoints were tested, and which techniques were attempted
- Full raw evidence: detailed logs showing the exact requests, payloads, responses, and steps taken so engineers can reproduce and validate quickly
This supports faster remediation by reducing guesswork and back-and-forth during triage.
By shifting security testing left and using Ostorlab continuously, Bumble increased confidence that the attack surface of its publicly available mobile apps does not contain obvious, easily exploitable flaws at release time.
Operationally, embedding continuous scanning into the process supports both velocity and security goals:
- Maintain release cadence while enforcing clear guardrails
- Block releases only for High and Critical severity findings
- Maintain consistent visibility into risk across the app portfolio
Having continuous scanning embedded into our process supports both velocity and security goals.
— Bumble
Code changes move through the normal mobile release process
CI-initiated security scans run continuously, complemented by scheduled scans
Findings are evaluated using centralized severity thresholds
High or Critical findings block the release until fixed and verified
Medium, Low, and Informational findings are routed into a remediation pipeline
Engineers use the scan summary plus raw evidence to reproduce and remediate efficiently
Bumble's approach demonstrates how mobile security testing can be operationalized as a continuous practice. With clear release guardrails, standardized scanning across teams, and evidence-rich traceability, security becomes a built-in capability of delivery rather than a last-minute checkpoint.
Get Started
See how this works in your CI pipeline
Get a walkthrough of how teams set up continuous mobile security testing with severity-based release gating and evidence-rich findings in Ostorlab.
Book a Demo