Checkmarx propose des solutions qui sont le fruit d’une maturation de plus de 16 ans d’expérience dans le domaine de la sécurisation des applications.

Un des axes de l’évolution des outils est de les intégrer au cœur de l’écosystème des développeurs de manière à ce que la sécurisation des applications allège le travail des développeurs au lieu de l’alourdir.

Nous allons illustrer un processus classique d’identification de faille via l’analyse statique du code et voir le cheminement de cette faille, à partir de son identification jusqu’à sa correction. A cet effet, nous allons considérer un développeur travaillant sur un projet en Java. Ce projet est maintenu dans un dépôt de code source via GitHub, et le développeur utilise IntelliJ pour coder.

Considérons un développeur qui code la fonctionnalité de Login de la nouvelle application sur laquelle son équipe travaille. Une fois le code écrit, il effectue un Commit & Push sur la branche version-3 du projet afin de le proposer.

Figure 1 Vue IDE IntelliJ

Dans Github, une Pull Request est alors générée afin d’affecter (merger) la branche master avec cette modification.

Figure 2 Pull Request

C’est à ce moment qu’un scan Checkmarx est lancé de manière automatique. Les résultats de ce scan apparaissent dans Github, via une décoration de la Pull Request. On remarque ici que des failles de sécurité sont détectées, notamment 2 horribles injections SQL.

Figure 3 Décoration Checkmarx de la Pull Request

A partir de Github, un hyperlien permet d’ouvrir le projet dans le GUI Checkmarx afin de regarder ces failles de plus près.

Figure 4 Vue Projets dans Checkmarx

Figure 5 Vue d'un vecteur d'attaque d'injection SQL dans Checkmarx

Dans cette vue, il est possible de simuler le parcours dans le code d’une donnée potentiellement malveillante pouvant générer l’injection SQL. En cliquant sur chacun des éléments du vecteur d’attaque (à gauche dans l’image ci-dessus), on peut retracer le parcours de cette donnée potentiellement malveillante, étape par étape, jusqu’à l’atteinte de la ressource critique (la base de données, pour une injection SQL). Ainsi, dans Checkmarx, une faille n’est pas un concept abstrait, le développeur peut la visualiser ligne par ligne dans son code, ce qui en facilite sa compréhension ainsi que sa correction.  Il est à noter aussi que Checkmarx aide le développeur à optimiser les corrections de plusieurs failles d’un même type en proposant dans la mesure du possible ce qu’on appelle un Best Fix Location, c’est-à-dire un point dans le code qui si on y affecte une correction, pourra éliminer un maximum de failles avec un minimum d’efforts.

A ce stade, Si la solution CodeBashing de Checkmarx est installée et que le développeur ne sait pas comment corriger la faille, il peut accéder directement à un tutoriel d’auto-formation contextuel lui permettant d’apprendre en 5 à 8 minutes à corriger ce type de faille dans le langage de programmation qu’il utilise. Ce scénario permet au développeur de « se mettre dans la tête » d’un attaquant dans la première partie du tutoriel afin de comprendre comment la faille de sécurité peut être exploitée. Le tutoriel expose ensuite la vulnérabilité au niveau du code pour enfin expliquer au développeur comment corriger la faille dans son langage de prédilection.

Figure 6 Vue CodeBashing

Il est à noter que Checkmarx propose au sein d’IntelliJ une vue permettant au développeur de parcourir le vecteur d’attaque directement dans l’IDE, ainsi le développeur peut consulter les résultats d’analyse Checkmarx directement dans son environnement de travail.

Figure 7 Vecteur d'attaque dans l'IDE

Le développeur peut maintenant corriger son code dans l’IDE et pousser cette correction dans Github.

Figure 8 Correction de la faille dans l'IDE

Une Pull Request est régénérée dans Github, entraînant le lancement automatique d’une nouvelle analyse statique Checkmarx, dont les résultats sont affichés dans Github.

Cette fois ci il n’y a plus de vulnérabilité grave, la Pull Request peut donc être mergée dans la branche master.

Figure 9 Décoration de la Pull Request avec le résultat du scan Checkmarx

Toutefois des issues Github ont été générées pour les vulnérabilités résiduelles (non-graves, dans cet exemple) afin de faciliter le suivi du traitement de ces failles.

Figure 10 Issues Github générées à partir des failles de sécurité détectées

L’exemple détaillé dans cet article peut être appliqué à une multitude d’autres outils s’intégrant avec Checkmarx ainsi qu’à d’autres scénarios (code open-source, attaques de supply chain, analyse dynamique, code d’infrastructure, etc).

Serge Ingber  (France, DACH and BeNeLux SE Manager - Checkmarx)