L’écart de sécurité entre Apple et Google se creuse alors que les chasseurs de bugs IA saturent les files d’attente

Les stratégies de sécurité d’Apple et Google sont entrées dans une nouvelle phase après que des chasseurs de bugs IA ont révélé une faiblesse dans le processus de réception des vulnérabilités d’Apple. Apple aurait limité les soumissions actives, les signalements générés par machine mettant à rude épreuve sa capacité de révision.

Le problème immédiat ne se limitait pas aux faux signalements. Des chercheurs de l’entreprise italienne de sécurité Bynario ont indiqué que leur flux de travail automatisé avait identifié une véritable faille d’autorisation dans macOS au milieu d’un volume bien plus important de signalements. L’entreprise a finalement validé une chaîne d’attaque capable de créer des fichiers avec des privilèges root.

Apple a corrigé la vulnérabilité en juillet 2026. Toutefois, cet épisode a mis en lumière un écart opérationnel plus large entre la découverte d’une faille et son évaluation par un expert humain de confiance. Google consacre depuis des années des efforts à bâtir cette couche de vérification autour de Project Zero et de son système d’IA, Big Sleep.

C’est le renversement central. L’IA devait aider les fournisseurs à examiner davantage de code, mais elle permet aussi aux chercheurs externes de générer des rapports plus vite que les fournisseurs ne peuvent les traiter. Le goulot d’étranglement s’est déplacé de la découverte vers la validation, la priorisation et le déploiement des correctifs.

Pour Apple, ce changement crée une pression qui dépasse un seul défaut de macOS. Son programme de sécurité doit distinguer les recherches utiles assistées par IA des soumissions plausibles mais incorrectes, sans bloquer les signalements légitimes. L’approche de Google offre un modèle, même si elle reste fortement dépendante d’une revue experte.

Une faille Mac corrigée a révélé un problème plus vaste de réception des signalements

Le changement important est que la découverte automatisée s’est heurtée à un processus de vulnérabilités conçu pour un volume de signalements humains.

Bynario a publié son compte rendu technique le 29 juillet, deux jours après la publication par Apple des mises à jour concernées. Les chercheurs ont identifié deux problèmes d’autorisation liés dans macOS Screen Sharing et les ont regroupés sous le CVE-2026-43760.

La faille touchait une ancienne voie d’authentification utilisée par Virtual Network Computing, ou VNC. VNC est un protocole qui permet à un utilisateur distant de voir et contrôler l’écran d’un autre ordinateur.

L’exploitation nécessitait plusieurs conditions. Screen Sharing ou Remote Management devait être activé. L’option de mot de passe VNC héritée devait également être configurée, et l’attaquant devait connaître ce mot de passe.

Ces exigences rendent la faille plus limitée qu’une attaque non authentifiée et sans clic. Elles n’en éliminent pas l’importance. Un mot de passe VNC était censé autoriser le contrôle de l’écran, pas l’accès privilégié au système de fichiers.

Les chercheurs ont constaté que macOS traitait différemment l’authentification native Apple et l’authentification VNC héritée. Une session native associait l’activité à un utilisateur macOS reconnu. La voie héritée ne fournissait pas la même identité utilisateur.

Les assistants de copie de fichiers conservaient l’autorité root lorsque cette identité manquait. Un utilisateur distant pouvait donc demander des fichiers protégés ou créer des fichiers contrôlés par l’attaquant dans des emplacements privilégiés.

Dans l’analyse de l’exploit macOS, Bynario a décrit le placement d’un fichier de politique dans un répertoire de configuration protégé. Ce fichier activait des commandes administratives sans mot de passe et permettait une démonstration d’exécution de commandes root à distance.

Les chercheurs ont testé ce comportement sur de récents systèmes Apple silicon avec System Integrity Protection activé. La faille ne contournait pas les protections mémoire d’Apple, car il s’agissait d’une erreur d’autorisation et non d’un exploit de corruption mémoire.

Cette distinction est importante. Les défenses modernes peuvent rendre les dépassements de tampon et les pointeurs falsifiés plus difficiles à exploiter. Elles ne peuvent pas empêcher un composant système légitime d’exécuter une opération autorisée sous une mauvaise identité.

L’avis d’Apple employait un langage plus mesuré, évoquant un possible accès à des données utilisateur sensibles. Bynario a soutenu que cette description ne reflétait pas pleinement l’impact de la création de fichiers privilégiés.

Les récits publics divergeaient également sur la gravité. L’avis d’Apple et l’évaluation des chercheurs appliquaient des scores et des hypothèses différents. Ce désaccord souligne pourquoi la validation exige davantage que l’acceptation d’une étiquette automatisée.

Apple a corrigé le problème dans macOS Tahoe 26.6 et Sonoma 14.8.8 le 27 juillet. La mise à jour de sécurité de l’entreprise crédite des chercheurs externes pour plusieurs vulnérabilités traitées dans cette version.

Pour les utilisateurs, la réponse pratique est simple. Installez la mise à jour macOS actuelle. Les organisations qui ne peuvent pas mettre à jour devraient désactiver l’option de mot de passe VNC héritée ou désactiver Screen Sharing lorsqu’il n’est pas nécessaire.

L’histoire plus large commence avant le correctif. Des informations indiquent que les chercheurs de Bynario avaient déjà soumis des dizaines de signalements sur plusieurs semaines. Un plafond de rapports actifs les a ensuite empêchés de soumettre immédiatement une autre vulnérabilité potentiellement grave.

Apple a ensuite contacté les chercheurs et examiné la faille. Cette action a contribué à produire un correctif, mais elle dépendait d’une exception au parcours normal de réception. Un programme de sécurité évolutif ne peut pas compter sur le fait que les chercheurs reçoivent une attention individuelle après qu’une file d’attente cesse d’accepter leur travail.

Pourquoi les chasseurs de bugs IA submergent la révision humaine

Les chasseurs de bugs IA modifient l’économie de la découverte plus vite qu’ils n’améliorent celle de la vérification.

La recherche traditionnelle de vulnérabilités coûte cher en temps humain. Un chercheur étudie une base de code, formule une hypothèse, la teste, élimine les fausses pistes et rédige un rapport reproductible.

L’IA peut accélérer certaines parties de ce processus. Un modèle peut rechercher des schémas suspects, comparer des chemins de code similaires, générer des cas de test et suggérer les endroits où des hypothèses d’autorisation pourraient échouer.

Cette échelle est utile lorsque le système produit des preuves. Elle devient coûteuse lorsqu’un agent transforme chaque schéma incertain en rapport affirmatif.

Une équipe de sécurité doit toujours reproduire le comportement, identifier les versions affectées, évaluer les conditions d’exploitation, attribuer la responsabilité et coordonner un correctif. Une explication soignée générée par un modèle ne réduit pas ces obligations.

Les propres directives de signalement d’Apple reflètent cette tension. Elles déconseillent les longues descriptions générées par IA et excluent les conclusions théoriques issues de l’IA qui ne disposent pas d’une validation adéquate.

Ces règles sont raisonnables. Les fournisseurs ont besoin de preuves reproductibles, pas de pages de raisonnement spéculatif. Pourtant, les limites de rapports constituent un contrôle brutal lorsqu’un chercheur soumet à la fois des pistes faibles et des conclusions à fort impact.

Le cas Bynario illustre la distinction entre le volume généré par IA et la recherche en sécurité assistée par IA. L’entreprise affirme que son système a révélé l’incohérence des identifiants, mais que des humains ont validé le résultat de bout en bout.

Cette validation incluait des contrôles négatifs. Sous authentification native, les opérations protégées échouaient avec les permissions ordinaires d’un utilisateur. Sous la voie héritée, des opérations similaires réussissaient avec l’autorité root.

Ce test différentiel est bien plus précieux qu’un score de confiance d’un modèle. Il établit que le résultat de sécurité change lorsqu’une voie d’authentification change.

La découverte a également résisté aux tests d’exploitation. Les chercheurs sont passés d’une différence inhabituelle de permissions à la création de fichiers privilégiés, puis à l’exécution de commandes. Chaque étape fournissait des preuves concrètes pour la suivante.

Un rapport de faible qualité manque souvent de cette chaîne. Il peut identifier du code suspect sans démontrer son accessibilité. Il peut décrire un plantage sans prouver son impact sur la sécurité, ou supposer qu’un attaquant contrôle des données qui restent internes.

Les modèles génératifs donnent à de tels rapports une apparence aboutie. Ils peuvent fournir des classifications de vulnérabilités, des scénarios d’attaque et des formulations de remédiation avant que l’affirmation sous-jacente ait été prouvée.

Cela crée une charge de travail asymétrique. Générer dix rapports plausibles peut demander moins de temps que réfuter soigneusement un seul d’entre eux. Le destinataire supporte l’essentiel du coût lorsque les personnes qui signalent ne valident pas leurs conclusions.

Les opérations de sécurité IA d’Apple font donc face à deux défis liés. L’entreprise a besoin de meilleurs contrôles de réception, mais aussi d’un parcours pour les chercheurs qui démontrent à répétition un travail fiable.

Les systèmes de réputation peuvent aider. Un historique de signalements validés, une preuve de concept complète, des étapes de reproduction déterministes et des données claires sur les versions affectées devraient accroître la priorité d’un rapport.

Le triage assisté par machine peut également comparer les soumissions, identifier les doublons et tester les affirmations de base. Toutefois, utiliser un autre modèle pour juger une sortie de modèle non étayée peut amplifier des erreurs communes.

L’approche la plus solide combine filtrage automatisé et réfutation. Au lieu de demander si un rapport semble crédible, un système de triage devrait tester activement les conditions qui le rendraient faux.

Cela exige l’accès à des builds, des journaux, des états de configuration et des environnements de test contrôlés. Cela exige aussi des réviseurs humains qui comprennent la frontière que le rapport prétend franchir.

Le défi de réception continuera de croître parce que le coût de génération des conclusions baisse continuellement. Les fournisseurs qui traitent chaque soumission de la même manière se noieront dans le bruit. Ceux qui bloquent l’automatisation sans discernement passeront à côté de véritables failles.

Les approches d’Apple et Google divergent au niveau de la vérification

La différence entre Apple et Google concerne moins l’accès aux modèles d’IA que la manière dont chaque entreprise organise la vérification experte.

Google a lancé Project Zero en 2014 en tant que groupe de recherche spécialisé dans les vulnérabilités graves. Cette expérience institutionnelle a donné à Google un processus existant pour sélectionner des cibles, reproduire les découvertes et divulguer les défauts.

Big Sleep associe cette expérience de sécurité à la recherche sur les modèles menée par Google DeepMind. Le système est conçu pour étudier des logiciels, tester des hypothèses et produire des rapports qui passent par une revue experte.

En août 2025, Google a déclaré que Big Sleep avait trouvé et reproduit 20 vulnérabilités dans des projets open source. Les logiciels concernés incluaient, selon les informations publiées, des composants largement utilisés pour le traitement des médias et des images.

Google n’a pas immédiatement divulgué les détails techniques, car les correctifs étaient encore en attente. Un porte-parole a également indiqué qu’un expert humain avait examiné chaque problème avant son signalement, bien que le système ait trouvé et reproduit les vulnérabilités de manière autonome.

Ce contrôle humain est l’élément crucial des résultats de Big Sleep. Il ne rend pas le processus entièrement autonome, mais il protège les mainteneurs contre la réception de sorties brutes de modèle.

Google Big Sleep opère également au sein d’une équipe qui comprend les délais de divulgation et les dépendances en aval. Ses découvertes ne sont pas simplement déposées dans des files d’attente de fournisseurs non liés, sans contexte.

Le système de divulgation de Project Zero crée un autre avantage. Google suit la date de signalement d’un problème, l’expiration d’un délai et le moment où les utilisateurs concernés reçoivent effectivement un correctif.

Sa politique de divulgation utilise un délai standard tout en reconnaissant l’écart entre un correctif en amont et son installation sur l’appareil d’un utilisateur final. Big Sleep participe au même cadre.

Apple dispose de ressources importantes en ingénierie de sécurité. L’entreprise maintient des fonctions de renforcement de plateforme, un programme d’appareils de recherche en sécurité et un processus public de bug bounty.

Le programme de bounty d’Apple demande également aux chercheurs des descriptions techniques et des preuves de concept. Ses nouveaux indicateurs de cible fournissent une méthode objective pour démontrer que certaines conditions d’exploitation ont été atteintes.

Ces investissements ne signifient pas qu’Apple ignore la recherche sur les vulnérabilités. La lacune mise en lumière ici concerne le débit de traitement et la confiance lorsque des soumissions automatisées arrivent de l’extérieur de son organisation.

Google contrôle à la fois le système d’IA et l’équipe d’experts qui examine ses résultats. Apple reçoit des rapports de nombreux chercheurs indépendants utilisant des modèles, des prompts, des outils et des normes de validation différents.

Il s’agit d’un problème de réception plus difficile. Apple ne peut pas supposer qu’un agent de modèle externe suit les méthodes de Project Zero ni qu’un rapporteur a testé l’affirmation avant de la soumettre.

Apple reste toutefois responsable de la conception de son canal de signalement. Si des chercheurs dont les travaux sont validés ne peuvent pas soumettre un problème sérieux parce que des rapports antérieurs restent ouverts, le système optimise la taille de la file d’attente plutôt que l’impact sur la sécurité.

Un programme mature a besoin de plusieurs voies. Une piste automatisée peu documentée peut rejoindre une file de faible priorité, tandis qu’un exploit démontré avec des preuves reproductibles reçoit une attention humaine immédiate.

Apple doit également trouver un moyen d’augmenter la capacité accordée aux rapporteurs fiables sans encourager les soumissions en masse. Un quota plus élevé devrait découler d’une qualité vérifiée, et non d’une simple demande d’espace supplémentaire.

L’approche de Google n’est pas à l’abri des erreurs. Son système repose sur une supervision coûteuse d’experts, et les premiers résultats publics n’ont pas établi dans quelle mesure Big Sleep est performant sur des plateformes propriétaires.

On ignore également combien de candidats le système a écartés avant d’aboutir aux découvertes rapportées. Sans ce dénominateur, les observateurs extérieurs ne peuvent pas calculer son taux de faux positifs ni son coût d’examen.

La leçon utile est plus circonscrite. La découverte assistée par l’IA fonctionne mieux lorsque les modèles s’inscrivent dans une chaîne de preuves supervisée par des experts responsables. Le défi d’Apple consiste à reproduire cette norme dans un programme ouvert de signalement externe.

Le compromis de sécurité oppose rapidité et signal

Davantage de découvertes n’améliorent la sécurité que si les fournisseurs peuvent les convertir en correctifs vérifiés avant que des attaquants n’emploient les mêmes outils.

La découverte de vulnérabilités assistée par l’IA met sous pression les deux côtés d’un processus de divulgation. Les chercheurs peuvent examiner davantage de code, tandis que les acteurs malveillants peuvent parcourir les mêmes logiciels à la recherche d’erreurs exploitables.

Google a déclaré en mai 2026 avoir perturbé une opération criminelle impliquant la découverte d’un zero-day assistée par IA. L’entreprise n’a pas révélé le produit concerné ni le modèle que les attaquants auraient utilisé.

Selon le récit de l’attaque par IA, la vulnérabilité pouvait contourner l’authentification à deux facteurs d’un produit d’administration système. Google a indiqué avoir averti le fournisseur et les forces de l’ordre avant que des dommages ne surviennent.

Les détails restent limités ; ce cas ne permet donc pas d’établir quelle part du travail le modèle a accomplie. Il montre toutefois pourquoi les délais de traitement des rapports présentent désormais un risque accru.

Une faille en attente dans une file n’est pas statique. Une autre équipe de recherche, un groupe criminel ou un opérateur soutenu par un État peut la découvrir indépendamment. Une recherche plus rapide augmente la probabilité de cette collision.

Apple ne peut pas résoudre le problème en acceptant chaque soumission automatisée. Cela absorberait le temps des examinateurs et retarderait les rapports les plus importants.

L’entreprise ne peut pas non plus résoudre le problème en réprimant la recherche assistée par machine. La faille de Bynario montre qu’un défaut d’autorisation valide peut émerger d’un flux de travail automatisé et résister à des tests humains rigoureux.

Le bon compromis est une rapidité sélective. Les rapports étayés par des preuves solides doivent être rapidement escaladés, tandis que les affirmations incomplètes doivent passer par des vérifications automatisées moins coûteuses avant d’atteindre les ingénieurs seniors.

Un rapport devrait établir la build concernée, la configuration requise, les prérequis de l’attaquant, le résultat observé, le résultat attendu et un test reproductible. L’impact sur la sécurité doit découler des preuves, non de spéculations générées par un modèle.

Pour un problème de privilèges, cela peut impliquer d’enregistrer l’identité du processus lors d’une opération contrôlée. Pour un défaut mémoire, cela peut inclure une trace de sanitizer et un reproducteur minimal.

Les fournisseurs peuvent publier des modèles de soumission structurés autour de ces exigences. Des preuves lisibles par machine aideraient le tri automatisé à tester un rapport sans considérer une prose fluide comme une preuve.

Les chercheurs ont également une responsabilité. Envoyer des dizaines de découvertes incertaines transfère le coût de validation au fournisseur et affaiblit la confiance dans chaque soumission ultérieure.

Les outils de sécurité basés sur l’IA devraient comporter une étape de réfutation avant de générer un rapport. L’agent devrait rechercher les contrôles d’accès qu’il a négligés, tester des builds corrigées et non corrigées, et vérifier que l’attaquant présumé contrôle chaque entrée nécessaire.

Un examen humain doit rester obligatoire pour les affirmations à fort impact. Cet examinateur devrait reproduire le problème de façon indépendante et vérifier si l’environnement de test a introduit une condition artificielle.

Cette exigence ne réduit pas la valeur de l’IA. Elle oriente le modèle vers les travaux d’investigation répétitifs où l’échelle est utile, tout en maintenant la responsabilité auprès d’un chercheur identifié.

Le public doit également éviter de considérer le nombre de vulnérabilités comme un classement. Vingt défauts acceptés ne sont pas automatiquement plus importants qu’une seule chaîne d’attaque vérifiée.

Les volumes peuvent récompenser l’analyse superficielle et les rapports en double. De meilleures mesures incluent le délai de validation, la gravité confirmée, la livraison du correctif, la charge liée aux faux positifs et l’adoption du correctif par les utilisateurs.

Le plafond de rapports d’Apple ne traite qu’une de ces mesures. Il peut réduire le nombre de soumissions ouvertes, mais ne prouve pas que les rapports les plus dangereux parviennent rapidement au bon ingénieur.

Un meilleur triage comptera davantage que des primes plus élevées

Le prochain avantage concurrentiel en matière de sécurité de l’IA sera une chaîne fiable reliant la découverte par machine à la correction vérifiée par des humains.

Apple offre déjà des incitations pour la recherche avancée, mais l’argent seul ne peut pas réparer un processus de réception engorgé. Un chercheur doit avoir l’assurance qu’une découverte solidement étayée sera lue, reproduite et correctement orientée.

La première amélioration devrait être une priorisation fondée sur les preuves. Une preuve de concept fonctionnelle, des prérequis clairs et un impact validé devraient primer sur l’ordre de soumission.

La deuxième devrait être un accès progressif. Les chercheurs dont les travaux précédents ont abouti à des correctifs confirmés pourraient bénéficier d’autorisations plus larges pour les rapports actifs et d’une escalade technique directe.

La troisième devrait être un statut transparent. De longues périodes sans retour utile encouragent les messages en double, les divulgations prématurées et l’incertitude quant au fait qu’un rapport ait atteint la bonne équipe.

Le concept de signalement de cible d’Apple va dans ce sens. Des signaux objectifs peuvent réduire les différends sur l’exploitabilité et récompenser les chercheurs qui démontrent un contrôle significatif.

Les indicateurs ne couvrent toutefois que des catégories de comportement définies. Une nouvelle faille logique peut ne pas correspondre à une cible présélectionnée, en particulier lorsque la vulnérabilité traverse plusieurs composants de confiance.

CVE-2026-43760 illustre cette difficulté. Chaque opération de copie de fichier se comportait normalement prise isolément. L’erreur résultait de l’interaction entre l’identité d’authentification, les privilèges de l’assistant et l’accès au système de fichiers.

Ce type de bogue nécessite un raisonnement sémantique. L’analyse sémantique examine si le comportement du système correspond à son intention de sécurité, et pas seulement si le code plante.

Les modèles d’IA peuvent aider, car ils peuvent suivre les relations entre les fonctions et les composants. Ils peuvent aussi inventer des relations inexistantes, ce qui rend la vérification exécutable indispensable.

Une plateforme de triage robuste préserverait le raisonnement du modèle tout en le séparant des preuves. Les examinateurs pourraient voir quelles affirmations sont observées, déduites ou encore non testées.

Les équipes pourraient appliquer le même principe à leurs dossiers internes d’ingénierie. Une base de connaissances techniques consultable aide à relier les défauts passés, les hypothèses de conception, les résultats de test et les responsables, sans traiter les résumés générés comme des sources faisant autorité.

Ce contexte compte lorsqu’un nouveau rapport ressemble à un problème antérieur. Le système devrait identifier les composants et correctifs associés tout en conservant l’accès aux artefacts d’origine.

Apple pourrait également publier des données agrégées sur le traitement sans exposer les vulnérabilités. Parmi les mesures utiles figurent le délai médian de validation, le taux de doublons, les demandes d’informations supplémentaires et la part des rapports fermés faute d’éléments probants.

Une telle publication clarifierait si les soumissions issues de l’IA sont principalement du bruit, ou si la capacité n’a tout simplement pas suivi le rythme de la recherche valide.

Google devrait être soumis à la même norme de transparence. Mettre en avant des découvertes réussies sans publier les coûts d’examen donne une image incomplète de la recherche automatisée en sécurité.

La comparaison ne devrait pas devenir une affirmation selon laquelle Google a résolu la sécurité de l’IA. L’examen humain de Big Sleep est une force, mais il prouve également que la recherche autonome de vulnérabilités nécessite encore un contrôle expert.

Apple peut rattraper son retard sans copier la structure organisationnelle de Google. L’entreprise a besoin d’un système de signalement qui rende les preuves démontrées rares et précieuses, même lorsque les découvertes proposées deviennent abondantes.

Trois signaux montreront si Apple rattrape son retard

Les prochains mois révéleront si Apple considère cet épisode comme un problème temporaire de file d’attente ou comme un changement durable de la recherche en sécurité.

Le premier signal sera une modification des contrôles de soumission d’Apple. Une mise à jour significative distinguerait les chercheurs validés et les exploits reproductibles des découvertes automatisées non testées.

Une simple hausse du plafond ne suffirait pas. Elle augmenterait le volume sans améliorer l’ordre dans lequel les rapports reçoivent de l’attention.

Une escalade fondée sur les preuves renforcerait l’idée qu’Apple s’adapte. Une dépendance continue à des démarches individuelles indiquerait que le processus reste fragile.

Le deuxième signal sera le traitement par Apple des découvertes assistées par IA dans de futurs avis de sécurité. Une attribution claire, des descriptions précises de l’impact et des détails cohérents sur la correction montreraient que l’automatisation ne réduit pas la valeur d’un rapport.

Surveillez les désaccords comme celui entourant CVE-2026-43760. Des évaluations de gravité différentes sont normales, mais des écarts inexpliqués entre un avis et un exploit démontré compliquent la priorisation pour les défenseurs.

Une description plus complète n’exige pas de publier des détails exploitables comme arme. Les fournisseurs peuvent expliquer les prérequis et l’impact tout en retenant les instructions susceptibles d’aider les attaquants.

Le troisième signal sera la manière dont Google Big Sleep et des systèmes similaires se comportent au-delà de leur première série publique. Des failles logiques confirmées, de faibles taux de faux positifs et une coordination efficace des correctifs renforceraient le modèle de Google.

Un déluge de rapports faibles l’affaiblirait. Il en irait de même de résultats dépendant de niveaux non documentés de travail humain tout en étant présentés comme une découverte autonome.

Ces signaux importent aux acheteurs d’entreprise, car la gestion des vulnérabilités affecte chaque parc d’appareils. Une fonctionnalité de sécurité a une valeur limitée lorsqu’un rapport valide ne peut pas parvenir à l’examen ou qu’un correctif publié reste non installé.

Les développeurs devraient également se soucier de l’évolution de la norme de preuve. L’IA peut aider à inspecter le code, mais les mainteneurs exigeront de plus en plus des tests reproductibles avant de consacrer du temps à un rapport.

Les chercheurs en sécurité font face au même choix. Ils peuvent utiliser des modèles pour augmenter le volume de soumissions, ou s’en servir pour construire des expériences plus solides qui rendent chaque soumission plus difficile à écarter.

La concurrence entre Apple et Google n’est donc pas une course à la génération du plus grand nombre d’affirmations de vulnérabilités. C’est une course visant à transformer une sortie machine incertaine en action défensive fiable.

Cette course a déjà atteint les équipes logicielles ordinaires. Examinez vos règles de réception des vulnérabilités, définissez les preuves nécessaires à une escalade et vérifiez si un rapport à fort impact peut contourner les limites ordinaires de la file d’attente. Si ce n’est pas le cas, la prochaine découverte valide assistée par IA pourrait révéler le processus avant de révéler le code.