®Sécurité offensive / Tests d'intrusion logiciels et SaaS
Des mises en production rapides nécessitent un contrôle de sécurité qui comprend votre application. OTOKO® analyse les produits SaaS, les API, les applications exploitées sur PaaS et les logiciels legacy développés au fil des ans. L'accent est mis sur les impacts réellement atteignables : données d'autres locataires, actions non autorisées, logique métier détournée et limites entre rôles utilisateurs. Des constats reproductibles donnent à votre équipe de développement une base pour la correction.
Nos services en détail
Analyse, intégration et transfert documenté
Ce que vous confiez à OTOKO®
Les lots de travail sont dérivés de votre situation de départ. Votre équipe connaît le périmètre convenu, la contribution nécessaire et les résultats attendus lors du transfert.
Nous définissons ensemble les processus métier importants et les rôles de test. Nous examinons ensuite si une fonction peut être utilisée au-delà des limites prévues. Les contrôles automatisés sont complétés par une analyse manuelle de l'application.
Constats évalués avec impact métier et preuve vérifiable.
L'attribution des locataires, les accès aux objets et les fonctions privilégiées sont contrôlés dans le périmètre autorisé. Un jeu de test dédié permet d'évaluer les impacts sans avoir à utiliser les données d'autres clients pour la preuve.
Contrôle documenté des limites de rôles et de locataires convenues.
Pour les applications PaaS, nous examinons les paramètres et interfaces dont vous êtes responsable. Pour les systèmes legacy, les limites d'exploitation connues et les dépendances sont intégrées à la planification du test. Les plateformes tierces restent hors périmètre tant qu'aucune autorisation n'a été accordée.
Périmètre de test délimité avec des méthodes adaptées sur les plans technique et opérationnel.
Les constats sont priorisés et discutés avec votre équipe de développement. Le retest convenu vérifie si la cause concrète a été corrigée dans la nouvelle version. Les résultats sont rapportés au périmètre et au moment effectivement contrôlés.
Rapport technique, synthèse pour la direction et résultats de retest documentés.
Planification et mise en œuvre
Un produit SaaS ne se limite pas à des points de terminaison accessibles publiquement. Différents rôles, invitations, exports, tâches en arrière-plan et fonctions d'administration forment ensemble la logique métier. Avant le test, nous clarifions donc quels processus nécessitent une protection particulière et quelles limites l'application doit faire respecter. Cette perspective complète les contrôles techniques classiques. Une fonction peut répondre de manière formellement correcte tout en autorisant une action qui n'est pas prévue pour la personne connectée ou son locataire.
Sur cette base, nous convenons d'un périmètre de test. Les volets black box, grey box ou white box sont choisis selon l'objectif et les informations disponibles. Lorsque le code source ou la documentation d'architecture est fourni, les observations peuvent être interprétées de manière plus précise. Le contrôle se concentre sur l'application autorisée et utilise les comptes et données convenus. Un constat issu d'un outil n'est pas retenu comme vulnérabilité confirmée sans évaluation ; l'impact et les conditions requises doivent être compréhensibles pour votre équipe.
Pour le SaaS et le PaaS, la limite de responsabilité est déterminante. Le contrôle de votre application ou de votre configuration n'autorise pas automatiquement à attaquer l'infrastructure d'un exploitant de plateforme. Les objectifs, les méthodes autorisées et les autorisations nécessaires sont consignés conjointement. Les API et les intégrations sont contrôlées au regard du périmètre de données et d'autorisations prévu. Nous vérifions en particulier que les différents rôles et locataires restent séparés de manière fiable dans les parcours applicatifs réels.
Les logiciels legacy nécessitent souvent une approche différente. La documentation peut être incomplète, les environnements de test ne reflètent que partiellement l'environnement de production et certains composants sont sensibles à la charge. Ces conditions doivent être prises en compte dans la planification avant le début du test. Nous convenons des fenêtres de test, des interlocuteurs joignables et des critères d'interruption. Lorsqu'un contrôle ne peut pas être mené de manière responsable, cette limite est rendue visible dans le résultat. On sait ainsi clairement ce que le test permet d'affirmer et où une investigation supplémentaire serait nécessaire.
Un rapport doit permettre une décision et aider l'équipe de développement à corriger. Un constat confirmé décrit donc la version concernée, les conditions requises, la preuve convenue et l'impact possible. La direction et les équipes techniques ont besoin d'un niveau de détail différent. La priorisation tient compte du contexte applicatif, plutôt que de produire seulement une longue liste de signalements de même poids. Les preuves sont limitées au strict nécessaire et partagées avec les interlocuteurs autorisés par des canaux convenus.
La correction est discutée avec votre équipe ; un retest convenu évalue la modification concrète. Un constat corrigé ne signifie toutefois pas automatiquement que l'ensemble de l'application est exempt de vulnérabilités. De nouvelles versions et des changements de configuration peuvent modifier la situation de départ. Sur demande, il est possible d'en faire un contrôle régulier des changements importants. Pour des objectifs adaptés et clairement délimités, Result as a Service peut également être convenu : la rémunération dépend alors du résultat défini au préalable et démontré.
Scénario de projet illustratif
Deux locataires de test distincts représentent les utilisateurs standard et l'administration. Avant la mise en production, les processus métier convenus et les limites d'autorisation sont examinés. L'équipe reçoit des preuves priorisées et vérifie les corrections lors du retest, sans que des données d'autres clients soient nécessaires pour la démonstration.
Avant de démarrer
Oui. Les applications legacy sont intégrées à la planification avec leurs limites d'exploitation, les environnements de test disponibles et leurs dépendances. Les contrôles impossibles à réaliser sont signalés comme limitation dans le rapport.
Les scanners facilitent le travail. La logique métier, les rôles et le contexte applicatif réel nécessitent toutefois une évaluation par des spécialistes et un contrôle manuel ciblé.
Pour les projets adaptés, une preuve de résultat définie par écrit peut être convenue avec un montant fixe. Sans cette preuve, la rémunération au résultat convenue pour le pentest n'est pas due. Les détails figurent sur la page Result as a Service.
Non. La conclusion porte sur le périmètre convenu, la version contrôlée et la période concernée. L'absence de preuve ne constitue pas une garantie de sécurité générale.
Services complémentaires
Tests d'intrusion logiciels et SaaS avec OTOKO®
Indiquez les systèmes concernés et l'objectif de votre demande. Lors du premier entretien, nous délimitons ensemble le périmètre, les conditions préalables et les prochaines étapes.
Discuter de Tests d'intrusion logiciels et SaaS
