Sécurité du code source : du signal au risque validé | Ostorlab

Un scanner trouve une fonction dangereuse dans un dépôt.

C'est un signal.

Ce n'est pas encore la preuve qu'un attaquant peut l'atteindre, que des données non fiables y circulent, ou qu'un autre contrôle ne rend pas le chemin sûr. Ces questions déterminent si le code représente une véritable vulnérabilité, et si un développeur doit tout arrêter pour la corriger.

C'est le problème au cœur du test de sécurité du code source.

Trouver du code suspect est devenu facile. Le plus difficile est de séparer les vulnérabilités du bruit, d'expliquer le risque en contexte et de donner aux développeurs un correctif qu'ils peuvent réellement utiliser.

Qu'est-ce que le test de sécurité du code source ?

Le test de sécurité du code source examine le code d'une application à la recherche de faiblesses avant qu'elles n'atteignent la production. Il peut inclure le test statique de sécurité des applications (SAST), la détection de secrets, l'analyse des dépendances, la revue manuelle de code sécurisé et l'investigation assistée par l'IA.

Le NIST définit un analyseur de sécurité du code source comme un outil qui examine le code source et signale les faiblesses pouvant conduire à des vulnérabilités de sécurité. La distinction est importante : une faiblesse suspecte peut mener à une vulnérabilité, mais les deux ne sont pas automatiquement équivalentes.

Un bon processus de sécurité du code source doit répondre à quatre questions :

1. Où se trouve la faiblesse ?
2. Peut-elle être atteinte ou exploitée dans cette application ?
3. Quel impact pourrait-elle avoir ?
4. Quelle modification la corrigerait en toute sécurité ?

Si un outil ne répond qu'à la première question, il a trouvé du travail pour l'équipe sécurité, pas nécessairement une vulnérabilité.

La vulnérabilité peut exister avant l'exécution de l'application

Les problèmes de sécurité n'attendent pas un environnement de production.

Un secret peut déjà être codé en dur dans un fichier de configuration. Une dépendance vulnérable peut déjà être épinglée dans un manifeste. Une entrée contrôlée par l'utilisateur peut déjà atteindre une requête non sécurisée. Un contrôle d'autorisation peut déjà manquer sur une opération sensible.

Rien de tout cela n'a besoin d'une URL publique, d'un compte de test ou d'une application en cours d'exécution pour être vrai.

Le test du code source permet de détecter ces faiblesses tant que la modification concernée est encore fraîche. Les résultats peuvent pointer directement vers le fichier, la fonction et le chemin de code concernés, et le retour peut parvenir au développeur avant que le code ne devienne une infrastructure partagée et un risque de production.

C'est tout l'intérêt de tester tôt. Mais la détection précoce n'aide que si l'on peut se fier au résultat.

Comment le SAST traditionnel trouve les vulnérabilités

Le test statique de sécurité des applications analyse le code sans exécuter l'application. Selon le moteur, il peut :

• décomposer le code en tokens ou en arbre syntaxique abstrait ;
• identifier les entrées, les fonctions sensibles et les schémas non sécurisés connus ;
• suivre les flux de données et de contrôle entre les fonctions ;
• reconnaître les mécanismes d'assainissement et les contrôles de sécurité ;
• appliquer des règles ou des requêtes associées à des classes de vulnérabilités ;
• signaler le problème suspecté et le chemin qui l'a produit.

Prenons une injection SQL possible. Trouver une requête de base de données ne suffit pas. Le scanner doit déterminer si une entrée contrôlée par l'attaquant peut l'atteindre, si cette entrée est paramétrée ou assainie, et si le chemin est possible en pratique.

L'explication de GitHub sur l'architecture du SAST fait clairement cette distinction : trouver un sink sensible ne prouve pas à soi seul une vulnérabilité. La preuve pertinente est le chemin non sécurisé entre une source et ce sink.

C'est là que la simple recherche de motifs atteint sa limite.

Pourquoi les scanners de code source génèrent des faux positifs

Un faux positif est un problème signalé qui semble dangereux au scanner mais n'est pas une véritable vulnérabilité dans le contexte de l'application.

Cela arrive souvent parce que le scanner ne voit qu'une partie de l'histoire. Il peut manquer un mécanisme d'assainissement personnalisé situé dans un autre fichier, ne pas comprendre un contrôle du framework, suivre un chemin inatteignable ou prendre des données de test pour un secret de production.

Parmi les causes courantes :

• une analyse incomplète des flux de données ou de contrôle ;
• une validation personnalisée que le scanner ne reconnaît pas ;
• un contexte de framework, de dépendances ou de build manquant ;
• du code mort ou inatteignable ;
• des valeurs de test et des configurations d'exemple ;
• une sévérité fondée sur une faiblesse générique plutôt que sur l'impact réel.

L'OWASP cite les faux positifs, les faux négatifs et la difficulté de prouver qu'un problème est une véritable vulnérabilité parmi les limites de l'analyse statique.

Le coût ne se limite pas au temps passé à examiner une mauvaise alerte. Le bruit répété apprend aux développeurs à se méfier du scanner. Lorsqu'une véritable vulnérabilité apparaît, elle rejoint une file que tout le monde a appris à ignorer.

C'est pourquoi l'objectif ne doit pas être « trouver plus ». Il doit être « supprimer autant d'incertitude que possible avant de demander à un développeur d'agir ».

Du scan statique à l'investigation agentique

Le scan traditionnel suit généralement un chemin court :

Pattern or query → match → alert

La sécurité agentique du code source ajoute une couche d'investigation :

Signal → gather context → follow the path → challenge the hypothesis → assess impact → report or discard → propose a fix

Un agent peut partir d'une opération suspecte, inspecter les fonctions environnantes, suivre les imports et les chemins d'appel, chercher des contrôles ailleurs dans le dépôt, tester des explications alternatives et poursuivre l'investigation lorsque la réponse n'est pas claire.

La différence n'est pas que les règles disparaissent. L'analyse déterministe reste utile pour trouver des faiblesses candidates. Le rôle de l'agent est d'investiguer ce que signifie le signal initial dans cette application.

Il peut poser des questions qu'une règle unique laisse souvent sans réponse :

• L'entrée est-elle réellement contrôlée par l'attaquant ?
• La fonction concernée est-elle atteignable ?
• La validation est-elle appliquée dans un middleware partagé ?
• Le secret suspect est-il réel et utilisé, ou n'est-ce qu'une valeur d'exemple ?
• Une fonctionnalité vulnérable d'une dépendance est-elle réellement appelée ?
• Un contrôle d'autorisation s'applique-t-il plus tôt dans le flux ?
• Quelles conditions l'exploitation exigerait-elle ?
• L'impact probable justifie-t-il la sévérité attribuée ?

Le résultat ne doit pas être une alerte plus longue. Il doit être un ensemble plus restreint de résultats, avec une chaîne de preuves plus claire.

C'est l'approche qui sous-tend Ostorlab Source Code. Au lieu de s'arrêter à une correspondance suspecte, Ostorlab réunit le contexte du dépôt, le chemin concerné, la sévérité, l'exploitabilité, l'impact métier et les recommandations de remédiation. Ses agents de code source sont conçus pour creuser les chemins complexes et les failles de logique, puis renvoyer des résultats que les développeurs peuvent examiner et traiter.

Comment la validation réduit concrètement les faux positifs

Les scanners traditionnels signalent souvent chaque motif suspect et laissent à l'équipe sécurité le soin de déterminer quels résultats sont réels.

Ostorlab déplace cette investigation dans le scan lui-même. Les agents de code source suivent le chemin vulnérable, examinent les contrôles environnants, évaluent l'atteignabilité et l'exploitabilité, et écartent les signaux qui ne résistent pas à une analyse plus poussée.

Ce qui parvient au développeur est un ensemble de résultats beaucoup plus restreint, chacun accompagné du chemin concerné, de l'impact, du contexte justificatif et des recommandations de remédiation nécessaires pour agir. La validation réduit les faux positifs. Elle ne les élimine pas : chaque résultat porte donc toujours les preuves dont un relecteur a besoin pour le confirmer ou le rejeter rapidement.

C'est la différence entre générer plus d'alertes et trouver les vulnérabilités qui comptent.

Ce que le test de sécurité du code source peut voir, et ce qu'il ne peut pas voir

L'analyse du code source peut détecter des faiblesses telles que :

• des chemins d'injection SQL, NoSQL, de commandes et de templates ;
• des opérations de fichiers non sécurisées et des traversées de répertoires ;
• des schémas de cross-site scripting et de falsification de requête côté serveur ;
• des secrets codés en dur et une utilisation non sécurisée de la cryptographie ;
• une désérialisation non sécurisée ;
• l'utilisation de dépendances vulnérables ;
• une validation et des contrôles de sécurité manquants ;
• des faiblesses d'authentification et d'autorisation ;
• des transitions d'état non sécurisées et des contournements de workflow ;
• des failles de logique propres à l'application lorsque le contexte est suffisant.

Mais le code source n'est pas le système entier. L'analyse statique peut avoir du mal avec la configuration propre à la production, les services externes, les relations d'infrastructure, l'état à l'exécution ou les règles métier qui n'existent que dans la documentation ou dans la tête des gens.

C'est pourquoi le test du code source doit compléter les autres formes de test, et non les remplacer.

Méthode	Ce qu'elle voit le mieux	Ce qu'elle peut manquer
SAST	Les faiblesses dans le code source avant l'exécution	Le contexte d'exécution et d'environnement
DAST	Le comportement observable de l'extérieur dans une application en cours d'exécution	Les chemins internes qu'il ne peut pas atteindre ou observer
SCA	Les risques connus dans les dépendances tierces	Si la fonctionnalité vulnérable est réellement atteignable
Revue manuelle de code	L'architecture, l'intention, les contrôles personnalisés et la logique métier	Une couverture continue de chaque modification
Test agentique du code source	Le contexte à l'échelle du dépôt, la validation itérative et la remédiation	Le contexte qui n'existe ni dans le code ni autour

Les recommandations de l'OWASP sur la revue de code sécurisé considèrent de même l'analyse automatisée et la revue manuelle comme complémentaires : l'automatisation met en évidence les zones suspectes, tandis qu'une revue plus approfondie traite le contexte, l'architecture et la logique que les outils peuvent manquer.

L'analyse agentique peut-elle trouver des failles de logique métier ?

Les vulnérabilités de logique métier sont difficiles parce que le code peut être techniquement valide alors que le workflow ne l'est pas sur le plan de la sécurité.

Un utilisateur applique plusieurs fois la même remise. Un responsable approuve sa propre transaction. Un locataire accède à la ressource d'un autre locataire via un endpoint valide. Rien ne ressemble nécessairement à une fonction universellement dangereuse. La faille se situe dans la relation entre les rôles, les états et le comportement attendu.

L'analyse agentique peut améliorer la couverture en reconstituant les workflows, en comparant les contrôles entre des opérations liées et en raisonnant sur les transitions d'état et les frontières d'autorisation.

Mais « propulsé par l'IA » n'est pas une preuve en soi. Un résultat crédible doit montrer le chemin concerné, l'hypothèse violée, les conditions requises pour l'exploitation et l'impact probable.

Ostorlab applique explicitement cette analyse plus poussée aux vulnérabilités complexes et aux bugs de logique, notamment les lacunes d'autorisation, les transitions d'état non sécurisées et les contournements de workflow. La valeur ne tient pas à l'étiquette « agentique ». Elle tient au contexte produit par l'investigation.

Ce que doit contenir un résultat exploitable

Un développeur ne devrait pas avoir à refaire toute l'investigation du scanner avant de pouvoir commencer à corriger le problème.

Un résultat exploitable doit inclure :

• le dépôt, la révision, le fichier et l'emplacement dans le code concernés ;
• une description claire de la vulnérabilité ;
• le chemin de flux de données ou de contrôle pertinent ;
• l'entrée contrôlée par l'attaquant ou la frontière de confiance rompue ;
• le contrôle de sécurité manquant, contourné ou inefficace ;
• des préconditions et un impact réalistes ;
• des preuves expliquant pourquoi le résultat est considéré comme exploitable ;
• des recommandations de remédiation propres à l'application ;
• une modification de code proposée lorsqu'un correctif sûr peut être généré.

La sévérité seule n'est pas une explication. Une étiquette « critique » sans chemin crédible renvoie simplement l'investigation au développeur.

Ostorlab organise les résultats autour des chemins concernés, de l'exploitabilité, de l'impact, de la sévérité et de la priorité de remédiation. Les correctifs peuvent être renvoyés dans les pull requests, ce qui permet aux développeurs d'examiner la modification proposée à côté du code qui a introduit le risque.

Intégrer la sécurité du code source dans le workflow des développeurs

Le retour de sécurité perd de sa valeur lorsqu'il arrive longtemps après que le code a été fusionné et oublié.

Un workflow pratique combine :

• Le scan au niveau des modifications pour un retour rapide sur le code en cours de revue.
• Le scan complet du dépôt pour une couverture de base et les applications héritées.
• Des contrôles de version sur la révision exacte du code qui sera livrée.
• Une réévaluation planifiée à mesure que la base de code et la connaissance des menaces évoluent.
• Une visibilité centralisée pour que les équipes AppSec puissent suivre le risque sans obliger les développeurs à quitter leur workflow habituel pour chaque tâche.

Le workflow actuel d'Ostorlab pour le code source prend en charge GitHub, GitLab, Bitbucket, Azure DevOps, les dépôts Git standard et les envois de fichiers ZIP. Les équipes peuvent sélectionner une branche, un tag ou un commit à analyser, examiner le chemin vulnérable et les preuves associées, et renvoyer la remédiation dans la pull request.

L'objectif est simple : garder le résultat, le code et le correctif dans la même conversation.

Comment évaluer un outil de sécurité du code source

Une longue liste de fonctionnalités ne dit pas ce que l'on ressent en utilisant un scanner. Testez-le sur du code représentatif et mesurez le travail qu'il crée autant que les vulnérabilités qu'il trouve.

Posez les questions suivantes :

Les résultats sont-ils dignes de confiance ?

• Chaque résultat montre-t-il un chemin crédible et un contexte justificatif ?
• La sévérité reflète-t-elle l'atteignabilité et l'impact réels ?
• Combien de problèmes signalés survivent à une revue d'expert ?

Comprend-il votre base de code ?

• Prend-il en charge vos langages, vos frameworks, vos dépôts et vos systèmes de build ?
• Peut-il suivre des bibliothèques et des contrôles de sécurité personnalisés ?
• Peut-il raisonner au-delà de motifs syntaxiques isolés ?

Que se passe-t-il après le premier signal ?

• L'outil valide-t-il l'hypothèse ou se contente-t-il de lui attribuer un score ?
• Peut-il reconnaître les mécanismes d'assainissement, les contrôles d'autorisation et les chemins inatteignables ?
• Écarte-t-il les résultats non étayés avant qu'ils n'atteignent les développeurs ?

La remédiation est-elle utile ?

• Les recommandations traitent-elles la cause racine ?
• Le correctif proposé est-il spécifique à l'application et au framework ?
• Le développeur peut-il inspecter la modification avant de l'accepter ?

S'intègre-t-il au workflow de développement ?

• Les équipes peuvent-elles scanner la branche, le tag ou le commit exact en cours de revue ?
• Les résultats et les correctifs apparaissent-ils là où les développeurs travaillent déjà ?
• Le retour est-il assez rapide pour influencer la version ?

Pour la preuve de concept, incluez des vulnérabilités connues, de vrais problèmes déjà corrigés, des contrôles personnalisés et du code qui trompe fréquemment les scanners génériques. Suivez les résultats confirmés, les vulnérabilités manquées, le temps de tri, le temps de remédiation et l'acceptation par les développeurs des correctifs proposés.

Un plus grand nombre d'alertes ne prouve pas une meilleure couverture. Il peut seulement signifier que l'outil a transféré plus d'incertitude à votre équipe.

La sécurité du code source à l'ère des logiciels générés par l'IA

Les outils de codage par IA augmentent le volume et la vitesse des modifications logicielles. Les équipes de sécurité ne peuvent pas répondre en générant des alertes au même rythme accéléré.

Si la génération de code passe à l'échelle alors que chaque hypothèse de sécurité exige encore un tri manuel, le goulot d'étranglement se déplace simplement vers les équipes AppSec et d'ingénierie.

La sécurité du code source doit donc devenir plus investigative. Elle doit comprendre le contexte du dépôt, valider ce qui compte et amener la remédiation au point où un développeur peut l'examiner en toute sécurité.

La question pertinente n'est plus :

De combien de règles le scanner dispose-t-il ?

Elle est :

Quelle part d'incertitude supprime-t-il avant de demander à un humain d'agir ?

C'est le critère autour duquel Ostorlab Source Code est conçu : suivre le signal, comprendre le chemin, continuer à creuser quand la réponse n'est pas claire, et renvoyer le risque avec le contexte et le correctif nécessaires pour agir.

Découvrir Ostorlab Source Code