Les règles de bug bounty d’Apple et Google convergent alors que le spam lié à l’IA impose un durcissement

Les règles de bug bounty d’Apple et Google sont arrivées au même point de bascule après un afflux sans précédent de rapports de vulnérabilités générés par l’IA et de faible qualité.

Apple aurait plafonné le nombre de rapports actifs que les chercheurs peuvent gérer via son portail de sécurité. L’entreprise a également instauré un délai d’attente après que les chercheurs ont atteint cette limite. Ses règles publiques prévoient désormais des pauses plus longues et une exclusion définitive en cas de soumissions invalides répétées.

La comparaison est importante, car Google avait déjà durci son programme de vulnérabilités open source après ce qu’il a qualifié de forte hausse de rapports générés par l’IA. GitHub a suivi avec des exigences de participation plus élevées et une structure de récompense remaniée. Ensemble, ces mesures montrent que la découverte automatisée de vulnérabilités s’est heurtée à une ressource rare : l’examen humain par des experts.

Le conflit ne se résume pas à l’IA contre les chercheurs en sécurité. Il oppose une découverte à grande échelle à des preuves vérifiables. Un système d’IA peut proposer des centaines de faiblesses plausibles, mais une équipe de sécurité doit encore reproduire chaque affirmation et déterminer si des attaquants peuvent l’exploiter.

Ce déséquilibre crée un renversement inconfortable. L’IA était censée aider les défenseurs à repérer plus vite les failles graves. Des soumissions non validées peuvent au contraire ensevelir les rapports qui méritent une attention immédiate.

Apple a instauré de nouvelles barrières autour de sa file de sécurité

La réponse d’Apple cible le volume de soumissions, mais ses règles publiques portent plus directement sur la validation et le comportement des chercheurs.

Selon le rapport original sur le quota, Apple a instauré un plafond pour les rapports de vulnérabilités actifs ainsi qu’une période de refroidissement pour les chercheurs qui l’atteignent. Les chercheurs pourraient demander une limite plus élevée lorsque leur travail justifie une capacité supplémentaire.

Cette restriction opérationnelle est distincte des sanctions publiées dans les directives actuelles d’Apple Security Bounty. Apple indique pouvoir suspendre le traitement des rapports pendant 180 jours lorsqu’un chercheur soumet de manière répétée des conclusions non admissibles.

Plus de deux périodes de suspension peuvent entraîner une exclusion définitive du programme. Pendant une suspension, les chercheurs perdent généralement l’accès aux récompenses, à la mention dans les avis de sécurité et au traitement habituel des rapports.

Apple prévoit des exceptions limitées. Un chercheur suspendu peut toujours soumettre des preuves capturant un Target Flag applicable ou incluant une virtualisation entièrement empaquetée d’iOS ou de macOS.

Un Target Flag est une valeur protégée placée dans un système Apple afin de prouver qu’un exploit a atteint une frontière de sécurité précise. Il transforme une affirmation théorique en preuve mesurable.

Les directives de signalement d’Apple identifient désormais plusieurs qualités nécessaires à une soumission valide. Un rapport doit comporter une explication précise, un exploit fonctionnel ou une preuve de concept fiable, ainsi que des étapes de reproduction concises.

L’entreprise demande explicitement aux chercheurs d’éviter les descriptions longues générées par des outils d’IA. Elle classe également comme non admissibles les conclusions théoriques produites par l’IA sans validation appropriée.

Ces dispositions n’interdisent pas la recherche assistée par l’IA. Elles tracent une frontière entre l’utilisation de l’IA au cours d’une enquête et le transfert dans la file d’Apple d’une sortie non testée d’un modèle d’IA.

Les conditions du programme distinctes d’Apple renforcent cette distinction. L’entreprise peut mettre fin à la participation après des spams répétés, de fausses affirmations ou des soumissions assistées par l’IA non examinées.

Cette combinaison offre à Apple plusieurs niveaux d’application. Un quota sur le portail limite le volume simultané. Une suspension de 180 jours traite les comportements répétitifs de faible qualité. L’exclusion définitive reste possible pour les chercheurs qui ne s’améliorent pas.

Cette distinction est importante, car les quotas seuls ne peuvent pas identifier la qualité. Un chercheur rigoureux peut avoir plusieurs conclusions légitimes en cours d’examen actif. Un spammeur peut soumettre moins de rapports qui mobilisent malgré tout de nombreuses heures.

Apple permet donc aux preuves plus solides de servir d’exception. Une exploitation fiable, un comportement reproductible et la confirmation de la cible peuvent faire passer un rapport au-delà des contrôles de volume.

Le changement resserre également ce qui compte comme une découverte de vulnérabilité utile. Trouver du code suspect ne suffit plus. Les chercheurs doivent expliquer comment un attaquant atteint ce code et quel contrôle, quelles données ou quels privilèges il obtient.

Cette norme est familière aux chasseurs de bugs expérimentés. Ce qui a changé, c’est la nécessité de l’énoncer directement en réponse au volume généré par l’IA.

Pourquoi la réponse d’Apple et Google arrive maintenant

Le durcissement d’Apple et Google reflète une asymétrie économique : les machines produisent à faible coût des affirmations de sécurité, tandis que les ingénieurs doivent les invalider une par une.

Les modèles génératifs peuvent analyser du code, décrire des schémas dangereux, rédiger des scénarios d’attaque et mettre en forme des rapports d’apparence professionnelle. Aucune de ces capacités ne démontre qu’une vulnérabilité fonctionne dans une configuration de produit prise en charge.

Un modèle peut identifier un dépassement de tampon dans du code inaccessible. Il peut mal comprendre une frontière d’autorisation ou inventer une fonction inexistante. Il peut aussi exagérer l’impact d’un défaut logiciel courant.

Chaque affirmation peut néanmoins paraître crédible au premier regard. Les ingénieurs en sécurité doivent examiner le code concerné, configurer un environnement de test, reproduire le comportement et évaluer l’exposition réelle.

Google a décrit exactement ce problème lorsqu’il a modifié son Open Source Software Vulnerability Reward Program en mars 2026. L’entreprise a déclaré avoir connu, pendant plusieurs semaines, une hausse massive de rapports générés par l’IA.

Google a observé des conditions de déclenchement hallucinées, un impact de sécurité négligeable et des conclusions portant sur des chemins de code inaccessibles. Sa mise à jour des règles OSS a par conséquent exigé des preuves plus solides pour certaines parties du programme.

Selon le niveau du dépôt, les preuves acceptables peuvent inclure une reproduction OSS-Fuzz ou un correctif fusionné. OSS-Fuzz est le service de fuzzing continu de Google pour les logiciels open source.

Google a ensuite supprimé les récompenses monétaires et la reconnaissance publique pour certaines vulnérabilités de produits de niveau inférieur et d’autres problèmes de sécurité. Ce changement a modifié la structure des incitations, et pas seulement le format des rapports.

Apple a emprunté une voie opérationnelle différente. Son plafond rapporté contrôle le nombre de dossiers actifs associés à un chercheur. Sa politique écrite prévoit des suspensions lorsque les rapports répétés restent théoriques ou invalides.

Les deux approches introduisent de la friction avant que les ressources limitées de triage ne disparaissent. Aucune ne suppose qu’une prose soignée équivaut à une vulnérabilité vérifiée.

Le mot « slop » peut masquer le véritable mécanisme. Le problème n’est pas qu’une phrase ait été écrite par l’IA. Le problème est que la génération automatisée supprime le coût naturel qui limitait autrefois les rapports spéculatifs.

Avant l’IA générative, élaborer une soumission de vulnérabilité convaincante exigeait un travail manuel considérable. Un chercheur devait normalement examiner une cible, déclencher un comportement inattendu et documenter des résultats reproductibles.

L’IA réduit le coût de production du document sans nécessairement réduire le coût de production des preuves. Elle crée ainsi davantage de rapports dont l’apparence dépasse la substance technique.

Une récompense peut amplifier ce comportement. Lorsqu’une seule soumission acceptée peut donner droit à une récompense, les systèmes automatisés peuvent générer de nombreuses tentatives spéculatives.

Le soumettant paie peu pour chaque affirmation supplémentaire. L’organisation qui reçoit les rapports paie un coût d’examen par un expert à chaque fois.

Il s’agit d’un problème classique de file d’attente. Si les arrivées invalides augmentent plus vite que la capacité d’examen, les cas légitimes attendent plus longtemps, quelle que soit leur qualité.

Ajouter davantage d’examinateurs ne constitue qu’une réponse partielle. Les ingénieurs expérimentés en sécurité produit sont difficiles à recruter, et le travail de triage entre en concurrence avec la correction, l’analyse des menaces et la réponse aux incidents.

Le triage automatisé peut aider à prioriser les rapports, mais il introduit une autre couche de vérification. Un classificateur peut écarter un rapport atypique qui décrit maladroitement un exploit authentique.

La réponse d’Apple et Google traite donc la validation humaine comme le point de contrôle essentiel. L’IA peut aider à la découverte, mais une personne reste responsable de prouver l’affirmation avant la soumission.

Le véritable compromis oppose l’accès au signal

Des filtres plus stricts peuvent protéger les équipes de sécurité, mais ils peuvent aussi désavantager les nouveaux chercheurs et retarder des conclusions inhabituelles.

Les programmes ouverts de bug bounty élargissent la portée défensive d’une entreprise. Des chercheurs indépendants testent des configurations, des composants et des chemins d’attaque que les équipes internes peuvent négliger.

Cette ouverture fonctionne parce que la participation ne nécessite ni emploi, ni statut institutionnel, ni relation existante avec le fournisseur. Un chercheur disposant d’une seule conclusion solide peut rejoindre la même file qu’une entreprise de sécurité établie.

Les limites de soumission modifient cet équilibre. Elles préservent la capacité d’examen, mais rendent également l’accès conditionnel à la qualité antérieure des rapports ou au quota disponible.

Le risque devient plus clair lorsque plusieurs conclusions légitimes arrivent simultanément. Une équipe de recherche auditant une grande plateforme peut identifier de nombreuses vulnérabilités liées lors d’un même projet concentré.

Si des dossiers antérieurs restent ouverts, l’équipe peut atteindre la limite de rapports actifs même lorsque ses nouvelles preuves sont solides. Demander une augmentation offre un recours possible, mais la décision reste entre les mains de l’opérateur du programme.

Apple a une raison légitime de protéger sa file. Son programme de sécurité couvre des produits et des services accessibles au public utilisés sur un vaste parc d’appareils.

L’entreprise indique que seul le premier rapport complet et exploitable est admissible à une récompense. Cette règle rend la soumission rapide importante lorsque plusieurs chercheurs enquêtent sur la même faiblesse.

Un quota peut donc créer une course involontaire. Les chercheurs peuvent privilégier le rapport le plus susceptible de recevoir une récompense plutôt que le problème ayant l’impact le plus élevé pour les utilisateurs.

Apple cherche à contrer cette pression en mettant l’accent sur des preuves complètes. Un rapport précipité sans reproduction fiable reste non admissible, même s’il arrive le premier.

La question sceptique soulevée par cette politique est de savoir si Apple peut distinguer systématiquement le volume de l’abus. La documentation publique explique ce qui rend un rapport exploitable, mais elle ne divulgue pas chaque seuil de triage ou décision d’escalade.

Les chercheurs ne peuvent pas non plus mesurer indépendamment combien de rapports IA invalides entrent dans le système d’Apple. L’entreprise a décrit le problème, mais n’a pas publié de ventilation mensuelle détaillée.

Cette absence n’invalide pas la réponse d’Apple. Elle limite l’évaluation externe du caractère proportionné d’un quota et de son efficacité à améliorer les délais de traitement.

Les inquiétudes historiques concernant les délais de réponse des fournisseurs rendent la transparence importante. Les chercheurs doivent savoir si le silence reflète un rapport faible, une longue enquête ou une file submergée par des soumissions sans rapport.

Un filtre mal mis en œuvre pourrait décourager la divulgation responsable. Un chercheur incapable de soumettre un rapport de manière privée pourrait retarder son signalement, s’adresser à un autre coordinateur ou divulguer publiquement après avoir perdu confiance dans le processus.

Une divulgation publique avant un correctif peut accroître le risque pour les utilisateurs. Les règles d’Apple rendent également toute divulgation prématurée non admissible à un paiement de bug bounty.

L’entreprise contrôle donc à la fois le canal accepté et les conditions de maintien de l’admissibilité. Cet arrangement fonctionne le mieux lorsque les chercheurs reçoivent un retour précis et rapide.

La norme la plus défendable est une friction fondée sur les preuves. Un chercheur qui soumet à répétition des conclusions hallucinées devrait faire face à des restrictions. Un chercheur disposant d’exploits reproductibles devrait bénéficier d’une voie d’escalade claire.

L’exception des Target Flags d’Apple va dans ce sens. Elle privilégie l’impact vérifiable plutôt que la seule réputation.

Toutefois, les Target Flags ne couvrent pas toutes les catégories de vulnérabilités. Certaines failles logiques importantes résistent à une preuve simple fondée sur des indicateurs, et certains rapports exigent une appréciation contextuelle.

Ce compromis ne peut pas être éliminé par une seule politique. Apple doit filtrer suffisamment agressivement pour protéger le triage tout en restant suffisamment ouvert pour capter des recherches inattendues.

Google et GitHub montrent qu’il s’agit d’une évolution du secteur

Apple n’agit pas seule, et le modèle industriel émergent récompense l’impact démontré plutôt que le volume de découvertes automatisées.

La mise à jour de Google de mars 2026 offre la comparaison la plus claire. L’entreprise a reconnu que l’IA peut accélérer la recherche de vulnérabilités, tout en insistant sur le fait que les chercheurs doivent valider ses résultats au cours de l’enquête.

Google n’a pas rejeté des rapports au seul motif que l’IA y avait contribué. L’entreprise a relevé les exigences de preuve pour certains niveaux de dépôts et réduit les incitations pour les catégories à plus faible valeur.

Son programme global Vulnerability Reward Program inclut désormais des facteurs de qualité des rapports, tels que la précision technique, la réactivité et l’exactitude factuelle. Les règles publiées identifient l’« AI slop » comme un signal de qualité négatif.

Cette formulation reflète un glissement : il ne s’agit plus seulement d’évaluer la vulnérabilité alléguée, mais aussi le processus de soumission. Les chercheurs doivent démontrer qu’ils comprennent la cible et qu’ils peuvent étayer les questions de suivi.

GitHub a adopté une autre variante en juillet 2026. L’entreprise a restructuré son programme public de primes et créé une filière permanente sur invitation réservée à certains chercheurs.

L’entreprise a également ajouté une exigence de signal HackerOne à son programme public. Le signal est une mesure de réputation fondée sur la fréquence à laquelle les rapports d’un chercheur reçoivent des résultats favorables.

GitHub a indiqué que cette exigence visait à réduire les soumissions produites avec peu d’effort ou générées par l’IA. Les rapports déposés à partir du 27 juillet ont intégré la structure révisée.

Les changements de GitHub montrent comment un programme ouvert peut progressivement devenir conditionné par la réputation. Les nouveaux chercheurs disposent de possibilités limitées pour établir un historique utile.

Le modèle d’Apple semble actuellement moins dépendant d’un score de réputation tiers. Il combine plutôt des critères de rapport, des limites de dossiers actifs et des sanctions progressives.

Les trois entreprises résolvent le même problème d’allocation avec des mécanismes de contrôle différents.

Google relève les exigences de preuve et restreint les catégories éligibles. GitHub ajuste l’accès, la réputation et les récompenses. Apple limite l’occupation de la file d’attente et pénalise les soumissions invalides répétées.

Ces approches peuvent améliorer le signal, mais chacune comporte un risque d’exclusion différent. Les exigences de preuve favorisent les chercheurs disposant d’outils matures. Les barrières de réputation favorisent les participants établis. Les quotas favorisent ceux dont les dossiers antérieurs se clôturent rapidement.

Le phénomène dépasse les grandes entreprises technologiques. Des mainteneurs de projets open source ont également signalé des affirmations de vulnérabilités générées par l’IA qui mobilisent du temps bénévole.

Ces projets font face à un déséquilibre encore plus marqué. Une bibliothèque populaire peut ne compter que quelques mainteneurs, tandis que des scanners automatisés peuvent produire des rapports en continu.

Les plateformes de bug bounty ont répondu par des règles plus strictes contre les hypothèses d’IA non validées. Certaines exigent des tests manuels et une confirmation avant qu’un chercheur ne soumette une découverte.

Cette convergence met un point en évidence : le secteur n’interdit pas la recherche en sécurité assistée par machine. Il retire les récompenses et l’attention accordées aux affirmations générées par machine sans vérification humaine responsable.

Cette distinction façonnera les futurs agents de sécurité. Les outils qui ne produisent que des rapports plausibles perdront de leur valeur. Ceux qui reproduisent des exploits, recueillent des traces et expliquent des chemins d’attaque accessibles resteront utiles.

L’opportunité concurrentielle réside dans l’automatisation des preuves. Un agent de sécurité ne devrait pas s’arrêter après avoir identifié du code suspect.

Il devrait construire un cas de test, confirmer la version affectée, isoler les conditions préalables et enregistrer l’exposition résultante en matière de privilèges ou de données. Les chercheurs humains doivent ensuite examiner ces éléments avant divulgation.

La comparaison entre Apple et Google est donc davantage qu’une histoire de politique. Elle définit les exigences produit de la prochaine génération d’outils de sécurité automatisés.

L’IA peut trouver de véritables vulnérabilités, mais la preuve reste le goulet d’étranglement

L’argument le plus solide contre une interdiction générale de l’IA est simple : les systèmes automatisés contribuent déjà à de véritables découvertes de sécurité.

Google a mis en avant la recherche de vulnérabilités assistée par IA à travers des projets tels que Big Sleep, un agent développé par Google DeepMind et Project Zero. Le projet combine le raisonnement de modèles avec des outils de sécurité établis.

Ce travail montre pourquoi les entreprises évitent les interdictions absolues. L’IA peut explorer de vastes bases de code, générer des hypothèses et aider les chercheurs à étudier des interactions complexes.

Les règles d’Apple préservent cette distinction. Elles font référence aux découvertes par IA sans validation adéquate, et non à chaque découverte développée avec une assistance de l’IA.

Un chercheur peut utiliser un modèle pour examiner le code source ou améliorer un rapport. La soumission finale doit néanmoins décrire le comportement observé, le comportement attendu, le mécanisme contourné et un résultat d’attaque crédible.

Une preuve de concept fiable reste essentielle. Une preuve de concept est un test minimal qui démontre la vulnérabilité dans des conditions définies.

Pour les chaînes d’attaque complexes, Apple demande les versions compilées et source, les charges utiles requises et tout ce qui est nécessaire pour exécuter la chaîne. Cette exigence place la reproductibilité au-dessus de la confiance narrative.

Apple a des raisons de préserver une recherche externe de haute qualité. Dans une précédente mise à jour sur les primes, l’entreprise a indiqué avoir versé plus de 35 millions de dollars à plus de 800 chercheurs depuis l’ouverture du programme public en 2020.

Elle a également fait état de plusieurs récompenses individuelles de 500 000 dollars. Ces chiffres montrent que les soumissions externes ne constituent pas une composante périphérique du processus de sécurité d’Apple.

Le défi consiste à maintenir ce canal utilisable à mesure que l’automatisation se développe. Si les équipes de triage passent trop de temps à réfuter des scénarios fabriqués, la valeur de l’ensemble du programme diminue.

Toutefois, le triage automatisé ne peut pas être considéré comme infaillible. Un exploit inhabituel peut ressembler à un faux positif parce qu’il franchit une frontière que les examinateurs n’avaient pas anticipée.

Un filtre fondé sur un modèle peut aussi récompenser une structure de rapport conventionnelle. Des chercheurs utilisant un anglais moins soigné ou des méthodologies inhabituelles pourraient recevoir des scores plus faibles malgré des preuves valides.

Apple indique que ses rapports font l’objet d’un examen humain, tandis que l’IA aide à prioriser les dossiers entrants. Cette répartition peut réduire le travail administratif sans confier entièrement les décisions finales à un classificateur.

Les détails restent importants. Les chercheurs doivent savoir si la priorisation automatisée influence le délai de réponse, l’éligibilité ou seulement l’ordre dans la file d’attente.

Les faux négatifs créent un risque différent du spam. Un rapport invalide rejeté fait perdre du temps à un chercheur. Un rapport valide rejeté peut laisser des millions d’appareils exposés.

La solution n’est pas d’accepter chaque affirmation générée. Elle consiste à rendre les recours, l’escalade et les normes de preuve suffisamment clairs pour que les découvertes solides puissent se remettre d’une mauvaise classification initiale.

Les équipes de sécurité devraient également mesurer les résultats, et pas seulement la réduction du volume. Une politique réussie devrait raccourcir le délai de validation des rapports critiques sans réduire le nombre de découvertes à fort impact acceptées.

Les chercheurs ont aussi des responsabilités. Ils devraient reproduire les résultats du modèle, tester les versions affectées, décrire les conditions préalables et supprimer tout langage spéculatif non étayé par des expériences.

Une prose générée par IA peut donner à l’incertitude l’apparence de la certitude. L’examen humain doit inverser cette tendance en séparant les observations des hypothèses.

Un rapport utile devrait répondre à quatre questions concrètes. Quelle entrée déclenche le comportement ? Quelle configuration prise en charge est affectée ? Quelle frontière de sécurité échoue ? Que gagne l’attaquant ?

Lorsque ces réponses manquent, davantage de texte n’améliore pas le rapport. Cela augmente le coût de recherche des preuves manquantes.

Ce qu’il faut surveiller après le durcissement contre les rapports de bugs générés par IA

Le prochain test sera de savoir si des règles plus strictes améliorent la qualité des réponses sans éloigner les chercheurs crédibles.

Le premier signal sera la performance d’Apple en matière de traitement des rapports. Des délais d’examen initial plus courts étayeraient l’argument de l’entreprise selon lequel les soumissions invalides consommaient une capacité critique.

Apple ne publie actuellement pas de tableau de bord public détaillé couvrant la taille de la file d’attente, les motifs de rejet et le délai de réponse médian. Davantage de transparence faciliterait l’évaluation de l’effet de la politique.

Les chercheurs peuvent néanmoins fournir des éléments indirects. Des signalements d’accusés de réception plus rapides, de mises à jour de statut plus claires et de moins nombreux dossiers prolongés suggéreraient que les contrôles fonctionnent.

Le schéma inverse affaiblirait l’explication d’Apple. Si les rapports légitimes restent retardés après les restrictions de volume, le goulet d’étranglement pourrait concerner les effectifs, la coordination interne ou la capacité de correction.

Le deuxième signal concernera le traitement des chercheurs à fort volume. Apple autoriserait les demandes d’augmentation de quota, créant une importante soupape de sécurité pour les équipes disposant de découvertes validées.

Les observateurs devraient surveiller si ces demandes reçoivent des décisions rapides et si les preuves, plutôt que la seule réputation, déterminent l’approbation.

Un processus d’exception efficace permettra aux équipes sérieuses de poursuivre des audits concentrés. Un processus opaque donnera au plafond de rapports actifs une apparence arbitraire.

Google offre un repère externe utile. Ses exigences de preuve plus élevées devraient réduire les rapports invalides, mais elles pourraient aussi diminuer la participation aux projets open source de niveau inférieur.

Les politiques d’Apple et Google sembleront plus défendables si les deux programmes maintiennent de forts taux de découverte tout en réduisant le trafic de faible valeur dans les files d’attente. La seule baisse du total des soumissions ne prouverait pas le succès.

Le troisième signal viendra des fournisseurs d’outils de sécurité et des agents d’IA. Le marché a désormais une incitation claire à produire des artefacts reproductibles plutôt que des spéculations soignées sur des vulnérabilités.

Les outils utiles intégreront des traces d’exécution, des informations de version, des environnements de test et des conditions préalables à l’exploit. Ils signaleront également les inférences incertaines au lieu de les présenter comme des comportements confirmés.

Les opérateurs de programmes pourraient soutenir cette transition avec des schémas de soumission lisibles par machine. Les champs requis pourraient séparer les résultats observés, l’impact déduit, les détails de l’environnement et les étapes de validation humaine.

Des preuves standardisées pourraient améliorer le routage automatisé sans remplacer le jugement d’experts. Elles faciliteraient également l’audit des soumissions en masse.

La question plus difficile est de savoir si les attaquants bénéficient des mêmes avantages de l’automatisation sans être confrontés à des règles de divulgation. Ils n’ont pas besoin de prouver une vulnérabilité à un fournisseur avant de l’exploiter.

Les défenseurs ne peuvent donc pas répondre à une mauvaise automatisation en rejetant l’automatisation dans son ensemble. Ils ont besoin de meilleurs agents, de pipelines de validation plus solides et d’une escalade humaine plus rapide pour les découvertes crédibles.

La politique immédiate d’Apple protège la porte d’entrée de son programme de primes. Elle ne résout pas le défi plus large de la découverte de vulnérabilités à l’échelle des machines.

Pour les chercheurs, le message pratique est direct. Utilisez l’IA pour élargir l’espace de recherche, mais ne soumettez que ce que vous pouvez reproduire et défendre face à un questionnement technique.

Pour les responsables d’ingénierie, la leçon dépasse les bug bounties. Tout flux de travail qui accepte des résultats d’IA générés de l’extérieur nécessite un contrôle lié aux preuves, à la responsabilité et au coût de l’examen.

L’évolution des politiques d’Apple et Google sera finalement jugée par ce qui parvient aux ingénieurs après le filtrage. La file contient-elle moins de rapports, ou contient-elle de meilleurs rapports ?

Cette différence devrait guider la prochaine phase. Suivez les délais de réponse, observez le fonctionnement des demandes d’exception et recherchez des agents de sécurité qui produisent des preuves plutôt qu’un texte assuré.