Analyse à chaque commit : ce qui se passe entre le push et la correction terminée
Trois profondeurs de vérification, une personne entre les deux, et une correction qui ne s'arrête pas à un ticket : comment une analyse de code à chaque commit passe du contrôle immédiat à l'évaluation en contexte puis au passage sur toute la base de code, comment les faux positifs sont écartés, et pourquoi renouveler une clé ou mettre à jour une bibliothèque est la véritable mesure.
Ce qui se passe vraiment à chaque commit
La formule évoque un outil qui radiographierait toute l'application à chaque push. Aucun analyseur ne travaille ainsi, et aucun ne le devrait, parce qu'une analyse complète par commit prend des minutes et bloque les développeurs. Ce qui se passe réellement est échelonné. La modification elle-même est vérifiée immédiatement. Son effet sur le reste du code est évalué en contexte. Et la base de code dans son ensemble est parcourue à son propre rythme, pour que ce qui n'est pas né dans ce commit soit trouvé aussi.
Cet échelonnement fait la différence entre un analyseur que les développeurs subissent et un analyseur qu'ils ne remarquent plus au bout d'une semaine. Notre page consacrée à la sécurité du code nomme les trois niveaux ; voici ce qui se passe dans chacun.
Profondeur un : le contrôle immédiat
Le push arrive, et en quelques secondes les lignes modifiées sont vérifiées sur trois points : mots de passe, clés et jetons codés en dur ; fonctions et schémas non sécurisés connus ; appels dangereux comme des commandes système non contrôlées. Le résultat est là avant que le code ne poursuive. Qui valide un secret l'apprend tant que son éditeur est encore ouvert, pas à la prochaine date d'audit.
Le contrôle immédiat est volontairement étroit. Il connaît des schémas, pas des intentions. Ce qu'il signale n'est pas encore un résultat, mais un candidat.
Profondeur deux : la vérification en contexte
La modification n'est plus regardée isolément, mais dans le contexte de la base de code. Le nouvel appel mène-t-il vraiment à un endroit où des entrées arrivent sans contrôle ? Le contrôle d'accès manquant se trouve-t-il à un point accessible de l'extérieur, ou dans un module utilitaire interne ? C'est ici qu'un candidat devient un risque réel, ou non. L'évaluation suit le risque réel, pas le nombre de résultats.
C'est à ce niveau que se produit ce que les analyseurs ne peuvent pas faire seuls : une personne voit chaque candidat avant qu'il ne devienne un résultat et écarte ce qui n'est pas exploitable dans le cas concret. Il en sort une priorité claire au lieu d'une liste sans fin. Qui a déjà reçu 400 alertes dont 380 ne signifiaient rien sait pourquoi cette étape compte le plus.
Profondeur trois : le passage complet
Le troisième niveau ne travaille pas par commit mais sur toute la base de code, parce que beaucoup de ce qui est dangereux n'est pas né dans le commit courant. Chaque dépendance est comparée aux vulnérabilités connues. L'historique du dépôt est parcouru à la recherche d'anciens secrets, car une clé validée il y a deux ans puis supprimée est toujours dans l'historique. Et la configuration est vérifiée pour ses réglages par défaut non sécurisés.
C'est de ce niveau que viennent les résultats qui figurent le plus souvent en tête du premier constat après 48 heures : pas l'erreur d'hier, mais la bibliothèque d'il y a dix-huit mois.
Pourquoi la correction est la mesure, pas l'alerte
Un rapport plein de résultats que personne ne traite n'est pas une protection. Le déroulement ne se termine donc pas par une notification. Pour un résultat critique, corriger signifie : le secret est renouvelé, pas seulement retiré du code, car une clé publiée une fois reste valable tant qu'elle n'est pas invalidée. La bibliothèque vulnérable est mise à jour. Le schéma dangereux est neutralisé. Et chacune de ces mesures est documentée avec le résultat et la date.
Qu'un secret renouvelé soit la seule vraie correction, nous l'avons détaillé dans notre article sur les secrets codés en dur. Pour les dépendances, le même principe vaut : tant que l'ancienne version tourne, le résultat n'est pas clos, quel que soit le nombre de fois où il a été signalé.
Le chemin pour y arriver
Le jour 0, les dépôts sont connectés et l'existant est analysé une première fois. Après 48 heures, le premier constat est là, trié selon ce qui est réel et critique. La première semaine, on nettoie. Ensuite, les trois profondeurs s'appliquent à chaque commit. Le point d'entrée est l'analyse de code gratuite, sans engagement et dans votre propre environnement sur demande.
Questions fréquentes
L'analyse ralentit-elle les développeurs ?
Le contrôle immédiat rend son résultat en quelques secondes et ne regarde que la modification. Les vérifications plus lourdes tournent en contexte et sur la base de code sans retenir le push. C'est précisément pour cela que les trois niveaux sont séparés.
Qui décide si un résultat est réel ?
Une personne, à la profondeur deux. L'analyseur fournit des candidats ; l'évaluation dans le contexte de la base de code et le classement selon le risque réel ont lieu avant qu'un résultat ne vous parvienne. Les faux positifs y sont écartés.
Et si un résultat critique arrive la nuit ?
Les résultats critiques sont traités immédiatement et nous vous signalons ce qui est déjà réglé, dans vos propres canaux. La réaction aux résultats critiques est inférieure à 15 minutes, comme décrit sur notre page consacrée à la sécurité du code.