Comment sécuriser une application SaaS ?

Vous connaissez sûrement cette situation. Votre pipeline CI/CD est vert, aucun incident cette nuit, votre SDLC est outillé depuis des années. Et pourtant, quelque part dans l'entreprise, une équipe produit a ouvert une API pour un partenaire sans en informer la sécurité. Un environnement de démo monté pour un prospect il y a trois semaines est toujours en ligne. Un stagiaire a créé un sous-domaine de test l'an dernier, personne ne s'en souvient. Ce sont des situations banales, que vivent la plupart des éditeurs de logiciels, et aucune n'est une faille de code : c'est votre surface d'attaque réelle, et elle change sans que vous en soyez informé.

Un modèle software as a service vend un accès continu à des données sensibles, mises à jour plusieurs fois par semaine. Votre sécurité des applications ne peut donc pas se limiter à un audit annuel. Entre deux contrôles, des failles de sécurité ou des accès non autorisés peuvent s'installer, faute de mise en place rigoureuse des pratiques de sécurité au quotidien. Vos clients vous auditent déjà, et NIS2, DORA et le Cyber Resilience Act transforment cet écart en obligation de conformité réglementaire.

En bref

• La sécurité du code (SAST, SCA, DAST) ne couvre pas ce que l'organisation expose réellement : démos, APIs, configurations cloud, sous-domaines oubliés.

• Vos clients, NIS2, DORA et le CRA transforment la protection des données en obligation de preuve.

• Le pentest annuel ne suit ni votre rythme de release ni ces exigences. La réponse : un modèle continu combinant EASM et pentest hybride.

• L'approche change selon votre échelle : 10, 100 ou 500 applications ne se pilotent pas pareil.

• Un plan à 90 jours, indépendant de tout fournisseur, clôt cet article.

Pour un éditeur, le produit vendu est aussi, mécaniquement, sa surface d'attaque. Une faille exploitée touche potentiellement les données de tous vos clients d'un coup, et une fuite de données ne se répare pas avec un correctif : elle abîme la confiance sur laquelle repose le modèle SaaS.

Vos clients vous auditent avant de signer : questionnaires de sécurité, exigences de pentest, certifications ISO 27001 ou SOC 2. Prouver un bon niveau de sécurité est devenu une condition de vente. Votre rythme de release dépasse aussi votre rythme d'audit : les équipes « elite » déploient plusieurs fois par jour (rapport 2024 Accelerate State of DevOps, Google Cloud), quand un pentest annuel photographie un produit qui aura connu des dizaines de releases avant l'audit suivant.

Ce triple enjeu (données clients, exigence contractuelle, rythme de release) pose une question simple : qui, dans votre organisation, est responsable de tout ça ?

Cette responsabilité est souvent répartie sans être explicite. Dans un éditeur mature, elle ressemble à ceci :

• Les développeurs corrigent le code dans leur périmètre.

• Les équipes DevOps gèrent les configurations cloud, IAM et pipelines, là où naissent souvent les expositions accidentelles.

• Les product owners arbitrent entre roadmap et remédiation.

• Le RSSI gouverne : visibilité, priorisation, preuve de maîtrise.

• La direction porte la responsabilité finale. Les articles 20 et 32 de NIS2 rendent les organes de direction personnellement responsables, avec un risque d'interdiction d'exercer en cas de manquement grave.

Cette répartition ne suffit pas si personne ne sait précisément ce que la réglementation exige.

Quatre sources de pression s'empilent, de la plus immédiate à la plus structurelle :

• Vos clients, la plus rapide à se faire sentir : un questionnaire de sécurité peut bloquer une signature.

• NIS2 et DORA, en cascade : si vous vendez à une banque ou un opérateur essentiel, la conformité de votre client devient votre cahier des charges.

• Le Cyber Resilience Act (CRA), qui vise les éditeurs directement : sécurité dès la conception, mise à jour régulière des correctifs, notification à l'ENISA sous 24 heures des failles activement exploitées. Calendrier : entrée en vigueur le 10 décembre 2024, signalement dès le 11 septembre 2026, conformité complète le 11 décembre 2027. Sanctions jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

• Le RGPD : l'article 32 impose des mesures de sécurité pour garantir la sécurité des données personnelles, sanctions CNIL jusqu'à 4 % du chiffre d'affaires mondial.

Face à ces obligations, encore faut-il savoir quels outils vous avez déjà, et lesquels vous manquent.

Aucun outil ne couvre seul toute la chaîne.

Les six premières lignes appartiennent au SDLC. Leurs angles morts convergent vers un même point, ce qui est exposé sans être déclaré : c'est ce que couvrent l'EASM et le pentest continu.

Une démarche de protection continue tient en six réflexes, du repérage des actifs jusqu'à la preuve présentée aux auditeurs.

1. Cartographier ce qui est exposé. On ne protège pas ce qu'on ne voit pas. Par exemple, une équipe produit ouvre une API pour un partenaire un vendredi soir : sans cartographie continue, elle peut rester invisible des équipes sécurité pendant des mois.

2. Détecter avec précision, pas avec du volume. Un scanner classique peut générer des milliers d'alertes sans rapport avec un vrai risque. Mieux vaut filtrer avant de transmettre.

3. Valider l'exploitabilité avant d'agir. Une vulnérabilité théorique n'est pas un risque tant qu'elle n'est pas démontrée exploitable. Le pentest hybride combine automatisation et expertise humaine sur les scénarios complexes.

4. Prioriser par le risque réel. Croiser exposition, exploitabilité et criticité métier donne une priorité plus juste qu'un score CVSS.

5. Remédier vite, dans les outils déjà utilisés. Un finding qui arrive par email finit dans une boîte de réception, pas dans un sprint.

6. Réagir en heures face aux menaces émergentes. Quand une CVE critique comme CVE-2025-53770 (SharePoint, juillet 2025) sort, la question est de savoir si elle vous concerne, en quasi temps réel.

Pris ensemble, ces six réflexes permettent de voir un actif exposé le jour même, plutôt que de le découvrir des semaines plus tard. Encore faut-il les adapter à la taille de l'organisation : ils ne se pilotent pas de la même façon chez un éditeur de dix applications et chez un groupe qui en gère cinq cents.

Le nombre d'applications et de services exposés change la nature du problème, pas seulement sa taille.

• Une dizaine d'applications. Le pentest ponctuel semble suffire, et c'est le stade le plus trompeur : la surface non déclarée existe déjà. Le réflexe est de mettre en place une première vue externe de ce qu'un attaquant voit réellement.

• Une centaine d'applications. Le pentest manuel généralisé devient impossible. L'EASM devient le socle, la priorisation par le risque devient obligatoire.

• Cinq cents applications et plus. Le sujet n'est plus l'outillage mais la gouvernance : segmentation par entité, délégation produit, métriques pour la direction.

Ce qui est exposé sur Internet est testé en permanence par des attaquants automatisés, contrairement à ce qui reste interne. Appliquer la même politique aux deux est l'erreur classique.

Patrowl est une plateforme française de gestion continue de l'exposition aux menaces (CTEM) : elle sécurise ce que votre organisation expose réellement, là où SAST, SCA et DAST sécurisent ce que vous écrivez.

Quatre éléments à regarder de près, sans que ce soit forcément unique sur le marché :

• Qualification humaine des findings : chaque résultat est vérifié avant transmission.

• Test de logique métier applicative : contrôles d'accès non autorisés, isolation entre tenants.

• Pricing forfaitaire par périmètre : pas de facturation à la vulnérabilité.

• Hébergement en France (OVH Gravelines).

Quatre questions à vous poser cette semaine :

1. Combien d'actifs sont exposés sur Internet à votre nom aujourd'hui ?

2. Sur les vulnérabilités remontées le mois dernier, combien étaient réellement exploitables ?

3. Combien de temps entre la publication d'une CVE critique et le moment où vous avez su si vous étiez concerné ?

4. Pouvez-vous produire une attestation de surveillance continue des 12 derniers mois ?

Jours 1 à 30 : voir. Consolidez l'inventaire officiel, obtenez une vue externe indépendante à partir de votre nom de domaine, interrogez les équipes produit sur ce qui a été créé ce trimestre. Livrable : une liste d'actifs classée en connus, oubliés et inconnus.

Jours 31 à 60 : filtrer. Appliquez un filtrage manuel sur un échantillon de vulnérabilités : combien sont réellement exposées et démontrées exploitables ? Définissez un critère de priorisation avec vos équipes de développement.

Jours 61 à 90 : industrialiser. Câblez la remontée des findings validés dans vos outils existants, et suivez trois métriques : actifs exposés, part couverte par un test récent, délai de remédiation sur le critique exposé. Au-delà de 100 applications, ce plan est difficile à tenir sans EASM ni pentest continu.

Vous n'avez rien fait de mal ce matin-là. Votre pipeline était vert, et pourtant votre exposition réelle avait changé sans que vous le sachiez. C'est le cas de la plupart des éditeurs : un écart grandit entre ce que le SDLC contrôle et ce que l'entreprise expose réellement, que la réglementation transforme en obligation de conformité réglementaire. Protéger ce que vous développez se joue dans votre capacité à voir, valider, prioriser et prouver en continu, pas dans un audit annuel qui arrive toujours trop tard.

Sources externes vérifiées

• Rapport DORA 2024, Accelerate State of DevOps, Google Cloud, octobre 2024.

• Directive (UE) 2022/2555 (NIS2), articles 20 et 32. Références : cyber.gouv.fr, EUR-Lex.

• Règlement (UE) 2024/2847 (Cyber Resilience Act), entré en vigueur le 10 décembre 2024. FAQ officielle : cyber.gouv.fr, digital-strategy.ec.europa.eu

• Règlement (UE) 2016/679 (RGPD), article 32.

• Règlement (UE) 2022/2554 (DORA).

• CVE-2025-53770, vulnérabilité critique SharePoint (« ToolShell »), documentée par Microsoft Security Response Center et la CISA, juillet 2025.

Données internes à Patrowl, à confirmer avant publication

Expérience client Patrowl, à valider avant mise en ligne : part d'actifs inconnus lors des onboardings, taux de faux positifs sur un scanner classique, réduction de MTTR chez un client cité, délai d'alerte des clients concernés par CVE-2025-53770.