Score de sécurité MobSF : ce qu’il signifie pour votre app

Un partenaire sécurité, un auditeur ou votre propre équipe passe votre app dans MobSF, et un chiffre tombe : disons 48 sur 100. Le réflexe naturel est de se demander comment atteindre 80. La meilleure question est de savoir de quoi ce 48 est réellement fait.

Dans cet article, nous expliquons ce que mesure un score MobSF, les trois façons dont il induit en erreur, et comment transformer un rapport de scanner en constats que quelqu’un peut prendre en charge et corriger — avec les chiffres réels d’un audit d’application bancaire que nous avons mené.

Ce que mesure MobSF

MobSF (Mobile Security Framework) analyse statiquement le binaire d’une app. Il lit le manifeste, décompile le code, recense les bibliothèques et vérifie la configuration au regard d’un ensemble de règles. Chaque règle non respectée fait baisser le score.

C’est ce qui rend MobSF rapide, reproductible et utile. Mais cela signifie aussi que le score reflète des motifs présents dans le binaire, et non le niveau de sécurité de l’app en usage réel.

📌 À retenir :

Un score MobSF répond à la question « combien de règles ce binaire a-t-il enfreintes ? », pas à « à quel point cette app est-elle difficile à attaquer ? »

Trois façons dont le score MobSF induit en erreur

1. Le type de build change le score

Les builds debug embarquent des paramètres que les builds release ne devraient pas contenir : indicateurs debuggable, configuration de test, journalisation verbeuse, etc. Analysez le mauvais build et vous notez quelque chose que vos utilisateurs n’installent jamais.

Dans l’application bancaire que nous avons auditée, 6 à 7 des 52 points manquants venaient du seul type de build. Avant que quiconque modifie une ligne de code, une partie du problème tenait simplement au fichier qui avait été analysé.

2. « Sécurisé » ne veut pas toujours dire sécurisé

Les règles statiques reconnaissent des motifs. Quand le code ressemble à une implémentation correcte, la règle passe — même si le contrôle ne fonctionne pas comme il le semble. Lors de ce même audit, deux contrôles marqués comme sécurisés étaient des faux positifs. Une coche verte est une affirmation à vérifier, pas une conclusion.

3. Le scanner ne voit pas la logique

Certaines des failles mobiles les plus graves se trouvent dans la logique, pas dans la configuration :

Un parcours d’authentification qui se fie à un indicateur côté client.
Une connexion biométrique qui se contente de vérifier un callback de succès.
Des données sensibles écrites dans un emplacement de stockage que les règles n’inspectent pas.

Aucune de ces failles ne modifie de façon fiable un score statique. Elles exigent une revue humaine.

Comment bien lire un rapport MobSF

Reproduisez le score sur le build release. Sans base de référence reproductible, aucune amélioration ne peut être prouvée.
Répartissez les points perdus par catégorie : bruit lié au type de build, véritables lacunes de configuration et constats qui demandent du contexte.
Vérifiez les coches vertes sur tout ce qui est critique pour la sécurité.
Menez un audit manuel selon l’OWASP Mobile Top 10 (2024) pour couvrir ce que le scanner ne voit pas.
Notez chaque lacune réelle avec le CVSS, afin que les priorités suivent la gravité, pas le volume.

Score brut ou constats audités

Critère	Score MobSF brut	Constats audités
Ce qui est compté	Règles enfreintes par le binaire	Failles réelles et vérifiées
Bruit lié au type de build	Inclus	Retiré
Fausses coches « sécurisé »	Masquées	Identifiées
Failles de logique	Le plus souvent invisibles	Couvertes par la revue manuelle
Priorisation	Aucune	Score CVSS par lacune

Comment Mobian vous aide

Chez Mobian, l’audit à l’origine de ces chiffres est parti d’un score de 48/100 pour aboutir à 48 lacunes notées CVSS et 124 correctifs suivis. Si vous avez déjà un rapport MobSF, nous pouvons vous en livrer une lecture d’une page : ce qui est réel, ce qui relève du bruit et ce qui mérite un second regard. Pour une vision complète, notre Mobile Security Teardown de deux semaines ajoute un audit OWASP manuel et un plan de remédiation chiffré.

Conclusion

MobSF est un bon outil employé à mauvais escient quand on traite son score comme un verdict. Analysez le build release, séparez le bruit des constats, vérifiez les coches vertes et auditez la logique à la main. Le chiffre compte moins que la liste des lacunes réelles et notées qui en ressort.

Questions fréquentes

Qu’est-ce que MobSF ?

MobSF (Mobile Security Framework) est un outil open source qui analyse les binaires d’applications Android et iOS. Son analyse statique examine le manifeste, le code, les bibliothèques et la configuration, et produit un rapport assorti d’un score de sécurité de 0 à 100.

Pourquoi mon score MobSF a-t-il changé entre deux analyses de la même app ?

La raison la plus fréquente est le type de build. Un build debug embarque des paramètres, comme les indicateurs debuggable et la configuration de test, qu’un build release n’a pas, et le scanner les pénalise. Lors d’un audit que nous avons mené, 6 à 7 des 52 points perdus par une app venaient du seul type de build. Analysez toujours le build que vos utilisateurs installent.

Un contrôle MobSF marqué comme sécurisé peut-il être faux ?

Oui. L’analyse statique repère des motifs ; elle ne comprend pas l’intention. Lors de l’audit d’une application bancaire, deux contrôles que le scanner donnait comme sécurisés étaient des faux positifs. Chaque contrôle important, réussi ou échoué, mérite une vérification manuelle.

Qu’est-ce que MobSF ne détecte pas ?

L’analyse statique voit le binaire, pas la logique métier. Elle ne peut pas dire si un parcours d’authentification peut être contourné, si une connexion biométrique est liée à une clé, ou si des données sensibles sont stockées correctement dans leur contexte. Pour cela, il faut un audit manuel, par exemple selon l’OWASP Mobile Top 10 (2024).

Mobian peut-il nous expliquer notre rapport MobSF ?

Oui. Si vous nous envoyez votre propre APK ou votre rapport MobSF, nous vous renvoyons une lecture d’une page : ce qui est réel, ce qui relève du bruit lié au type de build et ce qui pourrait être une fausse coche « sécurisé ». Nous ne le faisons qu’à la demande du propriétaire de l’app — nous n’analysons jamais l’application publique d’une entreprise sans y avoir été invités.

Ce que votre score MobSF vous dit vraiment