Une mise en production peut introduire une faille exploitable entre deux évaluations de sécurité planifiées. Le pentest IA continu aide les équipes à tester l'application en cours d'exécution au fil de ses modifications. Le résultat utile se traduit par des éléments exploitables par les développeurs, ainsi qu'un moyen de vérifier qu'un correctif déployé résout bien la vulnérabilité détectée.
Aikido Infinite intègre le pentest IA continu à votre processus de développement actuel. Ce guide détaille le parcours allant de l'évaluation initiale à la détection d'une faille, en passant par l'action du développeur et la demande de nouveau test. Vous pouvez conserver vos scanners de sécurité et votre processus de suivi des tickets actuels tout en évaluant ce flux de travail.
Commencez par une application délimitée et une évaluation initiale
Choisissez l'application et l'environnement que vous prévoyez de tester. Configurez son périmètre et ses accès, puis effectuez une évaluation initiale avec Aikido. Pour les tests continus, connectez les référentiels nécessaires pour identifier les modifications pertinentes, et vérifiez les autorisations actuelles ainsi que les prérequis de crédits dans la documentation de configuration.
Distinguez une évaluation complète initiale des tests ciblés ultérieurs. Un test restreint sur un comportement modifié ne remplace pas une évaluation complète de toute la surface de l'application.
Configurer le moment où les tests continus sont exécutés
Déterminez si les tests doivent suivre une branche de déploiement configurée ou un calendrier. Adaptez ce déclencheur à l'environnement accessible par l'Aikido , en tenant compte de tout délai nécessaire à la fin du déploiement.
L'objectif est de tester l'état de l'application que vous évaluez réellement. Un nouveau commit, une version déployée et un environnement de test accessible sont des événements liés, mais ils ne sont pas interchangeables. Voir pentest continu pour connaître les contrôles de configuration actuels.
Intégrez cette découverte dans le processus de travail du développeur
Un résultat pertinent fournit au développeur suffisamment d'informations pour comprendre le comportement concerné, reproduire le problème et évaluer une solution. La présentation générale du test d'intrusion sur Aikidoexplique les informations de validation et de résultats fournies par le produit.
Intégrez la gestion des mesures correctives au processus déjà utilisé par votre équipe. Par exemple, créez ou mettez à jour un ticket dans votre outil de suivi existant en y ajoutant un lien vers le résultat du test d’ Aikido , la version concernée, le responsable et les critères d’acceptation de la correction. Ce transfert peut se faire manuellement. Si vous utilisez une solution d’intégration, vérifiez son comportement face aux résultats des tests d’ avant de vous en servir pour la synchronisation ou la clôture des tickets.
Exemple de processus de réparation
L'exemple suivant illustre ce processus ; il ne s'agit ni d'une étude de cas client ni d'une démonstration de produit mesurée.
Imaginons une application web qui permet à un utilisateur authentifié d'accéder à une fiche appartenant à un autre compte. Un résultat de test d'intrusion identifie l'opération concernée et apporte la preuve d'une défaillance du contrôle d'accès.
Le développeur examine le contrôle d'autorisation et prépare une correction. L'équipe examine et teste cette modification dans le cadre de son processus habituel de pull request. Un correctif proposé est une correction potentielle ; le comportement de l'application doit encore être vérifié après le déploiement.
ÉtapeQui intervientQue faut-il consignerConstat confirméAikido fournit le constat ; l’équipe l’examine.Lien vers le constat, comportement de l’application concerné, preuves de reproductibilité et version testée.Responsabilité du développeurL’équipe attribue le ticket existant dans le système de suivi.Responsable et critères d’acceptation : l’action non autorisée doit échouer tandis que l’accès autorisé doit continuer de fonctionner.Correction : le développeur implémente et valide la modification. Pull request et version contenant la correction. Déploiement : l’équipe déploie dans l’environnement d’évaluation. Environnement et version déployée. Vérification : un utilisateur autorisé demande un nouveau test de la faille. Résultat du nouveau test et travaux de correction restants.
Vérifier la correction déployée
Déployez le correctif dans l'environnement de test avant de demander un nouveau test. Vérifiez le résultat avant de considérer le problème de sécurité comme résolu. Si le problème reste reproductible, poursuivez les mesures correctives et répétez la vérification après le prochain correctif.
Conservez les preuves des nouveaux tests associées à l'élément de travail. Un ticket de suivi des problèmes clôturé et un contrôle de sécurité réussi répondent à des questions différentes : l'un consigne l'état du workflow ; l'autre consigne ce qui s'est passé lors du test de l'application. Suivez les instructions relatives aux anomalies et aux nouveaux tests en fonction des actions en cours et des états des résultats.
Qu'est-ce qui peut rester en place ?
Vos outils de sécurité existants ( SAST, SCA et autres) peuvent continuer à fonctionner. Votre référentiel, votre processus de révision et votre outil de suivi peuvent rester les systèmes utilisés par vos développeurs pour coordonner les modifications. L'adoption des tests d'intrusion ne nécessite pas de transférer l'ensemble de votre infrastructure de sécurité vers Aikido.
Il reste encore des tâches de configuration à effectuer : accès à l'application, périmètre, référentiels pour les tests en continu, autorisations et configuration de l'utilisation. Vérifiez ces exigences pour le mode de test spécifique que vous choisissez.
Comparer les différents types de tests répétés
Une évaluation complète, un test ciblé après un changement et une nouvelle vérification d’un résultat connu ont des objectifs différents. Lorsque vous évaluez un produit « pentest continu », demandez-vous lequel de ces cas se présente, ce qui le déclenche et quelles informations il fournit.
Un nouveau test réussi traite la anomalie vérifiée dans l'environnement testé. Il ne garantit pas, à lui seul, une couverture de régression permanente pour chaque future version ni ne prouve que chaque vulnérabilité a été découverte.
Mener un projet pilote pratique
Choisissez une application et suivez une anomalie tout au long de votre processus de développement réel. Notez l'effort de configuration, les transferts manuels, la qualité des preuves et le résultat de la vérification de la correction. Si aucune anomalie n'est générée, n'en inventez pas pour compléter le scénario : utilisez un environnement de démonstration approuvé pour évaluer le flux de travail.
Commencez par la configuration du pentest Aikido, puis configurez le test continu une fois l'évaluation initiale et les prérequis en place.
