Ostorlab Logo
Tarifs
Études de cas Bumble Inc.

Tests de sécurité mobile continus au rythme des releases avec Ostorlab

Bumble valide la sécurité de chaque release iOS et Android grâce à des outils, dont Ostorlab, intégrés directement à son processus de livraison. Les analyses s'exécutent en continu via des workflows déclenchés par la CI et sont complétées par des analyses planifiées, garantissant à Bumble une évaluation de la sécurité tout au long de l'évolution de l'application, et non uniquement lors des étapes clés.

iOSAndroidAnalyse continueSurveillance Play Store et App StoreIntégration CI/CD
Le défi

Les équipes produit mobile déploient fréquemment. Bumble cherchait un moyen de valider la sécurité à chaque release tout en équilibrant le risque de sécurité et la cadence de production. L'approche devait répondre aux critères suivants :

  • S'adapter de manière cohérente à de multiples applications et équipes produit
  • Standardiser les attentes concernant le périmètre des analyses, leur fréquence d'exécution et les critères bloquants pour une release
  • Éviter de bloquer les releases pour des vulnérabilités mineures, tout en garantissant leur correction
  • Réduire la variabilité et l'ambiguïté lors du triage pour permettre aux ingénieurs d'avancer rapidement
Application Bumble — Fonctionnalités Club de lecture, Chat, Événements et profil
L'approche
1

Tests de sécurité continus dans le workflow de release

Bumble exécute des analyses de sécurité systématiques dans son processus de release iOS et Android. Cela se fait principalement via des analyses déclenchées par la CI, complétées par des analyses planifiées pour maintenir une couverture continue.

Ce modèle garantit que l'équipe évalue en permanence l'évolution de la surface d'attaque de l'application, plutôt que de s'en remettre uniquement à une revue manuelle de dernière minute.

2

Blocage des releases basé sur la criticité

Bumble applique des garde-fous stricts pour protéger ses utilisateurs sans ralentir le cycle de livraison.

  • Vulnérabilités critiques ou élevées : la release est bloquée jusqu'à ce que la remédiation soit terminée et que la résolution du problème soit confirmée
  • Vulnérabilités moyennes, faibles ou informatives : la release n'est pas bloquée automatiquement ; des tickets de remédiation sont créés et priorisés dans le pipeline de correction

Cette approche évite de bloquer systématiquement la production pour des failles mineures tout en s'assurant que les problèmes sont suivis et traités.

Résumé d'analyse automatisée Ostorlab publié sur une pull request GitHub
Ostorlab publie les résultats d'analyse directement sur les pull requests, offrant aux équipes une visibilité immédiate sur les vulnérabilités.
Standardiser les tests de sécurité sur un portefeuille multi-applications

Bumble applique un processus global de tests de sécurité identique à l'ensemble de son portefeuille. Cette standardisation repose sur :

  • L'exécution des mêmes analyses déclenchées par la CI et planifiées pour l'ensemble des applications
  • L'application de seuils de criticité centralisés afin d'uniformiser les critères de mise en production entre les équipes
  • La prévisibilité des résultats : les équipes savent quelles analyses seront exécutées, ce qui constitue un point de blocage, et comment seront traitées les failles non bloquantes

Cela réduit les disparités entre les applications et les équipes, et permet de mettre à l'échelle les pratiques de sécurité sans réinventer le processus pour chaque produit.

En utilisant une approche d'analyse standardisée et des seuils de criticité centralisés, nous réduisons la variabilité entre les applications et les équipes quant à l'interprétation et au traitement des vulnérabilités.

— Bumble
Ce que les tests automatisés continus doivent fournir pour réduire les délais de livraison

Pour Bumble, l'automatisation doit réduire les cycles de livraison sans augmenter les effectifs. Cela nécessite plus que de simples contrôles statiques. Il faut des tests pertinents, reproductibles et conçus pour un triage rapide.

1

Exigence 1 : Des tests qui sollicitent l'application

Bumble a souligné que les tests de sécurité continus automatisés devaient solliciter l'application de manière intelligente et réaliser du fuzzing de façon contrôlée, plutôt que de s'appuyer uniquement sur l'analyse statique.

2

Exigence 2 : Pertinence vis-à-vis des endpoints réels

Une exigence clé est la capacité à cibler les propres endpoints de Bumble pour que les résultats restent pertinents et actionnables par les équipes techniques.

3

Exigence 3 : Traçabilité, de la synthèse aux preuves brutes

Bumble a également mis l'accent sur la traçabilité à deux niveaux :

  • Vue d'ensemble : ce qui a été exécuté, les endpoints testés et les techniques employées
  • Preuves brutes complètes : des journaux détaillés montrant exactement les requêtes, les payloads, les réponses et les étapes suivies pour permettre aux ingénieurs de reproduire et valider rapidement la faille

Cela accélère la remédiation en réduisant les conjectures et les allers-retours inutiles lors du triage.

L'impact de l'approche Shift-Left avec Ostorlab

En intégrant la sécurité en amont (Shift-Left) et en utilisant Ostorlab en continu, Bumble a considérablement accru sa certitude que la surface d'attaque de ses applications mobiles publiques ne présente pas de failles évidentes et facilement exploitables lors de la mise en production.

D'un point de vue opérationnel, l'intégration de l'analyse continue au processus soutient à la fois les objectifs de vélocité et de sécurité :

  • Maintenir la cadence de livraison tout en appliquant des garde-fous clairs
  • Ne bloquer les releases que pour des vulnérabilités de sévérité Critique ou Élevée
  • Conserver une visibilité cohérente sur les risques pour l'ensemble du portefeuille d'applications

L'intégration de l'analyse continue à notre processus permet de soutenir à la fois nos objectifs de vélocité et de sécurité.

— Bumble
Récapitulatif du workflow
1

Les modifications de code suivent le processus normal de livraison mobile

2

Des analyses de sécurité déclenchées par la CI s'exécutent en continu, complétées par des analyses planifiées

3

Les résultats sont évalués en fonction de seuils de criticité centralisés

4

Les vulnérabilités critiques ou élevées bloquent la release jusqu'à leur correction et vérification

5

Les vulnérabilités moyennes, faibles et informatives sont redirigées vers un pipeline de remédiation

6

Les ingénieurs utilisent le rapport de synthèse et les preuves brutes pour reproduire et corriger efficacement la faille

L'approche de Bumble démontre comment les tests de sécurité mobile peuvent être opérationnalisés comme une pratique continue. Avec des garde-fous de livraison clairs, une analyse standardisée entre les équipes et une traçabilité étayée par des preuves, la sécurité devient une composante intégrée à la livraison plutôt qu'un point de contrôle de dernière minute.

Commencer

Découvrez comment l'intégrer à votre pipeline CI

Obtenez une démonstration de la configuration de tests de sécurité mobile continus dans Ostorlab, avec un gating des releases basé sur la criticité et des rapports étayés par des preuves.

Réserver une démo