Guardian360
Démarrer l’essai gratuitDevenir partenaire
← Tous les articles

Opinion

Yellow Teaming : buzzword ou point de rupture ?

Par Jan Martijn Broekhof ·

Je n’avais jamais entendu le terme « Yellow Team » avant de lire un récent article de Dark Reading sur l’IA et la sécurité. À la fin du deuxième paragraphe, j’ai pris conscience de quelque chose d’un peu inconfortable : Guardian360 en est discrètement une depuis des années, et personne, moi compris, ne s’est jamais donné la peine de l’appeler ainsi.

Pendant longtemps, cela n’a guère eu d’importance. Construire les outils qu’utilisent les Red et Blue Teams était considéré comme un travail de commodité : nécessaire, peu prestigieux, rarement le sujet d’une conférence. Les attaquants avaient le drame. Les défenseurs avaient le mérite de tenir la ligne. Les personnes qui construisaient les plateformes sous les deux avaient une ligne dans le budget. L’IA change ce calcul, et il vaut la peine de comprendre pourquoi, et ce que cela signifie pour la manière dont Guardian360 travaille avec ses partenaires.

Que sont exactement les Red, Blue et Yellow Teams, et où se situe DevSecOps ?

Le vocabulaire des couleurs en cybersécurité est plus ancien que la plupart des gens ne le pensent. Red Team désigne les personnes qui simulent des attaques : testeurs d’intrusion, hackers éthiques, celles et ceux payés pour s’introduire avant que quelqu’un aux intentions plus mauvaises ne le fasse. Blue Team désigne les défenseurs : les analystes et ingénieurs qui détectent ces attaques, y répondent et s’en remettent. La Yellow Team se situe sous les deux. C’est le groupe qui conçoit, construit et maintient les systèmes, applications et outils sur lesquels et avec lesquels Red et Blue opèrent réellement.

Cette distinction a été proposée pour la première fois à Black Hat en 2017, lorsqu’une roue chromatique a été introduite pour cartographier les différentes fonctions du travail de sécurité au-delà du cadre familier rouge contre bleu, comme les chercheurs en sécurité de Retest Security l’ont depuis documenté dans leur propre histoire du framework. Le jaune a été défini comme les bâtisseurs : architectes, développeurs et ingénieurs responsables de systèmes sûrs dès la conception, plutôt que les personnes qui les attaquent ou les défendent après coup.

DevSecOps n’est pas une couleur distincte sur cette roue. C’est la pratique que les Yellow Teams emploient pour faire leur travail : intégrer la sécurité dans le pipeline de développement lui-même, afin que les vulnérabilités soient détectées au moment de leur création plutôt que découvertes plus tard par Red ou nettoyées plus tard par Blue. DevSecOps est la méthode. La Yellow Team est le groupe de personnes qui l’applique.

Simplement du DevSecOps avec une nouvelle couche de peinture ?

Un sceptique légitime m’arrêterait ici. Si une Yellow Team n’est que les personnes qui font du DevSecOps, qu’est-ce qui a réellement changé ? Les organisations ont des ingénieurs en développement sécurisé depuis dix ans. Les appeler « jaunes » ne rend pas le travail nouveau.

Ce scepticisme mérite une réponse honnête, et la réponse honnête est la suivante : en soi, l’étiquette serait effectivement du vieux vin dans une nouvelle bouteille. Ce qui rend ce moment différent, ce n’est pas le nom, c’est l’ampleur de ce pour quoi les Yellow Teams doivent désormais construire. Les modèles d’IA de pointe comme Claude Mythos et GPT-5.5 peuvent trouver et enchaîner des vulnérabilités logicielles plus vite que presque n’importe quelle équipe humaine, et les organisations commencent tout juste à comprendre comment orienter cette capacité dans une direction utile plutôt que chaotique. Cette orientation, il s’avère, est un travail de Yellow Team, et cela ne ressemble en rien à la rédaction de listes de contrôle pour la revue de code sécurisée.

Pourquoi l’IA vient de changer l’équation pour les bâtisseurs

Selon le reportage de Dark Reading, les ingénieurs d’entreprises telles que Cisco, Microsoft, Cloudflare et Netskope passent désormais leur temps à construire des « harnesses » : des constructions logicielles qui définissent exactement ce qu’un modèle d’IA est autorisé à faire, quelles autorisations il possède et quels garde-fous il doit respecter pendant qu’il traque les vulnérabilités. Un « harness » semble restrictif, mais c’est l’inverse. Sans lui, les Red Teams sont submergées par les faux positifs et par des constats dépourvus de contexte métier ; avec lui, le même modèle d’IA devient réellement utile tant pour la simulation d’attaque que pour la défense.

Le CISO de Netskope, James Robinson, décrit exactement ce schéma : le modèle a signalé un point de terminaison interne comme non authentifié, techniquement vrai, mais il a manqué le fait que ce point de terminaison n’était de toute façon jamais accessible depuis le web. Passer de la sortie brute de l’IA à quelque chose auquel un analyste humain ferait confiance a exigé un effort d’ingénierie dédié, pas un prompt.

L’effet d’entraînement est que Blue et Yellow sont rapprochées comme jamais auparavant. Comme le dit Levi Bolourie de Zscaler, les blue teams qui n’utilisent pas l’IA pour l’analyse risquent d’être submergées par le volume considérable de signaux que le red teaming assisté par l’IA produit désormais, et les deux disciplines devront de ce fait s’intégrer bien plus étroitement. Les Yellow Teams ne sont plus une fonction de support se tenant discrètement derrière Red et Blue. Elles sont la raison pour laquelle chacune de ces équipes parvient encore à suivre.

D’un system of record à un system of action

Une deuxième évolution parcourt tout cela, et elle dépasse largement la sécurité. Pendant deux décennies, la plupart des logiciels d’entreprise ont été ce que l’on appelle aujourd’hui un « system of record » : un endroit qui stocke ce qui s’est passé. Votre CRM enregistre qu’un client a appelé. Votre plateforme d’analyse enregistre qu’une vulnérabilité existe. Utile, nécessaire et entièrement passif.

Un « system of action » fait quelque chose de différent. Au lieu de seulement stocker ce qui s’est passé, il utilise cette information pour décider ce qui devrait se passer ensuite, et de plus en plus, pour le faire. La propre étude de Grammarly sur la productivité au travail a révélé que 77 pour cent des professionnels se sentent submergés par le volume considérable d’informations qu’ils doivent traiter, et que 83 pour cent affirment manquer des outils pour réellement agir sur ce qu’ils savent. C’est précisément cet écart entre disposer de données et en faire quelque chose d’utile qu’un « system of action » est censé combler.

J’aime y penser comme à la différence entre un phare traditionnel et un phare capable d’orienter son propre faisceau. Un phare traditionnel est un pur « system of record » : il marque une position fixe et connue, et il revient au capitaine du navire de lire la lumière, d’évaluer la distance et de choisir le cap. Il ne s’ajuste pas au navire qui se trouve devant lui. Imaginez maintenant un phare capable de suivre un navire qui approche et de rediriger activement son faisceau pour avertir ce navire précis, à ce moment précis, du danger le plus proche de lui. Le capitaine gouverne toujours le navire. Mais le phare a cessé d’être un repère statique pour devenir un participant actif à la sécurité de ce navire.

Nous remettions autrefois une carte aux partenaires. Désormais, nous voulons guider l’itinéraire.

Une brève note de positionnement avant d’aller plus loin : Guardian360 est un éditeur de logiciels indépendant. Nous développons la plateforme Lighthouse : analyse continue, recommandations de conformité, inventaire des actifs, évaluation du risque métier et technique. Nous n’exploitons pas de Security Operations Centre, nous ne réalisons pas de tests d’intrusion manuels ni de réponse à incident, et nous ne vendons pas directement aux clients. Ce travail revient à nos partenaires, et il en a toujours été ainsi.

Pendant des années, ce que nous remettions aux partenaires était, en substance, une carte. Lighthouse montrait où se trouvait le risque, ce qui nécessitait de l’attention et, grosso modo, à quel point c’était urgent. Trouver le meilleur itinéraire depuis cette information jusqu’à un environnement client donné était laissé entièrement au partenaire. C’était le bon modèle lorsque la carte elle-même était la partie difficile à construire. C’est un modèle plus compliqué maintenant que l’IA peut aider à générer non seulement la carte, mais aussi une prochaine étape réellement utile.

Au cours des prochains mois, nous voulons que Lighthouse s’éloigne davantage de la carte pour se rapprocher de la navigation : non seulement montrer aux partenaires où se situe le risque, mais proposer le meilleur itinéraire pour le traiter, encore et encore, à mesure que les circonstances évoluent. C’est ce que construire un « system of action » signifie concrètement pour nous.

Il vaut la peine d’être honnête à ce sujet, car cela soulève une question évidente pour chaque partenaire qui lit ces lignes : si la plateforme se met à proposer l’itinéraire, que reste-t-il au conducteur ? Notre réponse est que le partenaire garde le contrôle de la voiture. Nous ne construisons pas des outils pour écarter les partenaires du travail ; nous les construisons pour leur ôter des mains les parties du travail qui ne nécessitent pas de jugement humain, afin que les décisions qui exigent bel et bien un humain reçoivent davantage de leur attention, et non moins. Les partenaires deviennent, en somme, la Blue Team de demain : celles et ceux qui décident, agissent et assument la responsabilité du résultat, épaulés par une Yellow Team à qui l’on demande enfin de faire plus que maintenir les lumières allumées.

Alors, quelle équipe avez-vous discrètement été ?

Guardian360 était une Yellow Team bien avant que le terme n’existe, et je soupçonne qu’un bon nombre d’organisations qui lisent ceci peuvent en dire autant d’au moins une partie de leur propre activité. La question sur laquelle il vaut la peine de s’arrêter n’est pas de savoir si le Yellow Teaming est une véritable catégorie ou un simple changement d’étiquette. C’est de savoir laquelle de vos équipes accomplit ce travail en arrière-plan depuis des années, sans nom et sous-estimée, et si vous êtes prêts à lui donner les outils, et l’attention, que ce moment exige réellement.

Sources