L’enthousiasme des investisseurs pour l’IA a alimenté l’espoir qu’elle améliorera considérablement les opérations de développement de logiciels, d’automatisation et de cybersécurité.
L’IA a déjà modifié la façon dont les logiciels sont créés, la manière dont les attaques sont générées et la rapidité avec laquelle ces deux éléments se propagent dans les entreprises. Cela a également accru les attentes des défenseurs : une analyse plus rapide, une meilleure priorisation et une prise de décision plus automatisée.
Cependant, lorsque les attaquants et les développeurs opèrent à la vitesse d’une machine, la prévention dépend moins de prédictions plus intelligentes que de décisions claires et exécutoires fondées sur l’intention.
La sécurité probabiliste ne suffit pas
La plupart des outils de sécurité, en particulier ceux intégrant l’apprentissage automatique ou de grands modèles de langage, sont probabilistes de par leur conception. Ils génèrent des probabilités : ce fichier est probablement malveillant, ce comportement est probablement suspect, cette activité a une forte probabilité d’être une attaque.
Cela fonctionne bien pour le triage et l’enquête. Il aide les analystes à passer au crible le bruit, à hiérarchiser les alertes et à identifier les modèles qui autrement passeraient inaperçus. Toutefois, ces atouts ne se traduisent pas nécessairement par des décisions d’application fiables.
Un système probabiliste ne fournit pas toujours le niveau de certitude requis pour déterminer si un artefact logiciel doit s’exécuter dans un environnement de production.
Les attaquants génèrent désormais du code polymorphe à usage unique. Les développeurs, quant à eux, s’appuient de plus en plus sur l’automatisation, les dépendances open source et les composants générés par l’IA qui circulent dans les pipelines sans examen humain. Dans les deux cas, le volume et la rapidité des logiciels dépassent les limites du jugement humain et la fiabilité de la notation probabiliste.
Il en résulte souvent un écart entre l’identification du risque et sa prévention.
Si les décisions de sécurité ne peuvent pas être prises avec suffisamment de confiance au moment de l’exécution, elles doivent être fondées sur quelque chose de plus stable que la probabilité et appliquées avant l’exécution du code. Il s’agit du fondement d’une approche Zero Trust for Code, dans laquelle l’exécution d’un logiciel n’est pas fiable tant que son comportement n’a pas été évalué par rapport à la politique.
La nécessité de contrôles de sécurité explicables
À mesure que les logiciels deviennent plus autonomes, les décisions en matière de sécurité doivent également être plus précises et plus fiables. Il ne suffit plus de détecter des anomalies ou d’attribuer des scores de risque. Les décisions doivent être explicables, reproductibles et vérifiables. Les équipes de sécurité doivent comprendre pourquoi un artefact a été autorisé ou bloqué, si le même artefact produirait le même résultat demain et si cette décision peut être défendue dans un contexte de conformité ou d’examen des incidents.
Les modèles probabilistes peinent à gérer ces trois éléments. Cela ne signifie pas que les systèmes probabilistes sont inefficaces. De nombreux programmes de sécurité modernes combinent analyse prédictive et contrôles basés sur des politiques, en utilisant chacun là où il est le plus efficace.
Même de petites variations dans l’état des entrées ou du modèle peuvent produire des résultats différents. Cette variabilité est acceptable pour aider les analystes, mais pas pour déterminer si le code est autorisé à s’exécuter dans un environnement réglementé. Ce risque devient plus prononcé dans les chaînes d’approvisionnement logicielles, où les décisions de confiance affectent non seulement un système, mais aussi les dépendances en aval, les environnements de production et les données clients.
Des incidents récents l’ont clairement montré. Dans le cadre de la compromission de la chaîne d’approvisionnement LiteLLM, un package Python largement utilisé a été brièvement modifié pour récolter les informations d’identification et établir la persistance dans les environnements de développement. Les versions malveillantes n’étaient disponibles que quelques heures, mais cela suffisait.
L’échec n’était pas la détection, mais le timing et la confiance. Au moment où les alertes pouvaient être générées, le code était déjà exécuté, les secrets avaient été révélés et des mécanismes de persistance étaient en place. Un modèle probabiliste peut signaler ce comportement après coup, mais il ne peut pas annuler la décision d’exécution.
Rien de tout cela ne diminue la valeur de l’IA en matière de sécurité. Il excelle dans l’identification de modèles sur de grands ensembles de données, la corrélation des signaux, l’accélération des enquêtes, la prise en charge de l’analyse des causes profondes et la réduction des charges de travail manuelles.
Utilisée correctement, l’IA peut améliorer considérablement la visibilité et la réponse, et aider les analystes à comprendre ce que le code peut faire. Mais cela ne devrait pas être l’autorité finale quant à savoir si ce code est autorisé à s’exécuter. Cette responsabilité nécessite des contrôles déterministes et axés sur les politiques.
Passer de la détection à la prévention
Au lieu de se demander si quelque chose est probablement malveillant, l’analyse déterministe des intentions comportementales se demande ce qu’un logiciel est capable de faire et si ce comportement est conforme à la politique.
Les logiciels malveillants générés par l’IA peuvent muter à l’infini, modifiant les hachages, les chaînes et la structure à la demande, mais leur intention ne change pas au même rythme que leur apparence. En effet, il ne peut pas atteindre son objectif sans effectuer certaines catégories d’actions, telles que l’accès à des données sensibles, la modification de l’état du système, l’établissement de la persistance ou la communication externe. Ces objectifs comportementaux restent souvent cohérents même lorsque le code sous-jacent change.
Il s’agit du cœur opérationnel de Zero Trust for Code : évaluer ce dont le logiciel est capable avant son exécution et appliquer une décision politique cohérente. En analysant le comportement avant l’exécution, les organisations peuvent autoriser les logiciels conformes à la politique, bloquer les logiciels qui enfreignent les contraintes définies et isoler ou faire remonter les cas qui nécessitent un examen plus approfondi.
Plus important encore, ces décisions sont conçues pour être cohérentes. Lorsqu’ils sont évalués par rapport aux mêmes politiques et conditions, les artefacts logiciels doivent produire des résultats prévisibles qui peuvent être examinés et audités. Cette cohérence est ce qui permet une prévention fiable. Cela modifie également le rôle des contrôles de sécurité. Au lieu de réagir aux événements d’exécution, ils deviennent les gardiens de l’exécution elle-même.
L’IA ne se contente pas d’améliorer les attaques ; cela comprime les délais. Les systèmes autonomes peuvent ingérer des dépendances, déployer des services et lancer des actions sans intervention humaine. Dans cet environnement, la prévention doit avoir lieu avant l’exécution, et non après.
Zero Trust for Code met l’accent sur l’application basée sur des politiques ainsi que sur l’analyse prédictive, prenant des décisions de sécurité basées sur la question de savoir si un artefact logiciel doit être autorisé à s’exécuter. Ce faisant, l’exécution devient un point de contrôle axé sur les politiques.
À mesure que l’IA accélère la création et le déploiement de logiciels, les organisations auront besoin de modèles de sécurité capables de suivre le rythme sans sacrifier la responsabilité. Il est peu probable que l’avenir soit un choix entre l’IA et les contrôles déterministes, mais plutôt une combinaison d’analyse intelligente et de politiques applicables qui permettent aux organisations d’agir rapidement tout en préservant la confiance.
