Le triage des malwares par LLM de Databricks comble un angle mort binaire, mais le contexte reste décisif

Databricks a publié une étude sur le triage des malwares par LLM qui a fait passer le taux d’échec de détection de 50 % à 4 % sur 70 tests de modèles économiques. L’amélioration ne provient ni d’un réentraînement de ces modèles ni de leur remplacement par des alternatives plus coûteuses. Elle repose sur l’injection de connaissances structurées en sécurité binaire avant chaque décision du modèle.

Ce résultat remet en cause une hypothèse courante derrière l’analyse de packages assistée par IA. Une plus grande intelligence du modèle n’est pas toujours la réponse la plus directe à des jugements de sécurité faibles. Un modèle plus petit peut combler une grande partie de l’écart lorsque l’analyse statique lui fournit les bons éléments de preuve et le bon cadre d’interprétation.

Cette conclusion importe car les packages npm malveillants ne révèlent pas toujours leur comportement dans du JavaScript lisible. Certains intègrent des exécutables compilés derrière des fichiers sources propres, des métadonnées crédibles et des scripts d’installation familiers. Ce contexte environnant peut conduire un modèle non assisté à rendre un verdict assuré mais dangereux.

L’expérience complète, publiée le 16 octobre 2026, a testé directement cette défaillance. Databricks a évalué neuf modèles issus de sept fournisseurs à l’aide de charges utiles Node.js natives conçues pour l’étude. L’entreprise a ensuite comparé leurs jugements avec et sans profils de capacités, des guides structurés élaborés à partir d’éléments de preuve statiques.

La comparaison principale n’oppose donc pas un modèle à un autre. Elle confronte le raisonnement d’un LLM non assisté à un raisonnement de LLM ancré dans des preuves propres au domaine. Databricks a constaté que cette distinction peut déterminer si un voleur d’identifiants dissimulé est bloqué ou recommandé pour une liste d’autorisation.

Le triage des malwares par LLM de Databricks modifie le contexte de décision

Databricks n’a pas appris à ses modèles à rétroconcevoir des binaires ; l’entreprise a modifié ce qu’ils savaient avant de les évaluer.

Le pipeline de l’entreprise commence avec des outils de sécurité déterministes. YARA analyse l’archive du package à la recherche de motifs connus. Semgrep examine le code source JavaScript, tandis que les métadonnées npm fournissent des informations sur le package et son objectif déclaré.

Un module distinct d’analyse binaire extrait des éléments de preuve à partir d’artefacts compilés. Le système combine ces résultats dans un prompt structuré. Le LLM renvoie ensuite un verdict et son raisonnement, avec jusqu’à trois possibilités de demander des fichiers supplémentaires.

Databricks a ajouté les profils de capacités entre l’extraction des preuves et le jugement du modèle. Chaque profil représente une technique malveillante, telle que la collecte d’identifiants, la persistance, le camouflage binaire ou l’exfiltration réseau. Il évalue des conditions observables selon des seuils suspects, malveillants et critiques.

Lorsqu’un profil atteint son seuil, le système ajoute au contexte du modèle un résumé structuré d’environ 1 800 tokens. Le modèle conserve le contrôle du verdict final et peut rejeter l’interprétation du profil. Le contenu injecté sert de briefing d’expert, et non de classification figée.

Cette architecture sépare deux tâches que les produits de sécurité basés sur les LLM confondent souvent. Les outils statiques identifient les imports, les propriétés de fichiers, les métadonnées et les motifs de code. Le modèle de langage pondère ces signaux dans le contexte plus large du package.

L’expérience a utilisé cinq types de charges utiles malveillantes empaquetées sous forme d’addons Node.js natifs. Elles représentaient un voleur d’identifiants, un dropper, un shell inversé, un stub de cryptomineur et un mécanisme de persistance. Le voleur d’identifiants apparaissait également à six niveaux d’obfuscation.

Chaque package incluait des métadonnées d’apparence professionnelle, un README plausible, des liaisons JavaScript et une configuration de build standard. Ces éléments créaient l’apparence d’un module natif normal. Le comportement malveillant restait enfermé dans un fichier .node compilé.

Les chercheurs ont exécuté dix charges utiles contre chaque modèle à deux reprises. Une exécution incluait les profils de capacités, l’autre non. Les prompts, les preuves binaires, les paramètres d’inférence et les octets des charges utiles restaient par ailleurs inchangés.

Sept modèles composaient le niveau économique : Claude Haiku 4.5, Gemini 3.5 Flash, Gemma 3 12B, GPT-5.4-nano, Qwen3-Next 80B, GLM 5.3 Flash et Llama 3.1 8B. Claude Sonnet 4.6 et Kimi K3 ont fourni des références comportementales de capacité supérieure.

Sans profils de capacités, le groupe économique n’a pas atteint le seuil de détection de l’étude dans 35 des 70 tests. Vingt de ces résultats ont qualifié de bénignes des charges utiles connues comme malveillantes. Au seuil malveillant plus strict, 51 tests sur 70 se sont révélés insuffisants.

Après l’injection des profils, 32 de ces 35 échecs sont devenus des détections. Aucun modèle testé n’a rendu de verdict bénin pour une quelconque charge utile conçue pour l’étude. Seuls trois résultats de GPT-5.4-nano sont restés sous le seuil d’escalade, les trois étant étiquetés comme suspects.

C’est le changement central derrière le triage des malwares par LLM de Databricks. Les modèles n’ont reçu ni nouveaux poids, ni entraînement élargi, ni cours général sur la sécurité. Ils ont reçu des interprétations concises liées à des preuves déjà extraites du package.

Pourquoi des packages npm propres peuvent dissimuler des binaires dangereux

L’angle mort binaire apparaît lorsque le contexte apparemment inoffensif d’un package pèse davantage que des preuves que le modèle ne peut interpréter avec assurance.

Databricks a commencé à collecter des échantillons de malwares npm en novembre 2025. Son corpus de recherche comptait 11 413 versions de packages corroborées par les avis OSV sur les malwares npm. La plupart contenaient du code source malveillant ou récupéraient une charge utile depuis un serveur externe.

Seules 432 versions de packages corroborées, soit 3,8 %, embarquaient un binaire. Cette faible part créait un problème de triage disproportionné. Les packages contenant des binaires n’ont pas reçu de verdict malveillant décisif plus de deux fois plus souvent que les packages ne contenant que du code source.

Les taux rapportés étaient de 14,4 % pour les packages contenant des binaires et de 6,2 % pour les packages ne contenant que du code source. Cette différence est importante car les fichiers compilés retirent de nombreux signaux disponibles dans le code lisible. Les binaires dépouillés omettent également les noms de symboles qui aident les analystes à interpréter les fonctions et les données.

Un package npm peut légitimement inclure du code natif. Les bibliothèques de performance, liaisons de bases de données, outils d’image, terminaux et utilitaires système utilisent régulièrement des composants compilés. Un script d’installation appelant node-gyp-build n’est donc pas automatiquement suspect.

Les attaquants peuvent exploiter cette normalité. Ils peuvent placer un comportement natif malveillant derrière des liaisons JavaScript propres et une description de package crédible. Un modèle qui se concentre sur la cohérence au niveau du package peut considérer ces signaux bénins comme des preuves plus solides que des imports binaires ambigus.

Databricks a observé ce comportement dans chacun des 35 échecs initiaux de détection. Chaque échec reposait sur au moins deux signaux contextuels bénins. Vingt-quatre en citaient quatre simultanément.

Les 35 considéraient le script d’installation comme standard. Les 35 considéraient également l’empaquetage d’addons natifs comme ordinaire. Trente-deux jugeaient les métadonnées cohérentes avec l’objectif déclaré, tandis que 21 s’appuyaient sur un JavaScript propre.

Dans 14 cas, les modèles ont reformulé les imports du binaire comme des appels système normaux. Des fonctions telles que fopen, connect et gethostname peuvent servir à des logiciels légitimes. Leur combinaison et leur comportement environnant déterminent si elles indiquent un vol d’identifiants ou une activité réseau habituelle.

L’obfuscation a aggravé ce jugement. Databricks a constaté que certains modèles attribuaient une gravité plus faible à mesure que la charge utile de vol d’identifiants devenait plus difficile à inspecter. L’enveloppe propre restait lisible tandis que les preuves binaires incriminantes devenaient moins accessibles.

Ce schéma correspond à une étude plus large sur l’obfuscation impliquant ChatGPT-4o, Gemini Flash 2.5 et Claude Sonnet 4. Les transformations du compilateur ont entraîné des échecs de classification répétés, alors même que le comportement sous-jacent du programme restait inchangé.

Les recherches sur le contexte des binaires dépouillés décrivent un défi connexe. La suppression des symboles retire les signaux contextuels utilisés pour localiser et valider les comportements dangereux. Un raisonnement plus fluide ne peut pas reconstruire des preuves que le pipeline d’analyse n’a jamais exposées.

Les registres de packages amplifient les conséquences, car les dépendances logicielles passent directement dans les environnements de développement et de production. MITRE définit le compromis de la chaîne d’approvisionnement comme la manipulation de logiciels, produits ou mécanismes de livraison avant que le destinataire ne les reçoive.

Un package malveillant peut donc hériter de la confiance accordée au registre, au graphe de dépendances ou au compte d’un mainteneur compromis. Une fois installé, son binaire peut s’exécuter avec les autorisations de l’application. Une présentation propre devient une partie de la surface d’attaque.

Les profils de capacités transforment les indices statiques en contexte de sécurité

Les profils de capacités fonctionnent parce qu’ils convertissent des indices techniques dispersés en une affirmation explicite qu’un modèle peut évaluer.

Une liste brute d’imports n’explique pas l’intention. connect indique une activité réseau, tandis que fopen indique un accès aux fichiers. Aucune de ces fonctions ne permet à elle seule de dire à un modèle qu’un addon natif lit des identifiants et les envoie ailleurs.

Un profil de capacités combine de telles observations dans un schéma propre à une technique. Il peut prendre en compte le type de package, le format binaire, les imports, l’entropie, les chaînes, les métadonnées et le comportement du code source. Des seuils pondérés expriment ensuite à quel point les preuves combinées étayent une hypothèse de sécurité.

Le processus ressemble à un raisonnement augmenté par récupération, mais le contenu récupéré est généré à partir du package examiné. Il ne s’agit pas d’un extrait général d’un rapport sur les menaces. Chaque résumé relie une définition de technique aux preuves trouvées lors de cette analyse.

Pour la charge utile de vol d’identifiants, les profils couvraient le camouflage binaire, la collecte d’identifiants, l’exfiltration réseau et la reconnaissance de l’environnement. Le shell inversé a déclenché des profils de camouflage binaire et de comportement de shell inversé. Le dropper a activé quatre profils critiques.

Cette spécificité modifie la tâche du modèle. Sans profils, le modèle doit déduire à la fois la signification de chaque artefact binaire et le verdict au niveau du package. Avec les profils, la logique statique traite la première étape d’interprétation.

Le modèle examine alors si les preuves assemblées étayent la conclusion du profil. Il peut considérer les éléments contraires, évaluer l’enveloppe du package et sélectionner une action. Cette répartition limite la quantité de connaissances spécialisées attendue des poids du modèle.

Le résultat obtenu avec le voleur d’identifiants par Qwen3-Next illustre cet effet. Sans profils, le modèle a qualifié un échantillon obfusqué de bénin avec une confiance de 0,98. Il a également recommandé d’ajouter le package à une liste d’autorisation.

Avec quatre profils injectés, le même modèle a qualifié l’échantillon strictement identique au niveau des octets de malveillant avec une confiance de 0,98. Il a recommandé de bloquer le package. Rien n’a changé, hormis le contexte de domaine structuré.

Ce revirement est plus important qu’une amélioration moyenne des benchmarks. Une recommandation d’ajout à une liste d’autorisation avec un haut niveau de confiance peut empêcher un examen ultérieur. Elle transforme un détecteur incertain en source opérationnelle de confiance mal placée.

L’expérience a également identifié quatre modes de défaillance récurrents : la rationalisation, le rejet, l’hésitation et la confabulation. Ces catégories expliquent pourquoi le simple fait de recueillir davantage d’avis de modèles ne résout pas le problème de manière fiable.

La rationalisation est apparue dans environ 37 % des 90 analyses réalisées sur les neuf principaux modèles. Les modèles utilisaient des détails ordinaires d’empaquetage pour écarter des preuves suspectes. Le rejet est apparu dans 22 % des cas et ignorait souvent entièrement les imports binaires.

L’hésitation a affecté 16 % des analyses. Ces modèles ont détecté un danger, mais se sont arrêtés à un verdict suspect, potentiellement sous le seuil de blocage automatisé. Des confabulations sont apparues dans environ 23 % des cas, y compris dans les réponses de modèles plus performants.

La confabulation a créé un risque opérationnel différent. Un modèle pouvait parvenir au bon verdict tout en inventant des adresses, des fonctions ou des routines de chiffrement. Ces faux détails pouvaient contaminer les registres d’audit et orienter à tort les enquêteurs humains.

Gemini 3.5 Flash a détecté les dix charges utiles sans profils de capacités. Toutefois, Databricks a signalé des détails techniques fabriqués dans plusieurs explications. Une classification correcte ne garantissait pas un raisonnement médico-légal fiable.

Ce résultat plaide en faveur d’une conception fondée d’abord sur les preuves. Un pipeline de sécurité devrait conserver la source de chaque affirmation et distinguer les observations extraites de l’interprétation du modèle. Les analystes doivent pouvoir remonter d’un verdict aux véritables imports, sections, chaînes ou comportements du code source.

Une base de connaissances techniques maintenue peut également soutenir la dimension humaine de ce processus. Les équipes ont besoin de dossiers accessibles sur la logique des profils, les exceptions, les décisions de revue et l’évolution des techniques des attaquants.

Les modèles moins chers réduisent l’écart, mais les métriques ont leurs limites

Le constat sur les coûts est crédible dans le cadre de l’expérience, mais les résultats en production n’établissent pas une détection binaire parfaite.

Claude Sonnet 4.6 et Kimi K3 ont détecté chaque charge utile conçue sans profils. Databricks a estimé que ces modèles de base coûtaient environ trois fois plus par analyse que le groupe économique. L’injection de profils a permis à la plupart des modèles moins chers d’atteindre leur taux de détection.

Les preuves supplémentaires n’étaient pas gratuites. Les modèles économiques ont reçu de 9 % à 34 % de tokens d’entrée supplémentaires après l’injection des profils. Leur consommation de tokens de sortie a également augmenté dans la plupart des cas.

Les modèles plus performants ont parfois utilisé moins de ressources, car les profils réduisaient l’exploration. Claude Opus 4.6 a utilisé en moyenne environ 10 551 tokens d’entrée sans profils et 7 214 avec eux. Kimi K3 a produit 13 % de tokens de sortie en moins après avoir reçu les preuves du profil.

Ces chiffres suggèrent qu’un meilleur contexte peut remplacer des demandes répétées de fichiers ou un raisonnement prolongé. Ce bénéfice dépend de la qualité de l’étape statique. Des preuves faibles transformées en prose soignée ne feraient que rendre une conclusion erronée plus facile à accepter.

Le benchmark contrôlé reste également limité. Il a utilisé dix charges utiles conçues, issues de cinq types de comportements. Chaque modèle a effectué un passage contrôlé dans chaque condition, avec une température nulle et des prompts cohérents.

Le comportement des modèles hébergés peut dériver lorsque les fournisseurs mettent à jour leurs endpoints. Databricks a reconnu que les verdicts absolus représentent une seule période de service. La preuve la plus solide réside dans la différence observée, sur cette période, entre des entrées identiques.

La validation en production offre une vue plus large et plus désordonnée. Databricks a identifié 470 versions de paquets npm malveillants confirmées par OSV, contenant 604 binaires natifs. L’ensemble comprenait 273 fichiers PE, 215 fichiers ELF, 113 fichiers Mach-O et trois formats non identifiés.

Chaque binaire ELF était dépouillé de ses symboles. Quarante pour cent des binaires avaient été compilés avec Go ou Rust, tandis que 50 fichiers ELF étaient empaquetés avec UPX. Ces détails montrent pourquoi une règle universelle pour le code natif produirait des résultats faibles.

L’évaluation en production a couvert 425 versions de paquets malveillants avec des verdicts du scanner. Elle a également utilisé 2 449 versions de paquets provenant de 287 paquets apparemment bénins. Les candidats bénins dépassaient un million de téléchargements mensuels et n’avaient jamais figuré dans OSV.

Au seuil d’escalade, le scanner a signalé une précision de 0,77, un rappel de 0,81 et un score F1 de 0,79. Il a retrouvé 345 des 425 versions de paquets malveillants. Quatre-vingts sont restées sous le seuil.

L’ensemble bénin a produit 104 escalades, soit 4,25 % de ses versions de paquets. Ces alertes étaient concentrées dans six paquets, soit environ 2 % de l’ensemble distinct de paquets bénins.

Un taux de revue de 4,25 % peut être gérable dans une file de triage filtrée. Il deviendrait coûteux s’il était appliqué sans discernement à chaque version de paquet d’un vaste écosystème de dépendances. Le volume opérationnel compte autant que la précision du benchmark.

Les étiquettes introduisent également de l’incertitude. Les avis OSV désignent une version de paquet comme malveillante sans toujours identifier l’artefact qui porte la charge utile. Certains paquets peuvent contenir un binaire tiers innocent alors que du JavaScript malveillant réalise l’attaque effective.

Databricks a constaté qu’environ la moitié des 20 paquets de production classés comme bénins contenaient des outils tiers reconnaissables. Parmi les exemples figuraient ripgrep, node-pty et des plugins d’installation NSIS. L’avis pouvait néanmoins rester correct au niveau du paquet.

Le rappel signalé n’est donc pas une mesure nette de la classification binaire. Il mesure les décisions par rapport à des étiquettes OSV au niveau du paquet. Databricks indique explicitement que les performances réelles sur les binaires peuvent être plus élevées ou plus faibles.

La base de données des paquets malveillants de l’OpenSSF reste précieuse, car elle fournit des rapports ouverts au format OSV. Toutefois, des étiquettes à l’échelle d’un registre ne peuvent pas remplacer une vérification au niveau de l’artefact pour évaluer un détecteur de binaires.

Le raisonnement autonome du modèle est désormais la stratégie sous pression

Cette recherche met sous pression les produits de sécurité qui traitent un LLM comme l’analyste principal plutôt que comme la couche finale de raisonnement.

Les conceptions centrées sur le modèle sont attrayantes, car elles réduisent le travail d’intégration. Une équipe peut placer le contenu d’un paquet dans un prompt, demander un verdict et afficher une explication en langage naturel. Cette simplicité masque la dépendance du modèle à des preuves visibles.

Les charges utiles compilées révèlent cette faiblesse. Un modèle de langage peut interpréter du désassemblage ou des caractéristiques extraites lorsqu’ils sont disponibles. Il ne peut pas déduire de façon fiable un comportement dissimulé à partir de JavaScript propre et de métadonnées professionnelles uniquement.

L’achat d’un modèle plus grand peut améliorer la détection de base. Databricks a observé que Sonnet et Kimi détectaient toutes les charges utiles conçues sans profils. Pourtant, ces deux bases plus performantes ont tout de même produit un raisonnement confabulé dans certaines analyses.

Cela crée deux exigences distinctes. Un détecteur doit parvenir à la bonne décision d’escalade. Il doit également fournir des preuves qu’un analyste peut vérifier.

Les profils de capacités répondent à la première exigence en orientant l’attention vers des combinaisons significatives. Les résultats statiques structurés soutiennent la seconde en ancrant les explications dans des artefacts observables. Le LLM reste utile pour la synthèse, la résolution des conflits et la priorisation.

Le vote majoritaire n’offre pas la même protection. Sur un échantillon obfusqué de voleur d’identifiants, les neuf modèles se sont répartis entre bénin, suspect, très suspect et malveillant. La majorité est restée sous le seuil de détection.

Ces erreurs étaient corrélées, car plusieurs modèles faisaient confiance au même contexte bénin. Ajouter davantage de juges pareillement confus n’a pas apporté de preuves indépendantes. Le vote n’a fait que répéter l’angle mort.

L’implication stratégique dépasse npm. Les équipes de sécurité demandent de plus en plus aux LLM d’interpréter des alertes, du code source, des journaux, des configurations cloud et des événements d’identité. Chaque tâche comporte des hypothèses propres au domaine qu’un modèle généraliste peut ne pas appliquer de manière cohérente.

L’architecture la plus défendable sépare l’extraction, l’interprétation et la décision. Des outils déterministes extraient les faits. Des profils versionnés interprètent les combinaisons pertinentes. Le modèle résout le contexte et produit un jugement destiné à l’analyste.

Cela ne rend pas les profils neutres. Leurs auteurs choisissent les seuils, les pondérations, les définitions et les exceptions. Les attaquants peuvent également étudier les règles courantes et adapter leurs binaires pour éviter de les déclencher.

Les profils peuvent devenir obsolètes à mesure que les systèmes de build et les techniques de malware évoluent. Une combinaison d’imports suspecte aujourd’hui peut apparaître demain dans un framework légitime populaire. À l’inverse, une nouvelle méthode d’exfiltration peut échapper à des profils écrits autour d’anciens appels système.

L’approche déplace donc une partie du risque de la sélection du modèle vers la maintenance des connaissances. Les équipes de sécurité ont besoin de responsables pour la qualité des profils, les tests de régression et la revue des faux positifs. Elles ont aussi besoin de preuves versionnées expliquant pourquoi chaque règle existe.

Les défenses des registres constituent une couche distincte. Les conseils sur la provenance de npm expliquent comment les utilisateurs peuvent vérifier où et comment des paquets pris en charge ont été publiés. La provenance peut relier un artefact à son commit source et à son workflow de build.

Cette vérification aide à identifier les versions non autorisées ou altérées. Elle ne prouve pas que le code source autorisé ou le comportement compilé sont sûrs. Le triage des malwares, la provenance, la sécurité des mainteneurs et les contrôles d’exécution traitent différentes parties du même problème de chaîne d’approvisionnement.

Pour les acheteurs, la question clé n’est plus de savoir quel modèle domine un benchmark de sécurité générique. Ils devraient demander quelles preuves parviennent au modèle, comment les affirmations restent traçables et comment le système traite les binaires incertains.

Ils devraient également examiner la politique d’escalade. Un verdict suspect a peu de valeur protectrice si les workflows automatisés ne bloquent que les classifications malveillantes. Databricks a montré que plusieurs modèles reconnaissaient le risque sans franchir le seuil opérationnel.

Trois signaux permettront de vérifier si l’approche se généralise

Le prochain test déterminera si l’injection de connaissances métier résiste aux malwares inconnus, à l’échelle des registres et à l’adaptation adversariale.

Le premier signal est une reproduction indépendante sur des malwares réels, étiquetés au niveau de l’artefact. Les chercheurs ont besoin de jeux de données qui identifient si le composant malveillant est du JavaScript, des métadonnées, un script d’installation ou un binaire intégré.

De telles étiquettes affineraient les estimations de précision et de rappel. Elles révéleraient aussi si les profils détectent la charge utile réelle ou ne font que corréler avec une étiquette de paquet malveillant. Des résultats plus solides au niveau de l’artefact renforceraient l’affirmation centrale de Databricks.

Le deuxième signal est la performance face à des comportements et chaînes d’outils inédits. Databricks a testé cinq schémas d’attaque conçus et validé son scanner complet sur un ensemble plus large dérivé d’OSV. Les futurs tests devraient exclure des familles entières de comportements lors du développement des profils.

Une réussite sur des familles exclues montrerait que la méthode capture des concepts de sécurité transférables. Une forte baisse suggérerait que les profils fonctionnent principalement comme des règles soigneusement sélectionnées pour des schémas connus.

La diversité des compilateurs et des plateformes sera importante. Les fichiers PE, ELF et Mach-O exposent des métadonnées et des conventions différentes. Les binaires Go et Rust diffèrent également des artefacts C ou C++ de façons qui influent sur l’analyse statique.

Les attaquants réagiront si les systèmes de profils de capacités se généralisent. Ils peuvent remplacer les imports évidents, retarder l’exécution, charger des fonctionnalités dynamiquement ou déplacer le comportement malveillant vers une autre couche du paquet. Chaque adaptation peut affaiblir un résumé de preuves statiques.

Le troisième signal est le coût opérationnel de la revue. Databricks a signalé 104 escalades parmi 2 449 versions de paquets bénins, concentrées dans six paquets. Les données de déploiement devraient montrer combien d’heures d’analystes ces grappes consomment.

Un système durable doit regrouper les alertes liées, conserver les preuves et apprendre des exceptions examinées. Sinon, un taux modeste de faux positifs au niveau des paquets peut créer un travail répétitif entre les versions et les environnements.

Les équipes devraient aussi surveiller les échecs graves, et non seulement le rappel agrégé. Le scanner de production de Databricks a classé comme bénines 20 versions de paquets malveillants étiquetées OSV. Certaines portaient probablement leur charge utile hors du binaire intégré, mais l’incertitude reste importante.

La qualité des preuves devrait devenir une métrique publiée. Un détecteur qui classe correctement tout en inventant des détails médico-légaux n’est pas entièrement fiable. Les évaluations futures devraient noter l’ancrage factuel séparément de la précision du verdict.

Le triage de malwares par LLM de Databricks plaide fortement en faveur d’une expertise structurée au moment de l’inférence. Il montre que des modèles moins chers peuvent prendre de bien meilleures décisions lorsque le pipeline de sécurité interprète les preuves opaques avant de demander un jugement.

Cela n’établit pas que la connaissance disponible au moment du prompt élimine le problème des binaires. Les profils dépendent d’une visibilité statique, de règles maintenues et de seuils que les attaquants peuvent sonder. Les libellés de production laissent également sans réponse la question de savoir quel artefact était malveillant.

Les équipes de sécurité devraient désormais tester une proposition concrète : leurs modèles existants peuvent-ils s’améliorer grâce à de meilleures preuves avant qu’elles ne paient pour un modèle plus grand ? Constituez un ensemble d’évaluation à partir de paquets examinés, conservez les libellés au niveau des artefacts et comparez des analyses identiques avec et sans contexte de domaine. Le résultat utile n’est pas une explication convaincante. C’est un verdict traçable qui résiste à l’examen lorsque le paquet semble sain mais que le binaire ne l’est pas.