Une évolution extrêmement rapide

Dès novembre 2024 [3], puis à nouveau en juillet  2025 [4] le système « Big Sleep » de Google a découvert deux vulnérabilité importantes dans le logiciel SQLite, pourtant très testé et utilisé. En début d’année 2026, la jeune pousse AISLE est allée plus loin : en utilisant des modèles d’IAGén avec sa propre infrastructure d’analyse, elle a trouvé 12 vulnérabilités « zero-day » – dont une faille critique [5], ainsi que des bogues remontant à des codes des années 1990 – dans  la librairie OpenSSL pourtant largement auditée [6]. AISLE a signalé aussi un grand nombre de vulnérabilités dans plus d’une dizaine de projets établis, notamment Apache, Chromium, Firefox, le noyau Linux, OpenVPN, et Samba. En mars 2025, l’outils « Security Copilot » de Microsoft a découvert des vulnérabilités dans GRUB2 et U-Boot (des chargeurs d’amorçage utilisés par la plupart des systèmes Linux). En août 2025, lors de la compétition « AI Cyber Challenge » organisée par l’agence étatsunienne pour les projets de recherche avancée de défense (DARPA), sept systèmes d’IA y ont travaillé de manière autonome sur 54 millions de lignes de code, ont trouvé la majorité des vulnérabilités synthétiques insérées, et ont révélé 18 bogues jusqu’alors inconnus [7], [8].

Ces démonstrations, certes impressionnantes, tiennes plus à l’infrastructure mise en place autour de l’IAGén (les intégrations d’outils, les connexions aux logiciels d’analyse statique existants, les boucles de planification itératives) qu’aux performances brutes des modèles [2] : ce qui est donc déterminant ici, est la conception du système, plutôt que la capacité du modèle en soi.

À la conférence « CyberSec Europe 2026 », en plus du mot « souveraineté » qui continuait d’être répété de puis la conférence précédente, le mot « Mythos » a fait son apparition après le coup de marketing magistral de la société Anthropic [9], [10], qui n’en est d’ailleurs pas à son premier [11]. En effet, en  7 avril 2026, dans son annonce de la mise à disposition de « Claude Mythos Preview » réservée à quelques entreprises triées sur le volet, la société Anthropic affirmait que Mythos avait identifié de manière autonome des milliers de vulnérabilités « zero-day » dans des infrastructures logicielles critiques, découvert un vieux bogue OpenBSD, et été capable d’enchaîner quatre vulnérabilités pour créer une exploitation de navigateur fonctionnelle. Les études indépendantes sont pour le moment quasiment inexistante et seul l’Institut britannique de sécurité de l’IA (AISI) – un organisme gouvernemental chargé d’évaluer les systèmes d’IA avant et après leur déploiement – a pu évaluer Mythos Preview et a confirmé qu’il pouvait, dans 3 cas sur 10, mener à bien une simulation d’attaque en plusieurs étapes sur un réseau d’entreprise – un scénario estimé à 20 heures de travail pour un professionnel humain qualifié [12], [13].

Mais ces découvertes ne sont pas uniques à Mythos. Les vulnérabilités découvertes par Mythos, ont pu aussi être trouvées par la société AISLE en utilisant des modèles moins couteux et de plus petite taille, dont les poids sont publics et pouvant être exécutés sur du matériel grand public [10], [14]. Indépendamment, l’AISI a constaté que le modèle GPT-5.5, était lui-aussi capable de mener à bien une simulation d’attaque sur un réseau d’entreprise [15]. Lors de son évaluation, l’AISI a également identifié une technique « universelle » pour contourner les restrictions de sécurité du modèle rappelant que des garde-fous imposant un  comportement au modèle [16] ne sont probablement pas aussi efficaces que des contraintes architecturales.

Suivre la cadence

Face à l’accélération de la découverte de nouvelle vulnérabilité, il devient impératif d’accélérer les pipelines de remédiation logicielle, notamment dans les  composant comportant des dépendances externe critiques [17]. L’exemple d’OpenSSL en janvier 2026, démontre que l’audit automatisé est désormais un outil à double usage accessible simultanément tant aux chercheurs qu’aux opérateurs criminels et aux acteurs étatiques [18].

Alors que le volume de CVE explose – avec une augmentation de 263 % entre 2020 et 2025 – il risque de saturer les capacité de correction traditionnelles dans la plupart des organisations [19], [20]. Dans son annonce Anthropic admettait que moins de 1 % des vulnérabilités trouvées par Mythos avaient été corrigées. Découvrir des vulnérabilités à grande échelle sans les corriger à la même échelle ne fait qu’allonger la liste des expositions, sans améliorer la sécurité. Dans ce contexte, seules les organisations ayant prépositionné une infrastructure de correction autonome et agile parviendront à réduire leurs fenêtre d’exposition, là où les méthodes manuelles ne peuvent plus suivre la cadence imposée par l’IA [20], [21].

Heureusement, même si les outils d’IA, malgré leurs « hallucinations » [22], offrent de nombreuses nouvelles possibilité à l’attaque, l’impression qui ressort de conférences comme CyberSec Europe 2026 ou Black Hat Europe 2025 est que la défense semble, pour le moment, conserver l’avantage [23], [24]. Le marché des outils de sécurité pour les entreprises murit rapidement et ces outils tentent de faciliter le travail des analystes. Par exemple, l’outil « Security Copilot » de Microsoft, couvre le triage des alertes, l’optimisation des politiques d’accès et les enquêtes sur la sécurité des données et permettrait de réduire de manière important le nombre d’alertes par incident et de résoudre plus rapidement des conflits de politiques de sécurité. Le triage automatisé des alertes issues de la gestion des événement et des informations de sécurité (SIEM) via des outils agentique d’orchestration, d’automatisation et de réponse pour la sécurité (SOAR) permettrait de réduire le temps d’effort par incident de manière significative [25]. Plus généralement, des études de recherche rapportent des réductions substantielles des faux positifs sur les alertes lorsque l’IAGén est utilisée comme couche de triage contextuel par-dessus les outils traditionnels d’analyse statique [26].

La détection et correction de vulnérabilité, c’est n’est pas le seul impact de l’IA sur la sécurité. L’automatisation des cyber-attaques par l’IA permet aux attaquants d’opérer avec une célérité sans précédent — jusqu’à 3 600 fois plus vite que les humains — tout en ciblant simultanément un volume bien plus important d’actifs [20]. Face à un « rythme opérationnel » où le délai médian d’exploitation après publication est tombé à seulement 5 jours [27], les modèles de réponse manuels ou linéaires sont désormais obsolètes et incapables de contenir ces incursions à haute fréquence [20]. Cette évolution impose une refonte des livrets de réponse aux incidents (« playbooks »).

Enfin, l’utilisation de l’IA à des fins (plus ou moins) productives apporte elle aussi son lot de problèmes de sécurité dans les entreprises. Il est important d’identifier précisément où l’IA opère au sein d’une infrastructure afin de garantir la sécurité des données. Le phénomène de l’« IA fantôme » (« shadow AI ») — défini comme l’utilisation d’outils d’IA sans l’approbation ou la supervision du service informatique – représente un risque important. Cette exposition inclut des modèles accessibles via des comptes personnels, des fonctionnalités IA intégrées dans des logiciels tiers en tant que service (SaaS) sans achat explicite, ou encore des modèles « open-source » utilisés par des programmeurs en dehors de tout processus de gouvernance [28]. Une organisation ne peut pas défendre un périmètre qu’elle n’a pas défini, et l’absence de visibilité actuelle crée des vulnérabilités critiques : environ 91 % des outils d’IA en entreprise fonctionneraient en dehors du contrôle de la direction du service informatique [29]. Or, sans un inventaire centralisé et une politique de surveillance continue, les entreprises s’exposent à des coûts de violation de données nettement plus élevés [30].

Conclusion

Très rapidement les outils de sécurité par IA sont passés de la phase de démonstration de recherche à la pertinence opérationnelle, des deux côtés de la barrière : tandis que les capacités offensives de l’IA ont abaissé la barre pour les acteurs criminels de niveau intermédiaire et permis des campagnes d’intrusion plus évolutives, les applications défensives – triage des alertes, découverte de vulnérabilités, filtrage des faux positifs, tests d’intrusion autonomes – intègrent des fonctionnalités d’IA et apportent des améliorations par rapport aux générations précédentes. La mise en œuvre de flux de travail défensifs augmentés par l’IA marque une transition importante dans l’ingénierie de sécurité.

Le défi n’est plus la détection, mais la correction.

Références

[1]          F. A. P. Petitcolas, « L’IA pour améliorer la sécurité du code ? (Partie 1 : sécurité du code généré) », Smals Research, 30 juill. 2025. Disponible sur: https://www.smalsresearch.be/ia-pour-ameliorer-securite-du-code-1/

[2]          F. A. P. Petitcolas, « L’IA pour améliorer la sécurité du code ? (Partie 2 : détection de vulnérabilités) », Smals Research, 26 août 2025. Disponible sur: https://www.smalsresearch.be/ia-pour-ameliorer-securite-du-code-2/

[3]          R. Lakshmanan, « Google’s AI Tool Big Sleep Finds Zero-Day Vulnerability in SQLite Database Engine », The Hacker News, 11 nov. 2024. Disponible sur: https://thehackernews.com/2024/11/googles-ai-tool-big-sleep-finds-zero.html

[4]          « NVD – CVE-2025-6965 », NIST – National Institute of Standards and Technology, juill. 2025. Disponible sur: https://nvd.nist.gov/vuln/detail/CVE-2025-6965

[5]          « NVD – CVE-2025-15467 », CVE-2025-15467, janv. 2026. Disponible sur: https://nvd.nist.gov/vuln/detail/CVE-2025-15467

[6]          A. Muanza, « Douze failles de sécurité découvertes dans OpenSSL par une analyse basée sur l’IA », 29 jan. 2026. Disponible sur: https://www.ictjournal.ch/news/2026-01-29/douze-failles-de-securite-decouvertes-dans-openssl-par-une-analyse-basee-sur-lia

[7]          D. DiMolfetta, « DARPA unveils winners of AI challenge to boost critical infrastructure cybersecurity », Nextgov.com, 8 août 2025. Disponible sur: https://www.nextgov.com/cybersecurity/2025/08/darpa-unveils-winners-ai-challenge-boost-critical-infrastructure-cybersecurity/407337/

[8]          J. Greig, « DARPA announces $4 million winner of AI code review competition at DEF CON », The Record, 9 août 2025. Disponible sur: https://therecord.media/darpa-ai-code-competition-winner-def-con

[9]          B. Vigliarolo, « Anthropic’s bug-hunting Mythos was greatest marketing stunt ever, says cURL creator », The Register, 11 mai 2026. Disponible sur: https://www.theregister.com/security/2026/05/11/anthropics-bug-hunting-mythos-was-greatest-marketing-stunt-ever-says-curl-creator/5238111

[10]       B. Schneier, « Claude Mythos is mostly “marketing hype” », Schneier on Security, 26 avr. 2026. Disponible sur: https://www.schneier.com/news/archives/2026/04/claude-mythos-is-mostly-marketing-hype.html

[11]       F. Tréguer, « La bonne conscience de la Silicon Valley », Le Monde diplomatique, 1 mai 2026. Disponible sur: https://www.monde-diplomatique.fr/2026/05/TREGUER/69543

[12]       « Our evaluation of Claude Mythos Preview’s cyber capabilities | AISI Work », AI Securty Institute (AISI), avr. 2026. Disponible sur: https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

[13]       L. Folkerts et al., « Measuring AI agents’ progress on multi-step cyber-attack scenarios », 17 mars 2026, arXiv: arXiv:2603.11214. doi: 10.48550/arXiv.2603.11214.

[14]       « Smaller and cheaper models also managed to discover the same security bugs as Claude Mythos, says AISLE analysis », OfficeChai, 9 avr. 2026. Disponible sur: https://officechai.com/ai/smaller-and-cheaper-models-also-managed-to-discover-the-same-security-bugs-as-claude-mythos-says-aisle-analysis/

[15]       « Our evaluation of OpenAI’s GPT-5.5 cyber capabilities », AI Security Institute, 30 avr 2026. Disponible sur: https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

[16]       B. Vanhalst, « Garde-fous : délimitez votre IA », Smals Research, 27 nov. 2025. Disponible sur: https://www.smalsresearch.be/garde-fous-delimitez-votre-ai/

[17]       « 4th annual software supply chain security report 2026 – How sophisticated malware, AI, and broken trust are reshaping software security », Reversing Labs, 2026.

[18]       B. Schneier, « AI found twelve new vulnerabilities in OpenSSL », Schneier on Security, 18 fév. 2026. Disponible sur: https://www.schneier.com/blog/archives/2026/02/ai-found-twelve-new-vulnerabilities-in-openssl.html

[19]       « NIST updates NVD operations to address record CVE Growth », NIST, 15 avr. 2026. Disponible sur: https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

[20]       « The NVD infrastructure crisis: AI discovery overwhelms tracking », CSAI Foundation | Cloud Security Alliance, mai 2026. Disponible sur: https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/05/CSA_whitepaper_NVD_infrastructure_crisis_AI_vulnerability_discovery_20260504-csa-styled.pdf

[21]       « Reddit taps Fleet’s autonomous patching to slash vulnerability exposure », MarketChameleon.com. Consulté le: 27 mai 2026. Disponible sur: https://marketchameleon.com/articles/b/2026/5/15/reddit-autonomous-patch-fleet-ai-cybersecurity

[22]       « Disrupting the first reported AI-orchestrated cyber espionage campaign », Anthropic, nov. 2025. Disponible sur: https://www-cdn.anthropic.com/d7dd50dd1185f59be051b307150d877f2b82bd2c.pdf

[23]       D. O’Brien et P. Miller, « Black Hat Europe 2025: Inside the defender’s AI advantage », Security.com, 15 jan. 2026. Disponible sur: https://www.security.com/expert-perspectives/inside-defenders-ai-advantage

[24]       Discussions privées à CyberSec Europe 2026, mai 2026.

[25]       TrendAI, « Experience the AI security revolution », 22 mai 2026.

[26]       X. Du et al., « Reducing False Positives in Static Bug Detection with LLMs: An Empirical Study in Industry », 26 janvier 2026, arXiv: arXiv:2601.18844. doi: 10.48550/arXiv.2601.18844.

[27]       Rapid7, « Rapid7 2026 global threat landscape rReport shows exploited high and critical-severity vulnerabilities surged 105% as attack timelines collapsed », Rapid7, 18 mars 2026. Disponible sur: https://www.rapid7.com/about/press-releases/rapid7-2026-global-threat-landscape-report-shows-exploited-high-and-critical-severity-vulnerabilities-surged-105-as-attack-timelines-collapsed/

[28]       J. Kisielius, « Shadow AI in IBM’s 2025 cost of a data breach report », 8 oct. 2025. Disponible sur: https://www.nudgesecurity.com/post/shadow-ai-the-emerging-security-threat-in-ibms-2025-cost-of-a-data-breach-report

[29]       « The invisible enterprise: shadow AI and the ungoverned frontier », Lab Space, 2 avr. 2026. Disponible sur: https://labs.cloudsecurityalliance.org/research/csa-whitepaper-shadow-ai-asset-blindness-systemic-risk-20260/

[30]       L. Kornutick, S. Agarwal, A. Litan, S. Sicular, P. Sundararaman, et S. Palit, « Market guide for AI governance platforms », Gartner, G00837249, nov. 2025. Disponible sur: https://www.gartner.com/document-reader/document/7145930

Dans un précédent article, nous avons exposé les avantages des conteneurs confidentiels et leur architecture dans le projet « CoCo. » Dans cet article, nous approfondissons notre propos en détaillant le fonctionnement de certains aspects de CoCo et en décrivant notre installation sur notre propre matériel.

Attestation de conteneurs

Les capsules Kubernetes, utilisées comme abstraction pour les charges de travail conteneurisées confidentielles, introduisent plusieurs défis. Leur nature dynamique — création, suppression, mise à jour de conteneurs — et l’influence de l’environnement Kubernetes (variables d’environnement, contrôleurs d’admission, etc.) rendent difficile la garantie que seul le code prévu par l’utilisateur sera exécuté. Par exemple, l’injection de variables malveillantes ou la modification de la spécification d’une capsule avant son lancement peuvent compromettre la confidentialité.

Le projet CoCo propose une solution élégante qui consiste à utiliser un moteur de politiques de sécurité, intégré à l’environnement d’exécution du conteneur dans l’environnement d’exécution de confiance (EEC), qui applique des règles définies par l’utilisateur. Ce moteur peut, par exemple, autoriser uniquement certaines images ou commandes, et rejeter les appels problématiques (comme l’exécution de processus non autorisés). La Figure 1 montre un exemple d’une telle politique.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figure 1 – Exemple de politique de sécurité (langage REGO) restreignant les images pouvant être exécutées et les commandes pouvant être invoquées dans l’image. Cette politique est appliquée par un agent inclus dans la machine virtuelle confidentielle.

Quatre composants de la machine virtuelle confidentielle invitée sont systématiquement mesurés pour assurer leur intégrité : le micrologiciel (e.g., OVMF), le noyau du système d’exploitation, la ligne de commande du noyau et le système de fichiers racine (Figure 2). Une entité externe de confiance, généralement appelée Trustee, atteste de l’intégrité de l’invité, renforçant ainsi la chaîne de confiance.

Cependant, les conteneurs confidentiels nécessitent généralement des données d’initialisation qui ne peuvent pas être intégrées directement dans l’image de la machine virtuelle ou du conteneur applicatif, comme les certificats, les adresses des services d’attestation ou les politiques de sécurité à appliquer. Ces données, bien que non secrètes, doivent être protégées contre toute altération.

Ces données d’initialisation appelées init-data peuvent être spécifiées sous forme de dictionnaire (e.g., fichiers JSON, TOML, YAML), encodé en base64 et passé à la capsule Kubernetes via une annotation Kubernetes (Figure 3). Afin de garantir leur intégrité, leur valeur de hachage cryptographique est fournie par l’agent d’attestation (fonctionnant dans la machine virtuelle confidentielle) en donnée d’entrée pour le calcul de l’attestation (cela peut se faire en utilisant le champ « HostData » de SEV-SNP). Il est alors possible de comparer les données d’initialisation envoyées à la machine hôte pour le lancement du conteneur avec la valeur de hachage reçue au moment de l’attestation, assurant ainsi que toute modification sera détectée lors de l’attestation à distance.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figure 3 – Exemple de données d’initialisation fournies (sous forme encodée) via une annotation Kubernetes à l’agent invité CoCo dans la machine virtuelle confidentielle.

Gestion de clés

Un service extérieur de médiation de clés, qui peut être connecté à une boîte noire transactionnelle, permet au conteneur d’obtenir dynamiquement des ressources nécessaires à son fonctionnement. Si le client n’est pas déjà en possession d’un témoin de connexion précédemment obtenu du service de médiation de clés, il doit d’abord s’authentifier et le service de médiation de clés lui répond avec un défi auquel il doit répondre (Figure 4).

Le client génère une paire de clés cryptographiques et demande au processeur de lui fournir une attestation en incluant la valeur de hachage de sa clé publique et une valeur aléatoire unique envoyée par le service dans son défi. L’attestation qui lie clé publique du client, valeur aléatoire unique envoyée par le service et mesure de la VM confidentielle contenant le client est signée par le processeur. Le service fait appel à un agent d’attestation qui vérifie l’attestation en vérifiant la signature et en comparant la mesure à une valeur de référence.

Installation et tests

Afin de tester l’environnement CoCo, nous avons choisi d’utiliser un microprocesseur EPYC 9335 de la société AMD. Il met en œuvre la technologie SEV-SNP de chiffrement et de protection de l’intégrité de la mémoire vive. Nous avons assemblé une machine avec une carte mère prenant en charge ce microprocesseur (Supermicro MBD-H13SSL-NT-O) et 128 Go de mémoire vive. Il a ensuite fallu configurer le BIOS afin que les fonctionnalités souhaitées de sécurité du microprocesseur soient bien activées. Nous avons aussi opté pour la distribution Ubuntu 24.04.3 LTS du système d’exploitation Linux. Avant de pouvoir tester les fonctionnalités de sécurité du processeur, nous avons enfin dû recompiler le noyau du système d’exploitation. L’opération est en fait relativement simple grâce aux scripts fournis par AMD.

Une fois le système configuré, il est alors possible d’y installer la plateforme Docker (afin de pouvoir créer des images de conteneurs), l’interface d’exécution de conteneur containerd (incluse dans la distribution de Docker) et le système de gestion Kubernetes. La configuration de ces outils est assez délicate et sensible aux version. Plusieurs scripts permettant de faciliter cette installation sont fournis ici.

Une fois le système installé, il nous a été possible de déployer une application existante dans des conteneurs confidentiels : il suffit en fait de changer le nom de classe d’exécution utilisé par Kubernetes (runtimeClassName) dans le fichier YAML de configuration de Kubernetes pour l’une des classes de CoCo (e.g., kata-qemu-snp). Bien sûr ce changement simple ne suffit pas à bénéficier des fonctionnalités de sécurité de CoCo. Il est nécessaire de modifier le cycle de production afin d’ajouter les étapes suivantes :

• Chiffrement de l’image du conteneur
• Signature de l’image du conteneur
• Mise à disposition des clés de chiffrement et de signature

Une fois l’image du conteneur créée de la manière habituelle, par exemple avec docker build, celle-ci peut être chiffrée avec l’outil skopeo qui prend en charge différents algorithmes : JWE (RFC7516), PGP (RFC4880), et PKCS7 (RFC2315). Cette image chiffrée peut ensuite être signée avec l’outil cosign et enfin chargée sur un registre d’images.

Au moment du lancement du conteneur, les composants CoCo inclus dans la machine virtuelle confidentielle devront pouvoir vérifier la signature et déchiffrer son image. Pour cela, il est nécessaire de mettre à disposition les clé requises. C’est là que le système de médiation de clés intervient. Comme nous l’avons vu précédemment, celui effectue un protocole d’attestation avant de fournir les clés.

Le déploiement des conteneurs confidentiels est transparent vis-à-vis de l’utilisateur de Kubernetes. Une fois l’invocation de la commande habituelle kubectl apply, une machine virtuelle légère Kata est créée. Celle-ci doit récupérer auprès du médiateur de clés, la clé d’accès au registre d’image (si celui-ci n’est pas public), la politique de sécurité à appliquer, la clé de vérification de signature et la clé de déchiffrement de l’image. Ces informations ne sont fournies qu’après l’attestation de la machine virtuelle (voir plus haut). Les agents inclus dans la machine virtuelle peuvent alors appliquer la politique de sécurité, télécharger l’image, vérifier sa signature et la déchiffrer avant de lancer le conteneur applicatif dans la machine virtuelle.

En ce qui concerne la communication de l’application conteneurisée avec des services extérieurs, il convient d’établir des clés de chiffrement mutuellement reconnues. Une première possibilité est que le conteneur confidentiel crée une paire de clé cryptographiques à son lancement et fournisse la valeur de hachage cryptographique de cette clé publique lors de l’attestation. C’est ce qui est utilisé dans le protocole d’authentification présenté dans la Figure 4. Une autre option est de fournir la clé publique d’une autorité de certification dans l’image chiffrée-puis-signée. Le conteneur pourra alors vérifier les certificats signés par cette autorité et accepter des clés de chiffrement. Une troisième option consiste à s’appuyer sur le service de médiation de clés : celui-ci permet au conteneur de récupérer des secrets de manière sécurisée. En fonction de l’option choisie, il conviendra de modifier plus ou moins le code de l’application.

Protection vis-à-vis d’un administrateur

Que peut faire un administrateur de la machine hôte ? A priori, pas grand-chose, à part lancer le conteneur.

En effet, le mécanisme d’attestation l’empêche de substituer ou de simuler les composants de la machine virtuelle utilisée pour le lancement des conteneurs. Le chiffrement de la mémoire allouée à la machine virtuelle le bloque dans l’observation des données traitées dans la machine virtuelle et le conteneur. Le chiffrement et la signature de l’image du conteneur ne lui permettent ni de substituer un autre conteneur, ni de connaître la nature du conteneur. En supposant que l’application soit configurée pour communiquer de manière chiffrée avec les services extérieurs avec lesquelles elle doit interagir, l’administrateur ne peut pas non plus accéder aux données sensibles en observant le trafic réseau, sauf s’il a également un accès privilégié au système de création des clés. Enfin, il ne peut pas non plus interroger le conteneur via la commande kubectl exec car celle-ci peut être restreinte via une politique de sécurité (voir Figure 1).

En revanche, l’administrateur peut lire les journaux applicatifs enregistrés par Kubernetes sur l’hôte. Par conséquent, il est important que le fournisseur de la charge de travail prenne soin que son code ne divulgue pas des informations sensibles dans les messages journalisés de l’application.

Enfin, comme nous l’avons rappelé dans l’article précédent, les environnements d’exécution de confiance ne sont pas parfaits et leur modèle de sécurité ne tient généralement pas compte des attaques physiques. Dans un environnement comme le G-Cloud, leur ajout offre de nombreuses possibilités. En revanche, dans un environnement où ni SMALS, ni ses clients, ni même l’État belge n’ont le moindre contrôle technique ou juridique sur l’infrastructure, il existe des risques importants qu’il convient d’évaluer sérieusement.

Conclusion

À travers cet article et le précédent, nous avons mis en avant les avantages réels en termes de sécurité que pourraient apporter des microprocesseurs permettant de créer des environnements d’exécution de confiance au sein d’une infrastructure informatique. En particulier, leur utilisation « on-premise » permet de mieux protéger des applications conteneurisées d’administrateurs malveillants ou d’intrus et donc d’offrir des garanties encore plus fortes à nos Membres.

Plus simples d’utilisation que les méthodes cryptographiques avancées, de tels systèmes pourraient aussi nous permettre de résoudre des problèmes plus génériques que la cryptographie ou des problèmes que nous ne pouvions pas résoudre jusqu’à présent.

In een vorige blogpost hebben we de voordelen besproken van confidential containers en hun architectuur in het CoCo-project. In deze blogpost gaan we dieper in op het onderwerp door bepaalde aspecten van CoCo in detail te beschrijven en onze installatie op onze eigen hardware toe te lichten.

Containercertificering

Het gebruik van Kubernetes-pods als abstractielaag voor vertrouwelijke container-workloads introduceert diverse uitdagingen. Door hun dynamische karakter – het maken, verwijderen, updaten van de containers – en de invloed van de Kubernetesomgeving (omgevingsvariabelen, toelatingscontrollers, enz.) valt het moeilijk te garanderen dat enkel de door de gebruiker bedoelde code wordt uitgevoerd. Zo kan het injecteren van kwaadaardige variabelen of het wijzigen van de specificatie van een pod voordat deze wordt gestart, de vertrouwelijkheid in gevaar brengen.

Het CoCo-project stelt een elegante oplossing voor, namelijk het gebruik van een engine voor beveiligingsbeleid, geïntegreerd in de containerruntime-omgeving binnen de trusted execution environment (TEE), die de door de gebruiker gedefinieerde regels toepast. Deze engine kan bijvoorbeeld alleen bepaalde images of commando’s toestaan en problematische verzoeken (zoals het uitvoeren van ongeoorloofde processen) afwijzen. Figuur 1 toont een voorbeeld van zo’n beleid.

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

package agent_policy

# Seules certaines images de conteneurs peuvent être exécutées
default CreateContainerRequest := false
CreateContainerRequest if {
    every storage in input.storages {
    some allowed_image in policy_data.allowed_images
    storage.source == allowed_image
  }
}

# Seules certaines commandes peuvent être exécutées
# via ‘kubectl exec’ dans les images de conteneurs
default ExecProcessRequest := false
ExecProcessRequest if {
  input_command = concat(" ", input.process.Args)
      some allowed_command in policy_data.allowed_commands
      input_command == allowed_command
}

policy_data := {
    "allowed_commands": [
        "ls",
        "cat",
    ],
    "allowed_images": [
        "pause",
        "my-registry.be/,my-app@sha256:5ed86f469bbc40026a0235dd92e2b0b0c7ce54e3b254132e271a9b9e85d5f220
",
    ],
}

Figuur 1 – Voorbeeld van een beperkend beveiligingsbeleid voor images die kunnen worden uitgevoerd en de commando’s die in de image kunnen worden aangeroepen. Dit beleid wordt toegepast door een agent die in de vertrouwelijke VM zit.

Vier componenten van de vertrouwelijke virtuele guestmachine worden altijd gecontroleerd om te bepalen of ze nog goed werken: de firmware (bijvoorbeeld OVMF), de kernel van het besturingssysteem, de kernel commandoregel en het rootbestandssysteem (Figuur 2). Een vertrouwelijke externe entiteit, vaak Trustee genoemd, zorgt ervoor dat de vertrouwensketen versterkt wordt.

Vertrouwelijke containers hebben echter meestal initialisatiedata nodig die niet direct in de image van de virtuele machine of de toepassingscontainer kunnen worden opgenomen, zoals certificaten, adressen van certificeringsdiensten of toe te passen beveiligingsbeleidsregels. Deze data zijn weliswaar niet geheim, maar moeten wel worden beschermd tegen wijzigingen.

Deze initialisatiedata, ook wel init-data genoemd, kunnen worden opgegeven in de vorm van een woordenboek (bijv. JSON-bestanden, TOML, YAML), gecodeerd in base64 en doorgegeven aan de Kubernetes-pod via een Kubernetes annotation (Figuur 3). Om de integriteit ervan te garanderen, wordt hun cryptografische hashwaarde door de certificeringsagent (die in de vertrouwelijke virtuele machine draait) als data voor de berekening van de certificering verstrekt (dit kan worden gedaan met behulp van het veld “HostData” van SEV-SNP). Het is dan mogelijk om de initialisatiedata die naar de hostmachine zijn gestuurd voor het starten van de container te vergelijken met de hashwaarde die op het moment van de certificering is ontvangen, zodat elke wijziging tijdens de certificering op afstand kan worden gedetecteerd.

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

version = "0.1.0"
algorithm = "sha256"

[data]

# Configuration de l’agent d’attestation
"aa.toml" = '''
[token_configs]
[token_configs.kbs]
url = "${KBS_ADDRESS}"
'''

# Configuration du gestionnaire de données secrètes
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "${KBS_ADDRESS}"

[image]
authenticated_registry_credentials_uri = "kbs:///${REGISTRY_AUTH_KBS_PATH}"
image_security_policy_uri = "${SECURITY_POLICY_KBS_URI}"
'''

# Politique de sécurité restreignant l’environnement du conteneur
"policy.rego"= '''
[Voir Figure 1 ci-dessus]
'''

Figuur 3 – Voorbeeld van initialisatiedata die (in gecodeerde vorm) via een Kubernetes-annotatie aan de CoCo-guestagent in de vertrouwelijke virtuele machine worden geleverd.

Sleutelbeheer

Een externe sleutelbemiddelingsdienst (key broker service), die kan worden gekoppeld aan een transactionele ‘black box’, stelt de container in staat om dynamisch de resources op te halen die nodig zijn voor de werking ervan. Indien de client nog niet in het bezit is van een eerder verkregen authenticatietoken van de sleutelbemiddelingsdienst, moet hij zich eerst authenticeren, waarna de sleutelbemiddelingsdienst hem een challenge stuurt die hij moet beantwoorden (Figuur 4).

De client genereert een paar cryptografische sleutels en vraagt de processor om een certificaat te verstrekken met daarin de hashwaarde van zijn openbare sleutel en een unieke willekeurige waarde die door de dienst in zijn challenge is verzonden. Het certificaat dat de openbare sleutel van de client, de unieke willekeurige waarde die door de service is gestuurd en de meting van de vertrouwelijke VM die de client bevat aan elkaar koppelt, wordt door de processor ondertekend. De service gebruikt een certificeringsagent die het certificaat controleert door de handtekening te verifiëren en de meting te vergelijken met een referentiewaarde.

Installatie en testen

Om de CoCo-omgeving te testen, hebben we gekozen voor een EPYC 9335-microprocessor van AMD. Deze maakt gebruik van SEV-SNP-technologie voor versleuteling en bescherming van de integriteit van het RAM-geheugen. We hebben een machine geassembleerd met een moederbord dat deze microprocessor ondersteunt (Supermicro MBD-H13SSL-NT-O) en 128 GB RAM-geheugen. Vervolgens moesten we het BIOS configureren om ervoor te zorgen dat de gewenste beveiligingsfuncties van de microprocessor goed waren geactiveerd. We hebben ook gekozen voor de Ubuntu 24.04.3 LTS-distributie van het Linux-besturingssysteem. Voordat we de beveiligingsfuncties van de processor konden testen, moesten we ten slotte de kernel van het besturingssysteem opnieuw compileren. Dit is eigenlijk vrij simpel dankzij de scripts die AMD heeft meegegeven.

Eenmaal het systeem is ingesteld, kun je het Docker-platform installeren (om containerimages te maken), de containeruitvoeringsinterface containerd (inbegrepen in de Docker-distributie) en het Kubernetes-beheersysteem. Het instellen van deze tools is best lastig en afhankelijk van de versie. Er zijn verschillende scripts beschikbaar om deze installatie te vergemakkelijken.

Nadat het systeem was geïnstalleerd, konden we een bestaande toepassing in vertrouwelijke containers zetten: je hoeft alleen maar de naam van de runtimeklasse die Kubernetes gebruikt (runtimeClassName) in het YAML-configuratiebestand van Kubernetes te veranderen in een van de CoCo-klassen (bijvoorbeeld kata-qemu-snp). Natuurlijk is deze simpele wijziging niet genoeg om te profiteren van de beveiligingsfuncties van CoCo. Je moet de productiecyclus aanpassen om de volgende stappen toe te voegen:

• Versleuteling van de containerimage
• Ondertekening van de containerimage
• Beschikbaar stellen van versleutelings- en ondertekeningssleutels

Zodra de containerimage op de gebruikelijke manier is gemaakt, bijvoorbeeld met docker build, kan deze worden versleuteld met de tool skopeo, die verschillende algoritmen ondersteunt: JWE (RFC7516), PGP (RFC4880) en PKCS7 (RFC2315). Deze versleutelde image kan vervolgens worden ondertekend met de tool cosign en ten slotte worden geüpload naar een imageregister.

Bij het opstarten van de container moeten de CoCo-componenten in de vertrouwelijke virtuele machine de handtekening kunnen verifiëren en de image kunnen ontsleutelen. Hiervoor moeten de benodigde sleutels beschikbaar worden gesteld. Hier komt het sleutelbemiddelingssysteem om de hoek kijken. Zoals we eerder hebben gezien, voert dit systeem een certificeringsprotocol uit voordat het de sleutels verstrekt.

De implementatie van confidential ccontainers is transparant voor de gebruiker van Kubernetes. Zodra het gebruikelijke commando kubectl apply wordt aangeroepen, wordt een lichte Kata-virtuele machine aangemaakt. Deze moet bij de sleutelbemiddelaar de toegangssleutel tot het imageregister (als dit niet openbaar is), het toe te passen beveiligingsbeleid, de sleutel voor handtekeningverificatie en de sleutel voor het ontsleutelen van de image ophalen. Deze informatie wordt pas verstrekt nadat de virtuele machine is geverifieerd (zie hierboven). De agents in de virtuele machine kunnen dan het beveiligingsbeleid toepassen, de image downloaden, de handtekening controleren en deze decoderen voordat de toepassingscontainer in de virtuele machine wordt gestart.

Wat betreft de communicatie van de gecontaineriseerde toepassing met externe diensten, moeten wederzijds erkende versleutelingssleutels worden ingesteld. Een eerste mogelijkheid is dat de vertrouwde container bij het opstarten een cryptografisch sleutelpaar aanmaakt en de cryptografische hashwaarde van deze openbare sleutel bij de certificering verstrekt. Dit wordt gebruikt binnen het authenticatieprotocol dat in Figuur 4 wordt beschreven. Een andere optie is om de openbare sleutel van een certificeringsinstantie in de versleutelde en vervolgens ondertekende image te verstrekken. De container kan dan de certificaten checken die deze autoriteit heeft ondertekend en de encryptiesleutels aanvaarden. Een derde optie bestaat erin om te steunen op de sleutelbemiddelingsdienst: hiermee kan de container op een veilige manier geheimen ophalen. Afhankelijk van de gekozen optie moet de code van de toepassing al dan niet worden aangepast.

Bescherming tegen een beheerder

Wat kan een beheerder van de hostmachine doen?  In principe niet veel, behalve de container opstarten.

Het certificeringsmechanisme zorgt er namelijk voor dat hij niets kan vervangen of simuleren wat betreft de onderdelen van de virtuele machine die wordt gebruikt om de containers te starten. Door de versleuteling van het geheugen dat aan de virtuele machine is toegewezen, heeft hij geen toegang tot de data die in de virtuele machine en de container worden verwerkt. Door de versleuteling en ondertekening van de containerimage kan hij geen andere container vervangen of de aard van de container achterhalen. In de veronderstelling dat de toepassing geconfigureerd is om versleuteld te communiceren met externe diensten waarmee ze moet interageren, kan de beheerder ook geen toegang krijgen tot gevoelige data door het netwerkverkeer te observeren, tenzij hij ook bevoorrechte toegang heeft tot het systeem voor het aanmaken van sleutels. Ten slotte kan hij de container ook niet ondervragen via het commando kubectl exec, omdat het kan worden beperkt door een beveiligingsbeleid (zie Figuur 1).

De beheerder kan daarentegen de toepassingslogboeken lezen die door Kubernetes op de host zijn opgeslagen. Daarom is het belangrijk dat de workload provider ervoor zorgt dat zijn code geen gevoelige informatie onthult in de gelogde berichten van de toepassing.

Tot slot, zoals we in de vorige blogpost al stelden, zijn vertrouwde uitvoeringsomgevingen niet perfect en houdt hun beveiligingsmodel meestal geen rekening met fysieke aanvallen. In een omgeving zoals de G-Cloud biedt de toevoeging ervan tal van mogelijkheden. In een omgeving waar echter noch SMALS, noch haar klanten, noch zelfs de Belgische Staat enige technische of juridische controle hebben over de infrastructuur, zijn er aanzienlijke risico’s die serieus moeten worden geëvalueerd.

Conclusie

In deze blogpost en de vorige hebben we de echte voordelen belicht op het gebied van beveiliging die microprocessors kunnen bieden om “vertrouwde uitvoeringsomgevingen” binnen een IT-infrastructuur te creëren. Vooral het “on-premise” gebruik ervan  maakt het mogelijk om gecontaineriseerde toepassingen beter te beschermen tegen kwaadwillige beheerders of indringers en zo onze leden nog meer garanties te bieden.

Omdat ze eenvoudiger in gebruik zijn dan geavanceerde cryptografische methoden, kunnen dergelijke systemen ons ook helpen om meer generieke problemen op te lossen dan met cryptografie alleen, of problemen die we tot nu toe simpelweg niet konden oplossen.

Wat als je systeembeheerders toegang zouden hebben tot je gevoelige data zonder dat je het weet? Confidential Computing biedt een oplossing: data isoleren, zelfs voor degenen die de infrastructuur beheren. Maar hoe?

Confidential Computing omvat een geheel van technologieën waarmee gevoelige data zodanig worden beschermd dat ze niet hoeven te worden ontsleuteld om te worden verwerkt. Hoewel sommige technologieën, zoals homomorfe versleuteling, nog steeds erg complex zijn om te implementeren, zijn Trusted Execution Environments (TEE’s) inmiddels zo ver ontwikkeld dat ze kunnen worden beschouwd als belangrijke technologie bij databescherming.

Het belangrijkste doel van TEE’s is om een buffer te vormen tegen de nieuwsgierigheid van de entiteiten die de infrastructuur beheren. Technische bescherming lost echter niet alles op. Extraterritoriale wetten [1-5] en het gebruik van eigen softwarelibrary’s die door sommige IT-infrastructuurproviders worden opgelegd, kunnen deze isolatie ondermijnen.

In deze en de volgende blogpost kijken we naar de mogelijkheid om TEE’s op onze eigen infrastructuur (on-premise) te gebruiken. Het doel is drieledig: gebruikmaken van de kracht van confidential computing om data te beschermen en nieuwe toepassingen mogelijk te maken, terwijl we een zekere controle behouden over de software- en hardwarestack, en zo het vertrouwen van onze klanten versterken.

Scheiding van rollen

Laten we beginnen met een overzicht van de verschillende spelers die betrokken zijn bij de implementatie van een toepassing op een IT-infrastructuur. Hun rollen moeten strikt gescheiden zijn om de integriteit van het systeem te garanderen.

• De infrastructure operator beheert de hardware en infrastructuur (computing, storage, network) en onderhoudt de beveiligde runtime-omgevingen. Hij beheert de firmware-updates en de toewijzing van middelen, maar zou geen toegang mogen hebben tot de data of de uitgevoerde workloads.
• De orchestration operator, die dezelfde kan zijn als de infrastructure operator, is verantwoordelijk voor het beheer van de serverclusters en de implementatie van de workloads. Hij configureert de benodigde middelen voor de toepassing en houdt toezicht op de bijbehorende diensten (logging, monitoring). Ook zijn rechten zouden strikt beperkt moeten blijven om elke vorm van inbreuk op de toepassing te voorkomen, terwijl de noodzakelijke orchestratie wel mogelijk blijft.
• De workload provider ontwerpt de specificaties van de toepassingen en kiest de juiste container images, waarbij hij de conformiteit en integriteit ervan garandeert. Hij moet aan de data owners (zie hieronder) laten zien dat de gebruikte code veilig is en de privacy respecteert, zonder direct toegang te geven tot gevoelige data.
• De container image provider bouwt, ondertekent en versleutelt de container images, zodat hun herkomst en veiligheid gegarandeerd zijn. Hij verstrekt de verificatie en decryptiesleutel. Zijn samenwerking met de toepassingsprovider is cruciaal om de softwareketen te garanderen en ervoor te zorgen dat de geïmplementeerde code precies dezelfde is als de geauditeerde code.
• Ten slotte bezit de data owner de data die door de toepassingen worden verwerkt en eist hij de vertrouwelijkheid en integriteit ervan. Hij vertrouwt op de code van de toepassing (de container) en de cryptografische bewijzen die door de microprocessor worden geleverd, waardoor infrastructure en orchestration operators buiten zijn vertrouwensbereik vallen. Hij kan extra controles opleggen om ervoor te zorgen dat zijn data niet zichtbaar zijn voor of gemanipuleerd worden door onbevoegde personen.

De relaties tussen deze spelers brengen specifieke uitdagingen met zich mee: de data owner moet bijvoorbeeld kunnen vertrouwen op de code van de containers (geleverd door de workload provider) om zijn data te verwerken, terwijl hij deze tegelijkertijd moet beschermen tegen andere spelers, zoals de infrastructure of orchestration operator. Met name de beheerders van deze operators mogen in geen geval toegang hebben tot de data die door de containers worden verwerkt.

Betrouwbare runtime-omgeving

Met TEE’s kan een technische barrière worden gecreëerd die het vertrouwen van de data owner in de toepassingscontainer versterkt. We hebben al uitvoerig uitgelegd hoe ze werken en wat hun voor- en nadelen zijn in een technisch rapport [6] en blogposts [7], [8]. Hier gaan we even de belangrijkste punten herhalen alvorens we de technologische keuzes voor een implementatie op onze onderzoeksinfrastructuur voorstellen.

Het goed functioneren van TEE’s hangt af van de hardware. Sommige moderne microprocessors maken het mogelijk om een deel van het RAM-geheugen dat is toegewezen aan een specifieke virtuele machine (VM) te reserveren en te versleutelen. Zo zal een beheerder van de hostmachine, zelfs met de hoogste privileges, alleen versleutelde data zien als hij dit geheugengebied probeert te inspecteren. Hoewel er aanvallen via side-channels bestaan (bijv. [9]), vereisen deze vanwege hun complexiteit doorgaans langdurige fysieke toegang en de toevoeging van kwaadaardige hardwarecomponenten, waardoor ze in de praktijk uiterst moeilijk uit te voeren zijn.

Opdat de data owner er zeker van kan zijn dat zijn toepassing in een veilige omgeving draait, gebruikt hij het certificeringsmechanisme. Dit proces genereert een cryptografische handtekening van de inhoud van het geheugen van de VM op het moment dat deze wordt opgestart. Deze handtekening wordt gecertificeerd door de fabrikant van de microprocessor.

Dit proces heeft zijn beperkingen, vooral als de infrastructure operator een buitenlandse onderneming is (bijvoorbeeld Amazon AWS, Google Cloud of Microsoft Azure) die zijn eigen libraries in de VM oplegt om bijvoorbeeld de juiste hardware-abstractielaag te bieden.

Dit heeft ons ertoe aangezet om dit soort hardware op onze eigen infrastructuur binnen het onderzoekslabo te testen, in afwachting van de mogelijkheid om dit op een dag op G-Cloud toe te passen. Het voordeel hiervan is dat een klant van SMALS een toepassingscontainer op een veilige manier kan gebruiken, zonder dat een beheerder van SMALS toegang heeft tot de inhoud van de container.

Maar het nut van TEE’s gaat verder dan alleen bescherming tegen beheerders. Het opent de deur naar andere toepassingen.

Use case

Een eerste voorbeeld is te vinden in de Europese infrastructuur voor digitale gezondheidsdiensten (eHDSI). Daar kunnen zorgverleners in het land waar de behandeling plaatsvindt de relevante gezondheidsdata van de patiënt opvragen in het land waar de patiënt is aangesloten. Technisch gezien wordt de aanvraag via de gateway van het nationale contactpunt voor gezondheidszorg (NCPeH) van het land waar de onverwachte gezondheidsgebeurtenis plaatsvindt, doorgestuurd naar het land waar de patiënt is aangesloten. De gevraagde info moet dan worden opgehaald uit de nationale infrastructuur van het land van aansluiting, vertaald naar het Engels en getranscodeerd (de gezondheidsdata worden omgezet van het nationale coderingssysteem naar het algemeen aanvaarde coderingssysteem, bijvoorbeeld van het FHIR– of KMEHR-formaat naar CDA), en vervolgens teruggestuurd en gepresenteerd worden aan de zorgverlener in het land van behandeling. Vanwege het gevoelige karakter van de data moeten deze van begin tot eind worden versleuteld, vanaf de gegevensbron op de infrastructuur van het land van aansluiting tot aan de zorgverlener in het land van behandeling. In de praktijk is dit nog niet mogelijk vanwege de grote verschillen tussen de Europese landen. Het zou echter op zijn minst mogelijk moeten zijn om te garanderen dat de data versleuteld en ontoegankelijk blijven voor alle gebruikers of beheerders tussen de bron van de data en de uitgang van de NCPeH-gateway. Een mogelijkheid is dan om TEE’s te gebruiken voor het vertalen en transcoderen van de data.

Een ander voorbeeld van het gebruik van TEE’s is de beveiligde samenwerking tussen entiteiten die hun ruwe data niet willen delen. In de onderwijs- en werkgelegenheidssector heeft een experiment van Bogdanov et al. in Estland [10] de kracht van confidential computertechnieken aangetoond. De auteurs van deze studie wilden achterhalen of werken naast een hogere opleiding ertoe leidt dat je je diploma niet op tijd behaalt – een vraag die vooral belangrijk is voor de sector van de informatie- en communicatietechnologie (ICT) in Estland. Om deze probleemstelling te beantwoorden zonder de privacy van persoonlijke data in gevaar te brengen, hebben de onderzoekers de onderwijsregisters van het ministerie van Onderwijs en Onderzoek gecombineerd met de data van de belastingdienst, dankzij een speciale techniek van confidential computing. Maar een simpelere variant met een TEE zou net zo goed hebben gewerkt voor de analyse, terwijl de fiscale vertrouwelijkheid en databescherming gewaarborgd bleven.

CoCo

Om TEE’s te gebruiken in onze eigen onderzoeksinfrastructuur bestaan er verschillende softwareoplossingen. We hebben gekozen voor het project “Confidential Containers (CoCo)“, waarvan de broncode vrij toegankelijk is. Dit project zorgt voor een goede isolatie van de toepassingscontainers en ondersteunt het certificeringsmechanisme op een transparante manier, terwijl de flexibiliteit van de implementatie en de compatibiliteit met het Kubernetes-platform waarop het is gebaseerd, behouden blijven. Elke Kubernetes-pod is geïsoleerd in een zeer lichte Confidential Virtual Machine, om te garanderen dat alleen geautoriseerde applicaties toegang hebben tot gevoelige gegevens.

CoCo’s bevatten naast de toepassing zelf enkele noodzakelijke softwarecomponenten. Deze maken het mogelijk om de uit te voeren containerimage te downloaden, de verificatie van de certificering te vergemakkelijken en bepaalde beveiligingsbeleidsregels toe te passen. Hun programmeerinterface is relatief klein, vooral vergeleken met een oplossing waarbij een hele Kubernetes-node in een Confidential Virtual Machine wordt geplaatst. Bovendien is de image van de guest-VM statisch en generiek voor alle workloads en zelfs platforms, waardoor het eenvoudiger is om veiligheidsgaranties te bieden. Tegelijkertijd is het makkelijk om dingen te delen tussen containers in dezelfde Kubernetes-pod. De naamruimte van het netwerk van de pod blijft bijvoorbeeld binnen de confidential VM, waardoor de containers daarin zonder extra kosten vertrouwelijk met elkaar kunnen communiceren.

CoCo is gebaseerd op Kata-containers, een ander open source-project, waarmee Kubernetes-pods kunnen worden uitgevoerd binnen zeer lichte Confidential Virtual Machines (zie Figuur 1). CoCo voegt echter twee cruciale componenten toe om vertrouwelijkheid en veiligheid te garanderen (zie Figuur 2).

• De eerste heeft te maken met het ophalen van containerimages: deze worden meestal gedownload door de Kubernetes-hoofdnode met behulp van een Container Runtime Interface (CRI) zoals “containerd”, waardoor de images via het bestandssysteem zichtbaar worden voor de hostmachine. Met CoCo worden de images binnen de Confidential Virtual Machine ontsleuteld en uitgepakt, vandaar de noodzaak van de bovengenoemde componenten.
• Het tweede onderdeel is het certificaat, dat, zoals we al hebben gezien, essentieel is voor het opzetten van een betrouwbare uitvoeringsomgeving. Om bijvoorbeeld een image te ontsleutelen, dient de guest de geheime ontsleutelingssleutel te kunnen verkrijgen, maar deze wordt alleen verstrekt als de guest zijn authenticiteit kan aantonen. Dit is de rol van twee componenten die steunen op een zogenaamd “Trustee”-systeem, dat buiten de virtuele machine staat en uit twee diensten bestaat: een certificeringsdienst om de vertrouwde runtime te valideren en een key mediation-dienst om de geheime middelen te leveren die de virtuele machine en de toepassing nodig hebben.

CoCo levert dus de basis voor het bouwen van confidential toepassingscontainers door het mogelijk te maken deze containers binnen confidential virtuel machines uit te voeren, waarbij de geëncrypteerde en ondertekende images van de containers, de verzegelde geheimen en andere kenmerken worden beheerd. Elke container of groep containers van dezelfde toepassing kan worden toegewezen aan een confidential virtuele machine, waarbij niet alleen de werklast wordt meegenomen, maar ook processen waarmee de toepassing bepaalde beveiligingsdiensten kan aanroepen.

Alles buiten de confidential VM op de host wordt als onbetrouwbaar beschouwd, inclusief de kubelet-tool, de runtime-interface van de containers en de kernel van het besturingssysteem van de host. De uitwisseling van informatie tussen vertrouwde en niet-vertrouwde contexten wordt streng gecontroleerd, met name via dynamische en configureerbare beveiligingsbeleidsregels. Ten slotte wordt de Kubernetes-orkestratie zelf als niet-vertrouwd beschouwd, waardoor de garanties met betrekking tot de planning of de volgorde van uitvoering van de workloads beperkt zijn, met uitzondering van de implementatie ervan in een geauthenticeerde enclave.

Conclusie

Confidential containers maken deel uit van een algemene beveiligingsaanpak, waarbij certificering, verificatie van images en best practices in de softwaretoeleveringsketen worden gecombineerd. Ze maken het mogelijk om use cases eenvoudiger te verwerken dan geavanceerde cryptografie (confidential collaboration, private set intersection, geavanceerde pseudonimisering, enz.). Puristen kunnen natuurlijk aanvoeren dat een oplossing op basis van confidential containers minder veilig is, maar in de praktijk zal deze waarschijnlijk volstaan in een on-premise omgeving, des te meer omdat het veel aspecten vereenvoudigt zodra het eenmaal is geïmplementeerd.

In de volgende blogpost gaan we dieper in op de installatie en het gebruik van confidential CoCo’s.

Referenties

[1]        C. Bômont, “Strategic Brief no.70 – 2024 – Extension of the FISA Law European ‘digital sovereignty’ far from American concerns – IRSEM”, Institut de Recherche Stratégique de l’Ecole Militaire. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, “Europeans, forget the US Cloud Act… worry about FISA instead (!)”. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        Paul Kunert, “Microsoft exec admits it ‘cannot guarantee’ data sovereignty”. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[4]        M. Rochefort, “Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française”, clubic.com. Geraadpleegd: 9 februari 2026. [Online]. Beschikbaar op: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[5]        D. Deridder, “Understanding Sovereignty: Who Rules your Cloud?”, Dirk Deridder. Geraadpleegd: 1 juli 2025. [Online]. Beschikbaar op: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[6]        F. A. P. Petitcolas, “Informatique confidentielle – État de l’art”, Smals Research, jul. 2023. [Online]. Beschikbaar op: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, “Introduction à l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, “Outils pour l’informatique confidentielle”, Smals Research. Geraadpleegd: 9 januari 2026. [Online]. Beschikbaar op: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, en J. V. Bulck, “Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing”, gepresenteerd bij 47th IEEE Symposium on Security and Privacy (S&P), mei 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, en R. Talviste, “Students and taxes: a Privacy-preserving study using secure computation”, Proc. Priv. Enhancing Technol., vol. 2016, nr. 3, pp. 117-135, jul. 2016, doi: 10.1515/popets-2016-0019.

Et si vos administrateurs système pouvaient accéder à vos données sensibles sans que vous le sachiez ? L’informatique confidentielle propose une solution : isoler les données, même de ceux qui gèrent l’infrastructure. Mais comment ?

L’informatique confidentielle regroupe un ensemble de technologies permettant de protéger les données sensibles de telle sorte qu’il n’est pas nécessaire de les déchiffrer pour les traiter. Alors que certaines, comme le chiffrement homomorphe, sont encore très complexes à mettre en œuvre, les environnements d’exécution de confiance (EEC aussi appelés « trusted execution environment (TEE) » en anglais) ont atteint une bonne maturité, permettant de les considérer comme des composants importants dans la protection des données.

L’objectif premier des EEC est de dresser un rempart contre la curiosité des entités contrôlant l’infrastructure. Toutefois la protection technique ne résout pas tout. Les lois extraterritoriales [1-5] et l’usage de bibliothèques logicielles propriétaires imposées par certains fournisseurs d’infrastructure informatique peuvent fragiliser cette isolation.

Dans cet article et le suivant, nous nous penchons sur la possibilité de déployer des EEC sur notre propre infrastructure (on-premise). L’objectif est triple : bénéficier de la puissance de l’informatique confidentielle pour protéger les données et permettre de nouveaux cas d’usage, tout en gardant un certain contrôle sur la pile logicielle et matérielle, et ainsi renforcer la confiance de nos clients.

Séparation des rôles

Commençons par rappeler les différents acteurs qui interviennent lors du déploiement d’une application sur une infrastructure informatique. Leurs rôles doivent être hermétiquement séparés pour garantir l’intégrité du système.

• L’opérateur d’infrastructure gère le matériel et les infrastructures (calcul, stockage, réseau), incluant la maintenance des environnements d’exécution de confiance. Il contrôle les mises à jour des micrologiciels et l’allocation des ressources, mais ne devrait pas pouvoir accéder aux données ou aux charges de travail exécutées.
• L’opérateur d’orchestration, qui peut être le même que l’opérateur d’infrastructure, est responsable de la gestion des grappes de serveurs et du déploiement des charges de travail. Il configure les ressources nécessaires aux applications et supervise les services associés (journalisation, surveillance). Ses privilèges devraient aussi être strictement limités afin d’éviter toute intrusion dans l’application, tout en permettant l’orchestration essentielle.
• Le fournisseur de la charge de travail conçoit les spécifications des applications et choisit les images de conteneurs adaptées, en garantissant leur conformité et leur intégrité. Il doit prouver aux propriétaires de données (voir ci-dessous) que le code utilisé est sécurisé et respectueux de la confidentialité, sans pour autant accéder directement aux données sensibles.
• Le fournisseur d’images de conteneurs construit, signe et chiffre les images conteneurs, assurant leur provenance et leur sécurité. Il fournit les clés de vérification et de déchiffrement. Sa collaboration avec le fournisseur de l’application est cruciale pour garantir la chaîne d’approvisionnement logicielle et assurer que le code déployé est exactement celui qui a été audité.
• Enfin, le propriétaire des données détient les données traitées par les applications et exige leur confidentialité et leur intégrité. Il accorde sa confiance au code de l’application (le conteneur) et aux preuves cryptographiques fournies par le microprocesseur, excluant de fait les opérateurs d’infrastructure et d’orchestration de son périmètre de confiance. Il peut imposer des vérifications supplémentaires pour s’assurer que ses données ne sont ni visibles ni manipulées par des personnes non autorisées.

Les relations entre ces acteurs soulèvent des enjeux spécifiques : le propriétaire des données, par exemple, doit pouvoir faire confiance au code des conteneurs (fournis par le fournisseur de la charge de travail) pour traiter ses données, tout en protégeant celles-ci contre les autres acteurs comme l’opérateur d’infrastructure ou l’opérateur d’orchestration. Notamment les administrateurs de ces opérateurs ne devraient en aucun cas pouvoir avoir accès aux données traitées par les conteneurs.

Environnement d’exécution de confiance

Les EEC permettent de créer une barrière technique renforçant la confiance du propriétaire des données dans le conteneur applicatif. Nous avons déjà expliqué en détail leur fonctionnement ainsi que leurs avantages et inconvénients dans un rapport technique [6] et des articles de blogues [7], [8]. Dans cette section nous en rappelons les points clés avant de présenter des choix technologiques pour une mise en œuvre sur notre infrastructure de recherche.

Le bon fonctionnement des EEC réside dans le matériel. Certains micro-processeurs modernes permettent de réserver et de chiffrer une portion de la mémoire vive (RAM) dédiée à une machine virtuelle (VM) spécifique. Ainsi, un administrateur de la machine hôte, même avec les privilèges les plus élevés, ne verra que des données chiffrées s’il tente d’inspecter cette zone mémoire. Bien que des attaques par canaux auxiliaires existent (e.g., [9]), leur complexité nécessite généralement un accès physique prolongé et l’ajout de composants matériels malveillants, ce qui les rend extrêmement difficiles à exécuter.

Pour que le propriétaire des données soit certain que son application s’exécute dans un environnement sain, il utilise le mécanisme d’attestation. Ce processus génère une signature cryptographique du contenu de la mémoire de la VM au moment de son lancement. Cette signature est certifiée par le fabricant du micro-processeur.

Ce processus a des limites notamment dans le cas où l’opérateur d’infrastructure est une société étrangère (e.g., Amazon AWS, Google Cloud ou Microsoft Azure) qui impose ses bibliothèques propriétaires dans la VM afin, par exemple, de fournir la bonne couche d’abstraction matérielle.

Cela nous a conduit à vouloir tester ce type de technologie dans notre laboratoire de recherche sur notre propre matériel, anticipant la possibilité de le faire un jour sur G-Cloud. L’intérêt est de permettre à un client de SMALS de faire fonctionner un conteneur applicatif de manière sécurisée, sans qu’un administrateur de SMALS puisse accéder au contenu du conteneur.

Mais l’utilité des EEC dépasse la simple protection contre les administrateurs. Elle ouvre la voie à d’autres cas d’usage.

Cas d’usage

Un premier exemple se trouve dans le cadre de l’infrastructure européenne de services numériques de santé en ligne (eHDSI). Là, les professionnels de santé d’un pays de traitement peuvent demander les données de santé pertinentes du patient au pays d’affiliation de celui-ci. D’un point de vue technique, la demande est transmise par la passerelle du point de contact national pour la santé (NCPeH) du pays où l’événement de santé imprévu se produit, au pays d’affiliation. Les informations demandées doivent ensuite être récupérées auprès de l’infrastructure nationale du pays d’affiliation, traduites en anglais et transcodées (les données de santé sont transformées du système de codification national vers le système de codification communément accepté, par exemple du format FHIR ou KMEHR vers CDA), puis renvoyées et présentées au professionnel de santé du pays de traitement. Compte tenu du caractère sensible des données, les données devraient être chiffrées de bout en bout, depuis la source de données sur l’infrastructure du pays d’affiliation jusqu’au prestataire de soins de santé dans le pays de traitement. Dans la pratique, cela n’est pas encore possible en raison des différences importantes entre les pays européens. Cependant, il devrait être possible, au minimum, de garantir que les données restent chiffrées et inaccessibles à tout utilisateur ou administrateur entre la source des données et la sortie de la passerelle NCPeH. Une possibilité consiste alors à utiliser des EEC pour effectuer la traduction et le transcodage des données.

Un autre exemple d’utilisation des EEC est la collaboration sécurisée entre entités ne souhaitant pas partager leurs données brutes. Dans le secteur de l’éducation et de l’emploi, une expérience menée par Bogdanov et al en Estonie [10] a montré la puissance des techniques d’informatique confidentielle. Les auteurs de cette étude ont cherché à déterminer si le fait de travailler pendant les études supérieures était corrélé à un échec d’obtention du diplôme dans les délais impartis – une question particulièrement cruciale pour le secteur des technologies de l’information et de la communication en Estonie. Pour répondre à cette problématique sans compromettre la confidentialité des données personnelles, les chercheurs ont combiné les registres d’éducation du ministère de l’Éducation et de la Recherche avec les données de paiements d’impôts du Conseil des taxes et des douanes, grâce à une technique particulière d’informatique confidentielle. Mais une variante plus simple avec un EEC eût été tout aussi efficace pour l’analyse tout en respectant le secret fiscal et la protection des données.

CoCo

Plusieurs solutions logicielles sont disponibles pour mettre à profit les EEC sur notre propre infrastructure de recherche. Nous avons choisi d’utiliser le projet « Confidential Containers (CoCo) » dont le code source est ouvert. Il permet en effet une bonne isolation des conteneurs applicatifs et prend en charge le mécanisme d’attestation de manière transparente, tout en préservant la flexibilité de déploiement et la compatibilité avec la plateforme Kubernetes sur laquelle il s’appuie. Chaque capsule Kubernetes est isolée dans une machine virtuelle confidentielle très légère, de manière à garantir que seules les applications autorisées peuvent accéder aux données sensibles.

Les conteneurs CoCo contiennent quelques composants logiciels nécessaires en plus de l’application elle-même. Ceux-ci permettent de télécharger l’image du conteneur à exécuter, de faciliter la vérification de l’attestation et d’appliquer certaines politiques de sécurité. Leur interface de programmation est relativement petite, notamment par rapport à une solution où tout un nœud Kubernetes serait mis à l’intérieur d’une machine virtuelle confidentielle. En outre, l’image de la machine virtuelle invitée est statique et générique sur toutes les charges de travail et même les plateformes, permettant ainsi d’assurer plus simplement des garanties de sécurité. En même temps, le partage entre les conteneurs dans la même capsule Kubernetes est aisé. Par exemple, l’espace de noms du réseau de la capsule ne quitte pas la machine virtuelle confidentielle, autorisant ainsi les conteneurs qu’elle contient à communiquer de manière confidentielle sans coût supplémentaire.

CoCo s’appuie sur les conteneurs Kata, un autre projet de logiciel libre, qui permet de faire fonctionner des capsules Kubernetes à l’intérieur de machines virtuelles confidentielles très légères (voir Figure 1). CoCo ajoute cependant deux composants cruciaux afin d’assurer confidentialité et sécurité (voir Figure 2).

• Le premier concerne la récupération des images des conteneurs : celles-ci sont habituellement téléchargées par le nœud principal Kubernetes avec l’aide d’une interface d’exécution de conteneur (CRI) comme « containerd, » exposant ainsi les images à la machine hôte à travers le système de fichiers. Avec CoCo, les images sont déchiffrées, et décompactées à l’intérieur de la machine virtuelle confidentielle, d’où la nécessité des composants susmentionnés.
• Le second est l’attestation qui est, comme nous l’avons déjà vu, indispensable à l’établissement d’un environnement d’exécution de confiance. Par exemple, afin de déchiffrer une image, l’invité doit pouvoir obtenir la clé secrète de déchiffrement, mais celle-ci n’est fournie que si l’invité peut prouver son authenticité. C’est le rôle de deux composants qui s’appuient sur un système appelé « Trustee, » extérieur à la machine virtuelle et composé de deux services : un service d’attestation permettant de valider la base d’exécution de confiance et un service de médiation de clés permettant de fournir les ressources secrètes nécessaires à la machine virtuelle et à l’application.

CoCo fournit donc les bases pour construire des conteneurs applicatifs confidentiels en permettant d’exécuter ces conteneurs à l’intérieur de machines virtuelles confidentielles, gérant les images chiffrées et signées des conteneurs, les secrets scellés, et d’autres caractéristiques. Chaque conteneur ou groupe de conteneurs de la même application peut être assigné à une machine virtuelle confidentielle, incluant non seulement la charge de travail, mais aussi des processus permettant à l’application d’appeler certains services de sécurité.

Tout ce qui se trouve en dehors de la machine virtuelle confidentielle sur l’hôte est considéré comme non fiable, y compris l’outil kubelet, l’interface d’exécution de conteneurs et le noyau du système d’exploitation de l’hôte. Les échanges d’informations entre les contextes de confiance et non fiables sont strictement contrôlés, notamment via des politiques de sécurité dynamiques et configurables. Enfin, l’orchestration Kubernetes elle-même est considérée comme non fiable, limitant les garanties sur le planning ou l’ordre d’exécution des charges de travail, à l’exception de leur déploiement dans une enclave authentifiée.

Conclusion

Les conteneurs confidentiels s’inscrivent dans une démarche globale de sécurité, combinant attestation, vérification des images et bonnes pratiques de la chaîne d’approvisionnement logicielle. Ils permettent de traiter des cas d’usage plus simplement que la cryptographie avancée (collaboration confidentielle, intersection privée d’ensemble, pseudonymisation avancée, etc.). Certes les puristes argueront qu’une solution basée sur des conteneurs confidentiels est moins sûre, mais dans la pratique, elle sera probablement suffisante dans un cadre « on-premise », d’autant plus qu’elle simplifie beaucoup d’aspect une fois qu’elle est mise en place.

Dans l’article suivant, nous entrerons plus en détails dans l’installation et l’utilisation des conteneurs confidentiels CoCo.

Références

[1]        C. Bômont, « Strategic Brief no.70 – 2024 – Extension of the FISA Law European “digital sovereignty” far from American concerns – IRSEM », Institut de Recherche Stratégique de l’Ecole Militaire. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.irsem.fr/en/strategic-brief-no-70-2024

[2]        D. Michels, « Europeans, forget the US Cloud Act… worry about FISA instead (!) ». Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://www.linkedin.com/pulse/europeans-forget-us-cloud-act-worry-fisa-instead-dave-michels-anjze

[3]        M. Rochefort, « Microsoft face au Sénat : l’aveu qui fait vaciller la souveraineté numérique française », clubic.com. Consulté le: 9 février 2026. [En ligne]. Disponible sur: https://www.clubic.com/actualite-573438-microsoft-face-au-senat-l-aveu-qui-fait-vaciller-la-souverainete-numerique-francaise.html

[4]        D. Deridder, « Understanding Sovereignty: Who Rules your Cloud? », Dirk Deridder. Consulté le: 1 juillet 2025. [En ligne]. Disponible sur: https://dirkderidder.wordpress.com/2025/03/13/understanding-sovereignty-who-rules-your-cloud/

[5]        P. Kunert, « Microsoft exec admits it “cannot guarantee” data sovereignty », The Register. Consulté le: 28 juillet 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/

[6]        F. A. P. Petitcolas, « Informatique confidentielle – État de l’art », Smals Research, juill. 2023. [En ligne]. Disponible sur: https://www.smalsresearch.be/publications/document?docid=269

[7]        F. A. P. Petitcolas, « Introduction à l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/introduction-a-l-informatique-confidentielle/

[8]        F. A. P. Petitcolas, « Outils pour l’informatique confidentielle », Smals Research. Consulté le: 9 janvier 2026. [En ligne]. Disponible sur: https://www.smalsresearch.be/outils-pour-linformatique-confidentielle/

[9]        J. De Meulemeester, D. Oswald, I. Verbauwhede, et J. V. Bulck, « Battering RAM: Low-cost interposer attacks on confidential computing via dynamic memory aliasing », présenté à 47th IEEE Symposium on Security and Privacy (S&P), mai 2026.

[10]      D. Bogdanov, L. Kamm, B. Kubo, R. Rebane, V. Sokk, et R. Talviste, « Students and taxes: a Privacy-preserving study using secure computation », Proc. Priv. Enhancing Technol., vol. 2016, n^o 3, p. 117‑135, juill. 2016, doi: 10.1515/popets-2016-0019.

Cet article fait suite à une première partie qui s’est penchée sur la sécurité du code généré par les outils d’IA générative (IAGén). Dans cette seconde partie, nous considérons la tâche de détecter des vulnérabilités dans du code existant et comment l’IAGén pourrait peut-être aider.

Les vulnérabilités de sécurité dans le code sont un problème récurrent affectant la plupart des logiciels et ayant un impact sur l’intégrité, la confidentialité et la disponibilité. L’utilisation de certains langages de programmation connus pour être moins susceptibles que d’autres à des problèmes classiques est recommandée (par exemple Rust plutôt que C). L’examen du code par d’autres programmeurs experts est aussi une méthode largement répandue. Mais l’IAGén pourrait-elle faciliter la tâche ?

Recherche de vulnérabilités

Il existe plusieurs façons de rechercher des vulnérabilités à partir du code ou du binaire et ce, de manière automatique ou manuelle, statique ou dynamique, et systématique ou exploratoire. En 2022, dans une étude très détaillée, Elder et al. [1] ont comparé plusieurs de ces méthodes sur une application d’ampleur dans le domaine médical : OpenMRS. Celle-ci contient près de 4 millions de lignes de code Java et JavaScript. Les auteurs font plusieurs recommandations en fonction des objectifs recherchés et des ressources (expertise, temps, équipement) disponibles et confirment une étude plus ancienne : chaque méthode de détection de vulnérabilité trouve des vulnérabilités qui n’ont pas été trouvées par d’autres méthodes. Cependant, dans leur expérimentation, la méthode manuelle exploratoire par tests d’intrusion a permis de trouver les vulnérabilités les plus dangereuses.

IAGén et analyse statique

Le Tableau 1 compare deux approches d’analyse de code : l’analyse statique (classique) et une analyse utilisant une IAGén. Selon certaines études, l’IAGén aurait commencé à montrer quelques avantages par rapport aux outils d’analyse statiques classiques.

Tableau 1 – Aperçu des principales différences et similitudes entre deux approches d’analyse du code : analyse statique et analyse avec IAGén (d’après [2]).

Par exemple, Noever [2] a étudié la performance de certaines IAGén pour identifier et rectifier des vulnérabilités dans des logiciels. Son étude portait sur divers dépôts de GitHub et comparait les IAGén avec des outils d’analyse statique. L’auteur a utilisé la requête (« prompt » en anglais) suivante :

“Act as the world’s greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.”

Les tests de l’auteur utilisent le cycle suivant pour une base de code donnée :

• Utiliser un outil d’analyse statique pour évaluer le nombre et le niveau de gravité des vulnérabilités ;
• Demander à l’IAGén d’identifier les vulnérabilités ;
• Demander à l’IAGén de corriger les vulnérabilités trouvées ;
• Utiliser l’outil d’analyse statique sur le code corrigé et comparer le nombre et le niveau de gravité des vulnérabilités trouvées.

Les résultats de l’auteur sont plutôt positifs sur la base de code choisie : l’IAGén a permis de réduire de manière significative le nombre de vulnérabilités très graves.

Performance de l’IAGén

Cependant, même les meilleurs outils utilisant l’IA pour la détection de défauts ont une précision inférieure à 70 % selon CodeXGLUE. Une étude de Steenhoek [3] rapporte que les modèles de pointe n’ont obtenu qu’une précision équilibrée de 54,5 %¹ dans leur évaluation de la détection des vulnérabilités, même pour les modèles pré-entraînés sur de grandes quantités de code source. En d’autres termes, « tous les modèles et toutes les requêtes ont donné des résultats proches de ceux des réponses aléatoires aux devinettes. » Les auteurs expliquent cela par la difficulté qu’ont les IAGén à raisonner sur la sémantique du code. Cette difficulté de raisonnement ne se limite d’ailleurs pas au code [3].

Nous avions déjà pu remarquer quelque chose de similaire lors de nos propres tests sur une base de code avec des vulnérabilités de type CWE connues : le nombre de faux-positifs² était souvent aussi important que le nombre de vrai-positifs³ lorsque nous avons demandé à différents modèles (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) d’indiquer si un fichier de code contenait des vulnérabilités potentielles. Même en envoyant une base de code entière nos résultats n’ont pas été plus concluants. En effet, Llama permet de fournir un contexte très large (10 millions de symboles), et après lui avoir fourni l’entièreté de WebGoat – un logiciel spécialement écrit avec des vulnérabilités – aucune vulnérabilité significative n’a été identifiée !

Dans une étude plus récente et plus systématique, Ullah et al. [4] montrent – en utilisant 8 modèles et 17 méthodes de requête sur 228 exemples de code – que les IAGén fournissent des réponses non déterministes, un raisonnement incorrect et infidèle, et qu’elles sont peu performantes dans des scénarios du « monde réel ». Plus grave, l’étude confirme aussi un manque de robustesse lors de la détection de vulnérabilités potentielles. De nombreuses études avaient déjà souligné que les techniques d’apprentissage automatique manquaient de robustesse aux transformations de code préservant la sémantique comme le renommage d’identifiants, l’insertion de déclarations non exécutées ou encore le remplacement de code par du code équivalent [5]. Sans grande surprise, les méthodes d’amplifications permettant à un modèle d’apprendre ce type de transformations, ne permettent d’augmenter la robustesse que pour les transformations spécifiques auxquelles le modèle a été entrainé [5].

Dans un autre exemple, plus anecdotique, Heelan [6] discute de la capacité de ChatGPT-o3 à trouver la vulnérabilité CVE-2025-37778 dans le noyau de Linux. Outre le fait que la requête envoyée par l’auteur à l’IAGén était très précise (extrait de code soigneusement sélectionné, instructions détaillées), l’IAGén n’a trouvé la vulnérabilité que 8 fois sur 100 (la même requête a été envoyée 100 fois, et seulement 8 fois l’IAGén a trouvé la vulnérabilité). Dans un autre exemple l’auteur décrit comment, par hasard, l’IAGén lui a permis de découvrir une nouvelle vulnérabilité ; là encore il a envoyé cent fois sa requête à ChatGPT et, dans une seule réponse, il a trouvé un élément le mettant sur la voie. C’est sans compter le coût environnemental et financier de l’exercice et surtout le fait que la nouvelle vulnérabilité est liée sémantiquement à la précédente.

Dès lors, on ne s’étonnera pas que l’expérience de plusieurs projets de logiciels libres tend à montrer que les bogues découverts avec l’aide de l’IAGén ont en réalité peu de valeur [7], [8].

Intégration de l’IAGén dans l’analyse statique

Afin d’améliorer la détection de vulnérabilités par une IAGén dans un échantillon de code, Yue Li et al. [9] suggèrent de rassembler le plus d’informations contextuelles possibles (p. ex., liste de dépendances et informations spécifiques à un type de vulnérabilité recherché). C’est ce qui est mis en pratique dans l’outil IRIS de Ziyang Li et al. [10].

IRIS combine l’IAGén avec l’analyse statique pour détecter les vulnérabilités de sécurité dans les logiciels tout en essayant de réduire le taux de faux positifs. Cet outil suit un processus systématique de détection des failles de sécurité :

1. Extraction de candidats potentiels pour être des sources ou des récepteurs contaminés dans les interfaces de programmation externes et internes grâce à un outil d’analyse statique.
2. Interrogation d’une IAGén pour étiqueter en tant que source ou puit (fonction vulnérable) spécifique à une classe de vulnérabilité⁴, les interfaces candidates.
3. Les sources et les puits étiquetés sont transformés en spécifications qui peuvent être introduites dans CodeQL afin d’effectuer une analyse des souillures (les variables entachées par des entrées de l’utilisateur et pouvant atteindre un puit) spécifique à une classe de vulnérabilité. Cette étape génère un ensemble de chemins de code vulnérables (ou alertes) dans le projet.
4. Enfin l’IAGén est utilisée pour réduire le nombre de faux-positifs signalés par l’analyse statique de CodeQL tout en fournissant une explication.

Nos tests de l’outil IRIS-v1⁵, sur la base de code WebGoat avec les modèles Codegen25-7b-instruct, qwen2.5-coder-7b et GPT-4 ont pu confirmer une réduction d’environ 18 % du nombre de vulnérabilités potentielles détectées, mais ce, au prix d’un grand nombre d’appels au modèle d’IAGen (1130 appels par type de CWE testé, pour une base de 259 fichiers Java).

Cet outil encore expérimental montre néanmoins une tendance plus générale de l’introduction de l’IAGén dans les outils de détection existants. C’est le cas, par exemple, de DeepCode, d’ETH Zurich, récemment intégré dans le logiciel Snyk. Il a pour ambition de permettre aux programmeurs de trouver rapidement des vulnérabilités dans leur code. Mais la convergence d’outils d’IAGén examinant du code généré par d’autres outils d’IAGén, crée des boucles de rétroaction qui pourraient s’avérer dangereuses [11].

Conclusion et recommandations

Même si quelques études ont montré que les IAGén peuvent résoudre des problèmes simples de correction de vulnérabilités (par exemple, des fuites de mémoire), on constate qu’ils rencontrent des difficultés à résoudre des défauts complexes. La plupart des études que nous avons rencontrées montrent aussi des performances incohérentes et une tendance générale à des taux élevés de faux-positifs, dans la détection des failles de sécurité, confirmant nos propres tests. Les meilleures performances de détection semblent être atteintes sur les vulnérabilités pour lesquelles les IAGén ont été entraînées. Ces observations sont confirmées par une étude systématique et extensive de Basic et Giaretta [12].

Par conséquent, avant de pouvoir utiliser l’IAGén pour la détection de vulnérabilité dans le code, il faudra attendre que des progrès importants soient faits. Pour le moment, il faut prendre conscience des limites actuelles de ces outils. Outre celles mentionnées précédemment, quelle que soit la méthode retenue, de nombreux appels à l’IAGén peuvent s’avérer être très coûteux (ou très lents s’ils sont exécutés localement sans matériel adéquat). De plus il manque encore une méthodologie scientifique solide permettant de comparer efficacement différents outils d’analyse et de mesurer l’apport objectif de l’IAGén.

Chez SMALS, par exemple, une initiative issue du fruit d’une collaboration (groupe de travail « SAST⁶ ») entre l’équipe de développement des applications & projets et celle de recherche travaille sur la performance des outils d’analyse statique et l’apport possible de l’IAGén.

Enfin, on note que CodeQL est repris par beaucoup d’études comme une base de référence pour la comparaison de l’efficacité des modèles d’IAGén à détecter des vulnérabilités. Cela n’est pas étonnant car des outils comme celui-ci ont fait leur preuve. Alors avant de se lancer tête baissée dans l’utilisation de l’IAGén pour améliorer la sécurité du code, il est probablement plus sage d’intégrer progressivement dans les indispensables revues de code habituelles, des outils d’analyse statique ou dynamique. Nul doute qu’une IAGén sera intégrée à ces outils au moment opportun.

Références

[1] S. Elder et al., « Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application », 2 août 2022, arXiv: arXiv:2208.01595. doi: 10.48550/arXiv.2208.01595.

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[3] P. Shojaee, I. Mirzadeh, K. Alizadeh, M. Horton, S. Bengio, et M. Farajtabar, « The illusion of thinking: Understanding the strengths and limitations of reasoning models via the lens of problem complexity », [En ligne]. Disponible sur: https://arxiv.org/abs/2506.06941

[4] S. Ullah, M. Han, S. Pujar, H. Pearce, A. Coskun, et G. Stringhini, « LLMs cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks », 24 juillet 2024, arXiv: arXiv:2312.12575. doi: 10.48550/arXiv.2312.12575.

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[6] S. Heelan, « How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation », Sean Heelan’s Blog. Consulté le: 12 juin 2025. [En ligne]. Disponible sur: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/

[7] T. Claburn, « AI-assisted bug reports make developers bear cost of cleanup », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

[8] C. Jones, « Curl takes action against time-wasting AI bug reports », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ Les auteurs préfèrent le score de précision équilibrée (« balanced accuracy ») au score classique F1 afin de mieux prémunir des biais potentiels du modèle évalué. Il est défini comme :

² Code déclaré contenant une vulnérabilité alors qu’il n’en contient pas.

³ Code correctement déclaré comme contenant une vulnérabilité.

⁴ Actuellement, IRIS ne prend en charge que les CWE suivants : CWE-022 (Traversée de chemin), CWE-078 (injection de commande du système d’exploitation), CWE-079 (Script inter-site) et CWE-094 (injection de code).

⁵ La version 2 a été publiée après l’écriture de cet article.

⁶ « Static application security testing »

Dit artikel is het vervolg op een eerste deel dat zich toespitste op de veiligheid van code die gegenereerd werd door generatieve AI-tools (GenAI). In het tweede deel nemen we de taak onder de loep om kwetsbaarheden in bestaande code op te sporen en zien we hoe GenAI daarbij zou kunnen helpen.

Kwetsbaarheden in code zijn een terugkerend probleem dat de meeste software treft en een impact heeft op integriteit, vertrouwelijkheid en beschikbaarheid. Er wordt aangeraden om bepaalde programmeertalen te gebruiken waarvan bekend is dat ze minder gevoelig zijn voor klassieke problemen dan andere (bijv. Rust in plaats van C). Code review door andere expertprogrammeurs is ook een veelgebruikte methode. Maar zou GenAI de taak kunnen vergemakkelijken?

Zoeken naar kwetsbaarheden

Er zijn verschillende manieren om kwetsbaarheden in code of binaire bestanden op te sporen, zowel automatisch als handmatig, statisch of dynamisch, en systematisch of verkennend. In 2022 hebben Elder et al. [1] in een zeer gedetailleerde studie verschillende van deze methoden vergeleken op een grootschalige toepassing in de medische sector: OpenMRS. Deze bevat bijna 4 miljoen regels Java- en JavaScript-code. De auteurs doen verschillende aanbevelingen op basis van de beoogde doelstellingen en de beschikbare middelen (expertise, tijd, apparatuur) en bevestigen een eerdere studie: elke methode voor het opsporen van kwetsbaarheden vindt kwetsbaarheden die met andere methoden niet zijn gevonden. In hun experiment bleek echter de handmatige verkennende methode met penetratietests de gevaarlijkste kwetsbaarheden op te sporen.

GenAI en statische analyse

Tabel 1 vergelijkt twee benaderingen van code-analyse: statische (klassieke) en een analyse die GenAI gebruikt. Volgens bepaalde studies zou GenAI enkele voordelen beginnen te vertonen ten opzichte van klassieke statische analysetools.

Tabel 1 – Overzicht van de belangrijkste verschillen en overeenkomsten tussen twee benaderingen van codeanalyse: statische analyse en analyse met GenAI (naar [2]).

Noever [2] heeft bijvoorbeeld de prestaties van bepaalde GenAI onderzocht om kwetsbaarheden in software te identificeren en te verhelpen. Zijn onderzoek had betrekking op verschillende GitHub-repository’s en vergeleek GenAI met statische analysetools. De auteur gebruikte de volgende prompt:

“Act as the world’s greatest static code analyzer for all major programming languages. I will give you a code snippet, and you will analyze the code and rewrite it, removing any identified vulnerabilities. Do not explain, just return the corrected code and format alone.”

De tests van de auteur gebruiken de volgende cyclus voor een bepaalde codebase:

• Gebruik een statische analysetool om het aantal en de ernst van de kwetsbaarheden te beoordelen;
• Vraag GenAI om de kwetsbaarheden te identificeren;
• Vraag GenAI om de gevonden kwetsbaarheden te corrigeren;
• Gebruik de statische analysetool op de gecorrigeerde code en vergelijk het aantal en de ernst van de gevonden kwetsbaarheden.

De resultaten van de auteur zijn vrij positief op basis van de gekozen codebase: GenAI heeft het aantal zeer ernstige kwetsbaarheden aanzienlijk verminderd.

Performantie van GenAI

Maar zelfs de beste tools die AI gebruiken voor foutdetectie hebben volgens CodeXGLUE een nauwkeurigheid van minder dan 70%. Een studie van Steenhoek [3] meldt dat de meest geavanceerde modellen slechts een gemiddelde nauwkeurigheid van 54,5%¹ behaalden bij het opsporen van kwetsbaarheden, zelfs voor modellen die vooraf waren getraind op grote hoeveelheden broncode. Met andere woorden: “alle modellen en alle prompts leverden resultaten op die dicht in de buurt kwamen van willekeurige antwoorden op raadsels”. De auteurs verklaren dit door de moeilijkheid die GenAI heeft om te redeneren over de semantiek van code. Deze moeilijkheid om te redeneren beperkt zich overigens niet tot code [3].

We hadden al iets soortgelijks opgemerkt tijdens onze eigen tests op een codebase met bekende CWE-kwetsbaarheden: het aantal valse positieven² was vaak even groot als het aantal echte positieven³ toen we verschillende modellen verzochten (gpt-40-mini, gpt-4o, mistral-large-2411, Llama-4-Scout, DeepSeek-V3, Qwen2.5) om aan te geven of een codebestand potentiële kwetsbaarheden bevatte. Zelfs toen we een volledige codebase verstuurden, waren onze resultaten niet overtuigender. Llama biedt namelijk een zeer grote context (10 miljoen symbolen) en nadat we het de volledige WebGoat – een speciaal geschreven softwareprogramma met kwetsbaarheden – hadden aangeleverd, werd er geen enkele significante kwetsbaarheid geïdentificeerd!

In een recentere en systematischere studie tonen Ullah et al. [4] aan – aan de hand van 8 modellen en 17 promptmethoden op 228 codevoorbeelden – dat GenAI niet-deterministische antwoorden en onjuiste en onbetrouwbare redeneringen geeft en slecht presteert in ‘realistische’ scenario’s. Erger nog, het onderzoek bevestigt ook een gebrek aan robuustheid bij het opsporen van potentiële kwetsbaarheden. Talrijke studies hadden al aangetoond dat machine learning-technieken niet robuust genoeg zijn tegen semantiekbehoudende codetransformaties, zoals het hernoemen van identifiers, het invoegen van niet-uitgevoerde declaraties of het vervangen van code door gelijkwaardige code [5]. Het is dan ook niet verwonderlijk dat amplificatiemethoden waarmee een model dit soort transformaties kan leren, alleen de robuustheid verhogen voor de specifieke transformaties waarop het model is getraind [5].

In een ander, meer anekdotisch voorbeeld bespreekt Heelan [6] het vermogen van ChatGPT-o3 om de kwetsbaarheid CVE-2025-37778 in de Linux-kernel te vinden. Afgezien van het feit dat de prompt die de auteur naar GenAI stuurde zeer nauwkeurig was (zorgvuldig geselecteerde codefragmenten, gedetailleerde instructies), vond GenAI de kwetsbaarheid slechts 8 van de 100 keer (dezelfde prompt werd 100 keer verzonden en slechts 8 keer vond GenAI de kwetsbaarheid). In een ander voorbeeld beschrijft de auteur hoe hij door toeval met behulp van GenAI een nieuwe kwetsbaarheid ontdekte; ook hier stuurde hij zijn verzoek honderd keer naar ChatGPT en vond hij in één antwoord een aanwijzing die hem op het spoor zette. Daarbij komen nog de milieukosten en financiële kosten van deze operatie en vooral het feit dat de nieuwe kwetsbaarheid semantisch verband houdt met de vorige.

Het is dan ook niet verwonderlijk dat de ervaring met verschillende vrije softwareprojecten aantoont dat bugs die met behulp van GenAI worden ontdekt, in werkelijkheid weinig waarde hebben [7], [8].

Integratie van GenAI in statische analyse

Om de detectie van kwetsbaarheden door GenAI in een codefragment te verbeteren, stellen Yue Li et al. [9] voor om zoveel mogelijk contextuele informatie te verzamelen (bijv. lijst van afhankelijkheden en specifieke informatie over een bepaald type kwetsbaarheid). Dit wordt in de praktijk gebracht in de IRIS-tool van Ziyang Li et al. [10].

IRIS combineert GenAI met statische analyse om beveiligingskwetsbaarheden in software op te sporen en tegelijkertijd het aantal valse positieven te verminderen. Deze tool volgt een systematisch proces voor het opsporen van beveiligingslekken:

1. Extractie van potentiële kandidaten voor besmette bronnen of ontvangers in externe en interne programmeerinterfaces met behulp van een statische analysetool.
2. Vragen aan een GenAI om de kandidaat-interfaces te labelen als bron of put (“sink”, kwetsbare functie) die specifiek is voor een bepaalde klasse van kwetsbaarheden⁴.
3. De gelabelde bronnen en putten worden omgezet in specificaties die in CodeQL kunnen worden ingevoerd om een analyse uit te voeren van smears (variabelen die door gebruikersinvoer zijn besmet en een put kunnen bereiken) die specifiek zijn voor een klasse van kwetsbaarheden. Deze stap genereert een reeks kwetsbare codepaden (of waarschuwingen) in het project.
4. Ten slotte wordt GenAI gebruikt om het aantal valse positieven dat door de statische analyse van CodeQL wordt gemeld te verminderen en tegelijkertijd een verklaring te geven.

Onze tests van de IRIS-v1-tool⁵, op basis van WebGoat-code met de modellen Codegen25-7b-instruct, qwen2.5-coder-7b en GPT-4, hebben een vermindering aangetoond van ongeveer 18% van het aantal gedetecteerde potentiële kwetsbaarheden, maar dit ging ten koste van een groot aantal oproepen aan het GenAI-model (1130 oproepen per getest CWE-type, voor een basis van 259 Java-bestanden).

Deze nog experimentele tool toont niettemin een meer algemene trend aan om GenAI te integreren in bestaande detectietools. Dit is bijvoorbeeld het geval bij DeepCode van ETH Zürich, dat onlangs is geïntegreerd in de Snyk-software. Het is bedoeld om programmeurs in staat te stellen snel kwetsbaarheden in hun code op te sporen. Maar de convergentie van GenAI -tools die code onderzoeken die door andere GenAI-tools is gegenereerd, creëert feedbackloops die gevaarlijk kunnen zijn[11].

Conclusie en aanbevelingen

Hoewel enkele studies hebben aangetoond dat GenAI eenvoudige problemen met kwetsbaarheden (bijvoorbeeld geheugenlekken) kan oplossen, blijkt dat het systeem moeite heeft met complexe fouten. De meeste studies die we hebben gevonden, tonen ook inconsistente prestaties en een algemene neiging tot hoge percentages valse positieven bij het opsporen van beveiligingslekken, wat door onze eigen tests bevestigd wordt. De beste detectieprestaties lijken te worden bereikt voor kwetsbaarheden waarvoor GenAI is getraind. Deze bevindingen worden bevestigd door een systematische en uitgebreide studie van Basic en Giaretta [12].

Voordat GenAI kan worden gebruikt voor het opsporen van kwetsbaarheden in code, moet er dus nog aanzienlijke vooruitgang worden geboekt. Voorlopig moeten we ons bewust zijn van de huidige beperkingen van deze tools. Naast de eerder genoemde beperkingen kan het, ongeacht de gekozen methode, erg duur zijn om GenAI veelvuldig te gebruiken (of erg traag als het lokaal wordt uitgevoerd zonder de juiste apparatuur). Bovendien ontbreekt het nog aan een solide wetenschappelijke methodologie om verschillende analysetools effectief te vergelijken en de objectieve bijdrage van GenAI te meten.

Bij SMALS is bijvoorbeeld een initiatief ontstaan ​​uit een samenwerking (werkgroep “SAST”⁶) tussen het team voor toepassings- en projectontwikkeling en het onderzoeksteam. Er wordt gewerkt aan de prestaties van statische analysetools en de mogelijke bijdrage van GenAI.

Ten slotte merken we op dat CodeQL in veel studies wordt genoemd als referentiepunt voor het vergelijken van de doeltreffendheid van GenAI-modellen bij het opsporen van kwetsbaarheden. Dat is niet verwonderlijk, aangezien tools zoals deze hun nut hebben bewezen. Voordat we ons halsoverkop op GenAI storten om de codeveiligheid te verbeteren, is het waarschijnlijk verstandiger om statische of dynamische analysetools geleidelijk te integreren in de gebruikelijke essentiële codebeoordelingen. Ongetwijfeld zal GenAI op een gepast moment in deze tools worden geïntegreerd.

Referenties

[1] S. Elder et al., « Do I really need all this work to find vulnerabilities? An empirical case study comparing vulnerability detection techniques on a Java application », 2 août 2022, arXiv: arXiv:2208.01595. doi: 10.48550/arXiv.2208.01595.

[2] D. Noever, « Can large language models find and fix vulnerable software? », août 2023, [En ligne]. Disponible sur: https://arxiv.org/abs/2308.10345

[3] P. Shojaee, I. Mirzadeh, K. Alizadeh, M. Horton, S. Bengio, et M. Farajtabar, « The illusion of thinking: Understanding the strengths and limitations of reasoning models via the lens of problem complexity », [En ligne]. Disponible sur: https://arxiv.org/abs/2506.06941

[4] S. Ullah, M. Han, S. Pujar, H. Pearce, A. Coskun, et G. Stringhini, « LLMs cannot reliably identify and reason about security vulnerabilities (yet?): A comprehensive evaluation, framework, and benchmarks », 24 juillet 2024, arXiv: arXiv:2312.12575. doi: 10.48550/arXiv.2312.12575.

[5] N. Risse et M. Böhme, « Uncovering the limits of machine learning for automatic vulnerability detection », 6 juin 2024, arXiv: arXiv:2306.17193. doi: 10.48550/arXiv.2306.17193.

[6] S. Heelan, « How I used o3 to find CVE-2025-37899, a remote zeroday vulnerability in the Linux kernel’s SMB implementation », Sean Heelan’s Blog. Consulté le: 12 juin 2025. [En ligne]. Disponible sur: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/

[7] T. Claburn, « AI-assisted bug reports make developers bear cost of cleanup », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2024/01/04/aiassisted_bug_reports_make_developers/

[8] C. Jones, « Curl takes action against time-wasting AI bug reports », The Register. Consulté le: 14 mai 2025. [En ligne]. Disponible sur: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

[9] Y. Li et al., « Everything you wanted to know about LLM-based vulnerability detection but were afraid to ask », 18 avril 2025, arXiv: arXiv:2504.13474. doi: 10.48550/arXiv.2504.13474.

[10] Z. Li, S. Dutta, et M. Naik, « IRIS: LLM-assisted static analysis for detecting security vulnerabilities », 6 avril 2025, arXiv: arXiv:2405.17238. doi: 10.48550/arXiv.2405.17238.

[11] S. Varma, A. Batchu, et N. Tyagi, « Innovation insight: AI code review tools », Gartner, G00834019, juill. 2025.

[12] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

¹ De auteurs geven de voorkeur aan de ‘balanced accuracy’-score boven de klassieke F1-score om beter te kunnen waken over mogelijke vertekeningen in het geëvalueerde model. Deze wordt als volgt gedefinieerd:

² Code die als kwetsbaar wordt aangemerkt, terwijl dat niet het geval is.

³ Code die correct als kwetsbaar wordt aangemerkt.

⁴ Momenteel ondersteunt IRIS alleen de volgende CWE‘s: CWE-022 (path traversal), CWE-078 (injectie van besturingssysteemopdrachten), CWE-079 (cross-site scripting) en CWE-094 (code-injectie).

⁵ Versie 2 werd gepubliceerd na het schrijven van dit artikel.

⁶ “Static application security testing”

De uitgebreide communicatie rond generatieve artificiële intelligentie (GenAI) en het toenemende gebruik ervan – althans in de testfase – uit angst om iets te missen of om een echte meerwaarde te bieden, roept de vraag op of het in veel domeinen nuttig is, en waarom niet, om de veiligheid van code te verbeteren. Meer bepaald: kan GenAI worden gebruikt om veiligere computercode te schrijven? Kan het helpen bij het opsporen van kwetsbaarheden in bestaande code?

In dit eerste deel geven we een antwoord op de eerste vraag. De tweede vraag komt in een ander artikel aan bod.

Menselijke aspecten

Laten we beginnen met het menselijke aspect van het gebruik van GenAI. In een gedetailleerde analyse, die ik ten zeerste aanbeveel, leggen Simkute et al. [1] de redenen uit die kunnen leiden tot een productiviteitsverlies van programmeurs die een beroep doen op GenAI. Onderzoekers hebben het onder andere over: een verglijding van de programmeurrol van productie naar evaluatie, een onnuttige herstructurering van werkstromen, onderbrekingen en de neiging van GenAI om makkelijke taken nog gemakkelijker en moeilijke taken nog moeilijker te maken. De resultaten van een studie van Perry et al. [2], van Stanford University verbazen ons dan minder. Deze tonen aan dat deelnemers die toegang hebben tot een codeerassistent op basis van een AI-model aanzienlijk minder veilige code schrijven dan deelnemers zonder toegang. Erger nog, deelnemers met toegang tot de assistent geloofden vaker dat ze veilige code schreven dan deelnemers zonder toegang. Deze observatie van Perry et al. wordt bevestigd door het werk van Klemmer et al. [3]: het onderzoeksteam ondervroeg professionele programmeurs, en hoewel zij wantrouwig staan tegenover suggesties van AI-codeerassistenten, blijkt dat zij ook hun eigen vermogen om de suggesties van deze codeerassistenten te beoordelen overschatten. Het gebruik van codeerassistenten vereist daarom de implementatie van systematische codecontrole en statische analyse [4].

Betrouwbaarheid van de voorstellen

Wat betreft de kwaliteit van de suggesties van GenAI: hoewel het over het algemeen functioneel correcte code oplevert, introduceert het ook veiligheidsproblemen [5], [6]. Khoury et al. [7] hebben met behulp van meerdere voorbeelden aangetoond dat ChatGPT 3.5 vaak code genereert die voor veiligheidsproblemen kan zorgen : slechts 5 van de 21 use cases die de auteurs bestudeerd hebben waren aanvankelijk beveiligd. ChatGPT 3.5 was in staat om beveiligde code aan te maken voor slechts 7 gevallen en dit was pas mogelijk nadat de auteurs expliciet vroegen om de code te verbeteren.

Meer recentelijk concludeerden Sivana et al. [8] dat ChatGPT als platform meer CWE-kwetsbaarheden genereerde dan de website StackOverflow. Onafhankelijk daarvan hebben Fu et al. [9] aan de hand van honderden door Copilot gegenereerde codevoorbeelden die op GitHub zijn gevonden, aangetoond dat ongeveer een derde daarvan veelvoorkomende kwetsbaarheden bevat die door de organisatie MITRE zijn geïnventariseerd (waarvan sommige tot de 25 belangrijkste behoren). De auteurs raden programmeurs daarom aan om de beste praktijken voor het gebruik van codegeneratietools te volgen en de gegenereerde codesuggesties altijd te controleren. Soortgelijke resultaten waren al gevonden door Pearce et al. [10] twee jaar eerder.

Er zijn nog veel meer voorbeelden van soortgelijke resultaten. Dat hebben Basic en Giaretta [11] gedaan in een uitgebreide systematische studie van de academische literatuur over GenAI en de veiligheid van computercode. De betrokken modellen zijn divers en omvatten onder meer ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet en Gemini Pro. De auteurs bevestigen dat verschillende belangrijke kwetsbaarheden, zoals SQL-injecties en bufferoverflows, kunnen worden aangetroffen in de code die door GenAI wordt gegenereerd. Ze wijzen er ook op dat het risico van vergiftiging van trainingsgegevens niet alleen kan leiden tot het genereren van onveilige code, maar ook de detectie van kwetsbaarheden in gevaar kan brengen.

Vergiftiging van AI

Het vergiftigen van een generatief model voor codeaanvulling bestaat uit het compromitteren van de integriteit van dit model door kwaadaardige codevoorbeelden in de trainingsgegevens van het model te integreren. Backdoor-aanvallen proberen tijdens de trainingsfase triggers te verbergen in het diepe neurale netwerk van het model, waardoor resultaten worden gegenereerd die door de tegenstander zijn gekozen.

Ondanks aanzienlijke vooruitgang op het gebied van codeaanvullingsmodellen blijven deze kwetsbaar voor dit soort aanvallen, zoals Yan et al. [12] met CodeBreaker hebben aangetoond. Voor hun aanval is het niet nodig om een vooraf getraind groot model zoals BERT of GPT te compromitteren. Deze modellen worden namelijk vaak gebruikt als basis die slachtoffers nauwkeurig afstemmen op specifieke taken met behulp van specifieke gegevens die vaak openbaar beschikbaar zijn. De tegenstander hoeft dus alleen maar deze finetuning data te compromitteren of zijn eigen set vervuilde data, gegenereerd met CodeBreaker, te uploaden. De vergiftigde code die na gebruik van CodeBreaker wordt gegenereerd, is niet detecteerbaar met kwetsbaarheidsdetectietools op basis van traditionele statische analyses of GenAI.

Hoewel dit soort aanvallen onwaarschijnlijk is, rijst de vraag waar de gebruikte GenAI-tool vandaan komt en past dit in de problematiek die inherent is aan de huidige GenAI om zowel veilige als nauwkeurige modellen te verkrijgen [13].

Belang van de prompt

Het is echter niet allemaal kommer en kwel en het belang van de keuze van de prompts die aan GenAI worden gegeven om het genereren van code met potentiële zwakke punten te voorkomen, moet worden benadrukt. Götz et al. [14] tonen aan dat, terwijl 65% van de code die oorspronkelijk door verschillende GenAI-tools werd gegenereerd, door een gekwalificeerde ingenieur als onveilig wordt beschouwd, dezelfde tools veilige code genereren wanneer ze handmatig worden aangestuurd. De auteurs concluderen dat technische expertise, met name op het gebied van beveiliging, vereist is om veilige code te genereren met behulp van code AI-codeerassistenten.

Om de best mogelijke resultaten te verkrijgen, moet de prompt die aan GenAI wordt gegeven zowel nauwkeurig als duidelijk interpreteerbaar zijn voor het model. Met andere woorden: de programmeur heeft er alle belang bij om zich aan de eisen van de machine te houden en zo gedetailleerd mogelijk niet alleen de taak die het model moet uitvoeren, maar ook de context waarin deze taak plaatsvindt en de verwachte invoer- en uitvoergegevens te specificeren. Dit kan in één keer gebeuren of in de vorm van een chain-of-thoughts volgens een bepaalde redenering.

Er bestaat echter geen ideale methode, maar Bruni et al. [15] geven verschillende eenvoudige voorbeelden van verbetering van prompts. Volgens hun experimenten is de meest effectieve methode om, na een eerste prompt, GenAI te vragen de code die het al heeft voorgesteld op mogelijke kwetsbaarheden te herzien en vervolgens correcties voor te stellen. Bijvoorbeeld:

• Prompt 1: genereer Java-code voor …
• Prompt 2: analyseer de volgende code en vind de beveiligingsproblemen: <antwoord op prompt 1>
• Prompt 3: op basis van de volgende problemen: <problemen gemeld door prompt 2>, verbeter de volgende code: <antwoord gegeven op prompt 1>

Deze werkwijze veronderstelt uiteraard dat GenAI in staat is om kwetsbaarheden op te sporen, maar zoals we in het volgende artikel zullen zien, is dat vandaag nog niet het geval.

Gespecialiseerde tools

We kunnen echter nieuwe tools verwachten die programmeurs in staat zullen stellen om de veiligheidsrisico’s van GenAI te vermijden.

Zo biedt de tool SafeCoder van ETH Zürich [16] een kader om de veiligheid van door GenAI gegenereerde code te verbeteren zonder de functionaliteit van die code in het gedrang te brengen. De tool combineert de standaardinstellingen van instructies met een veiligheidsgerichte finetuning aan de hand van veilige en onveilige codevoorbeelden. Om een dataset van hoge kwaliteit te creëren, hebben de auteurs een geautomatiseerd proces opgezet dat geverifieerde kwetsbaarheidscorrecties uit de op GitHub geregistreerde codewijzigingen haalt met behulp van heuristische filtering en statische analyse op basis van de CodeQL-tool. De resultaten tonen aan dat SafeCoder de codeveiligheid met ongeveer 30% verbetert, terwijl de bruikbaarheid in benchmarks zoals HumanEval en MMLU behouden blijft. De auteurs geven echter toe dat de tool de veiligheid van code met kwetsbaarheden waarvoor hij niet is getraind, niet verbetert.

In de tussentijd kan een manier zijn om een traditionele statische analyse te combineren met GenAI door eerst de GenAI te vragen de gewenste code te genereren en vervolgens de statische analyse te gebruiken om deze code te analyseren. Als de tool een probleem identificeert en de correctie niet voor de hand ligt, kan men de GenAI vragen om de code aan te passen, waarbij de eerder geïdentificeerde fout wordt aangegeven. De lus kan worden herhaald totdat er geen probleem meer wordt geïdentificeerd door het analyse tool. Natuurlijk kan deze omslachtige procedure worden geautomatiseerd in een normale softwareontwikkelingscyclus.

Conclusie

Het eerste deel van dit artikel ging over de impact van GenAI op de kwaliteit van code in termen van beveiliging. In de huidige situatie moet worden vastgesteld dat, ondanks het verbazingwekkende vermogen van GenAI-tools om computercode te genereren, deze code vaak veiligheidsproblemen kan opleveren, ongeacht het gekozen model. Het is daarom raadzaam om zeer waakzaam te zijn vooraleer we code gebruiken die door GenAI-tools is gegenereerd. Bovendien kunnen GenAI-tools bepaalde programmeertaken vergemakkelijken, maar dat neemt niet weg dat zij niet verantwoordelijk zijn voor de mogelijke negatieve gevolgen van hun “werk”. Die verantwoordelijkheid ligt bij de programmeur en zijn werkgever.

De vaardigheden en kennis op het gebied van veiligheid van programmeurs – wier taak geleidelijk zal evolueren van codeschrijver naar codecontroleur – blijven een essentiële troef. De komst van GenAI in de ontwikkelcyclus is misschien een goede gelegenheid om de samenwerking tussen beveiligings- en ontwikkelingsteams te versterken door werkgroepen op te richten (of te versterken) waarin gemeenschappelijke doelstellingen worden afgestemd om de beveiliging te verbeteren.

In het tweede deel zullen we ons concentreren op het gebruik van GenAI voor het opsporen van kwetsbaarheden in code.

Referenties

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking Prompt Engineering Techniques for Secure Code Generation with GPT Models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

La communication intense autour de l’intelligence artificielle générative (IAGén) et l’augmentation de son utilisation – au moins en phase de test – que cela soit par peur de rater quelque chose ou pour apporter une réelle valeur ajoutée, conduit à se poser la question de son utilité dans beaucoup de domaines, et, pourquoi pas, afin d’améliorer la sécurité du code. En particulier, l’IAGén permet-elle d’écrire du code informatique plus sécurisé ? Peut-elle aider à détecter des vulnérabilités dans du code existant ?

Dans cette première partie nous apporterons des éléments de réponse à la première question. Nous traiterons la seconde question dans un autre article.

Aspects humains

Commençons par considérer l’aspect humain du recours à l’utilisation de l’IAGén. Dans une analyse détaillée, dont je recommande vivement la lecture, Simkute et al. [1] expliquent les raisons pouvant conduire à une perte de productivité des programmeurs ayant recours à l’IAGén. Les chercheurs citent notamment : un glissement du rôle des programmeurs de la production à l’évaluation, une restructuration inutile des flux de travail, des interruptions, et une tendance de l’IAGén à rendre les tâches faciles plus faciles et les tâches difficiles plus difficiles. On s’étonne alors moins des résultats d’une étude de Perry et al. [2], de l’université de Stanford. Ceux-ci montrent que les participants ayant accès à un assistant basé sur un modèle d’IA écrivent un code significativement moins sécurisé que ceux sans accès. Pire, les participants avec un accès à l’assistant étaient plus enclins à croire qu’ils écrivaient du code sécurisé, que ceux sans l’assistant. Cette observation de Perry et al. est corroborée par le travail de Klemmer et al. [3] : l’équipe de chercheurs a interrogé des programmeurs professionnels, et bien que ces derniers se méfient des suggestions des assistants d’IA, il apparait qu’ils surestiment aussi leur propre capacité à examiner les suggestions de ces assistants. L’adoption d’assistants impose donc la mise en place de pratiques de revue de code et d’analyse statique systématiques [4].

Fiabilité des propositions

Considérant maintenant la qualité des suggestions de l’IAGén, bien que celle-ci produise en général du code fonctionnellement correct, elle introduit également des problèmes de sécurité [5], [6]. Khoury et al. [7] ont montré à travers plusieurs exemples que ChatGPT 3.5 génère souvent du code qui présente des problèmes de sécurité : seuls 5 des 21 cas d’utilisation que les auteurs ont étudiés étaient initialement sécurisés. ChatGPT 3.5 n’a été en mesure de produire du code sécurisé que dans 7 autres cas, et ce, seulement après que les auteurs lui ont explicitement demandé de corriger le code.

Plus récemment, Sivana et al. [8] concluaient leurs expérimentations en soulignant que ChatGPT, en tant que plateforme, générait plus de vulnérabilités de type CWE que le site StackOverflow. Indépendamment, Fu et al. [9] ont montré à travers plusieurs centaines d’échantillons de codes générés par Co-Pilot et trouvés sur GitHub, qu’environ un tiers contient des vulnérabilités communes répertoriées par l’organisme MITRE (certaines faisant partie des 25 plus importantes). Les auteurs recommandent donc aux programmeurs de suivre les meilleures pratiques d’utilisation des outils de génération de code et de toujours vérifier les suggestions de code générées. Des résultats similaires avaient déjà été trouvés par Pearce et al. [10] deux ans plus tôt.

On pourrait multiplier les références à des résultats similaires. C’est ce qu’ont fait Basic et Giaretta [11] dans une étude systématique extensive de la littérature académique sur les IAGén et la sécurité du code informatique. Les modèles concernés sont divers et incluent notamment ChatGPT 3.5, GPT 4-Turbo, Copilot, Claude, Sonnet et Gemini Pro. Les auteurs confirment que plusieurs vulnérabilités clés, telles que les injections SQL et les dépassements de mémoire tampon, peuvent être trouvées dans le code généré par les IAGén. Ils signalent aussi que les risques d’empoisonnement des données d’entraînement peuvent non seulement conduire à une génération de code non sécurisé, mais aussi compromettre la détection des vulnérabilités.

Empoisonnement de l’IA

L’empoisonnement d’un modèle génératif de complétion de code consiste à compromettre l’intégrité de ce modèle en intégrant des échantillons de code malicieux dans les données d’entrainement du modèle. Les attaques par porte dérobée, quant à elles, tentent de dissimuler des déclencheurs à l’intérieur du réseau neuronal profond du modèle pendant la phase d’apprentissage, provoquant la génération de résultats choisis par l’adversaire.

Malgré des progrès importants des modèles de complétion de code, ceux-ci restent vulnérables à ce type d’attaques comme l’ont montré Yan et al. [12] avec CodeBreaker. Pour leur attaque, il n’est pas nécessaire de compromettre un modèle massif pré-entrainé comme BERT ou GPT. En effet ces modèles sont souvent utilisés comme fondation que les victimes règlent finement pour des tâches particulières en utilisant des données spécifiques souvent disponibles publiquement. Il suffit donc alors à l’adversaire de compromettre ces données de réglage fin, ou de téléverser son propre ensemble de données polluées générées avec CodeBreaker. Le code empoisonné généré après l’utilisation de CodeBreaker n’est pas détectable avec des outils de détection de vulnérabilités basés sur des analyses statiques traditionnelles ou des IAGén.

Même si ce type d’attaques est peu probable il pose la question de la provenance de l’outil d’IAGén utilisé et s’inscrit dans la problématique inhérente à l’IAGén actuelle d’obtenir des modèles à la fois sécurisés et exactes [13].

Importance de la requête

Tout n’est pas si noir cependant et il faut souligner l’importance du choix des incitations (« prompt » en anglais) données à l’IAGén afin d’éviter la génération de code avec des faiblesses potentielles. Götz et al. [14] montrent qu’alors que 65% du code initialement généré par divers outils d’IAGén est considéré comme non sécurisé par un ingénieur qualifié, ces mêmes outils génèrent du code sécurisé lorsqu’ils sont guidés manuellement. Les auteurs concluent qu’une expertise technique, en particulier dans le domaine de la sécurité est requise pour générer du code sécurisé en utilisant des assistants de codage.

Afin d’obtenir les meilleurs résultats possibles il faut donc que la requête envoyée à l’IAGén soit à la fois précise et clairement interprétable par le modèle. Autrement-dit, le programmeur a tout intérêt à se plier aux exigences de la machine et fournir avec le plus de détails possibles, non seulement la tâche que le modèle doit exécuter, mais aussi le contexte qui décrit cette tâche, ainsi que les données d’entrée et les données de sortie attendues. Cela peut se faire en seule fois ou sous forme de chaîne de pensée suivant un raisonnement particulier.

Il n’existe cependant pas de méthode idéale, mais Bruni et al. [15] donnent plusieurs exemples simples d’amélioration des incitations. Selon leurs expérimentations la méthode la plus efficace est, après une première requête, de demander à l’IAGén de revoir le code qu’elle a déjà suggéré pour des vulnérabilités potentielles, et enfin de proposer des corrections. Par exemple :

• Requête 1 : Génère du code Java pour …
• Requête 2 : Examine le code suivant et trouve les problèmes de sécurité : <réponse fournie à la requête 1>
• Requête 3 : À partir des problèmes suivants : <problèmes signalés par la requête 2>, améliore le code suivant : <réponse fournie à la requête 1>

Cette façon de faire suppose bien évidemment que l’IAGén est capable de détecter des vulnérabilités, mais comme nous le verrons dans l’article suivant ce n’est pas encore le cas aujourd’hui.

Outils spécialisés

Nous pouvons néanmoins nous attendre à l’arrivée de nouveaux outils qui pourraient permettre aux programmeurs d’éviter les écueils de sécurité créés par l’IAGén.

Par exemple l’outil SafeCoder d’ETH Zurich [16] propose un cadre permettant d’améliorer la sécurité du code généré par une IAGén sans sacrifier la fonctionnalité de ce code. L’outil combine le réglage standard des instructions avec un réglage fin – spécifique à la sécurité, en utilisant des exemples de code sûrs et non-sûrs. Pour créer un ensemble de données de qualité, les auteurs ont mis en place un processus automatisé qui extrait les corrections de vulnérabilités vérifiées à partir des modifications de code enregistrées sur GitHub à l’aide d’un filtrage heuristique et d’une analyse statique basée sur l’outil CodeQL. Les résultats montrent que SafeCoder améliore la sécurité du code d’environ 30 % tout en conservant son utilité dans des étalons tels que HumanEval et MMLU. Les auteurs admettent cependant que l’outil n’améliore pas la sécurité de code contenant des vulnérabilités pour lesquelles il n’a pas été entrainé.

En attendant, une façon de procéder pourrait être de combiner un outil d’analyse statique « classique » avec une IAGén en demandant d’abord à l’IAGén de générer le code souhaité, puis en utilisant l’outil d’analyse statique pour analyser ce code. En cas de problème identifié par l’outil, si la correction n’est pas évidente, on peut demander à l’IAGén de modifier celui-ci en indiquant à celle-ci l’erreur précédemment identifiée. On peut recommencer la boucle jusqu’à ce qu’aucun problème ne soit identifié par l’outil d’analyse. Bien évidemment cette procédure fastidieuse pourrait être automatisée dans un cycle de développement logiciel habituel..

Conclusion

La première partie de cet article était dédiée à l’impact de l’IAGén sur la qualité du code en termes de sécurité. En l’état actuel des choses, force est de constater que malgré la capacité étonnante des outils d’IAGén à générer du code informatique, ce code peut souvent présenter des problèmes de sécurité – et ce quelque-soit le modèle choisi. Il convient donc d’être très vigilent avant d’utiliser du code généré par des outils d’IAGén. De plus, même si les IAGén peuvent faciliter certaines tâches de programmation, il n’en reste pas moins qu’elles ne portent pas la responsabilité des conséquences potentiellement négatives de leur « travail », responsabilité qui échoit au programmeur et à son employeur.

Les compétences et connaissances en matière de sécurité des programmeurs – dont la tâche évoluera progressivement de créateur de code à contrôleur de code – restent un atout essentiel. L’arrivée de l’IAGén dans le cycle de développement est peut-être une bonne occasion de renforcer la collaboration entre les équipes de sécurité et de développement en établissant (ou renforçant) des groupes de travail dans lesquels sont alignés des objectifs communs afin d’améliorer la sécurité.

Dans la seconde partie nous nous focaliserons sur l’utilisation de l’IAGén pour la détection de vulnérabilités dans le code.

Références

[1] A. Simkute, L. Tankelevitch, V. Kewenig, A. E. Scott, A. Sellen, et S. Rintel, « Ironies of generative AI: Understanding and mitigating productivity loss in human-AI interactions », 17 février 2024, arXiv: arXiv:2402.11364. doi: 10.48550/arXiv.2402.11364.

[2] N. Perry, M. Srivastava, D. Kumar, et D. Boneh, « Do users write more insecure code with AI assistants? », 16 décembre 2022, arXiv: arXiv:2211.03622. Consulté le: 3 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2211.03622

[3] J. H. Klemmer et al., « Using AI assistants in software development: A qualitative study on security practices and concerns », 14 octobre 2024. doi: 10.1145/3658644.3690283.

[4] J. Ganseman, « LLM pour code : the good, the bad and the ugly », Smals Research Blog. Consulté le: 18 octobre 2023. [En ligne]. Disponible sur: /llms-pour-code/

[5] A. Chowdhery et al., « PaLM: scaling language modeling with pathways », 5 octobre 2022, arXiv: arXiv:2204.02311. doi: 10.48550/arXiv.2204.02311.

[6] M. Chen et al., « Evaluating large language models trained on code », 14 juillet 2021, arXiv: arXiv:2107.03374. doi: 10.48550/arXiv.2107.03374.

[7] R. Khoury, A. R. Avila, J. Brunelle, et B. M. Camara, « How secure is code generated by ChatGPT? », 19 avril 2023, arXiv: arXiv:2304.09655. doi: 10.48550/arXiv.2304.09655.

[8] S. Hamer, M. d’Amorim, et L. Williams, « Just another copy and paste? Comparing the security vulnerabilities of ChatGPT generated code and StackOverflow answers », 22 mars 2024, arXiv: arXiv:2403.15600. doi: 10.48550/arXiv.2403.15600.

[9] Y. Fu et al., « Security weaknesses of copilot generated code in GitHub », 4 avril 2024, arXiv: arXiv:2310.02059. doi: 10.48550/arXiv.2310.02059.

[10] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, et R. Karri, « Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions », in 2022 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA: IEEE, mai 2022, p. 754‑768. doi: 10.1109/sp46214.2022.9833571.

[11] E. Basic et A. Giaretta, « Large language models and code security: A systematic literature review », 19 décembre 2024, arXiv: arXiv:2412.15004. doi: 10.48550/arXiv.2412.15004.

[12] S. Yan et al., « An LLM-assisted easy-to-trigger backdoor attack on code completion models: Injecting disguised vulnerabilities against strong detection », présenté à 33rd USENIX Security Symposium, Philadelphia, PA, USA, août 2024.

[13] E.-M. El-Mhamdi et al., « On the impossible safety of large AI models », 9 mai 2023, arXiv: arXiv:2209.15259. Consulté le: 17 octobre 2023. [En ligne]. Disponible sur: http://arxiv.org/abs/2209.15259

[14] S. Götz et A. Schaad, « “You still have to study” – On the security of LLM generated code », août 2024, [En ligne]. Disponible sur: https://arxiv.org/abs/2408.07106

[15] M. Bruni, F. Gabrielli, M. Ghafari, et M. Kropp, « Benchmarking prompt engineering rechniques for secure code generation with GPT models », 9 février 2025, arXiv: arXiv:2502.06039. doi: 10.48550/arXiv.2502.06039.

[16] J. He, M. Vero, G. Krasnopolska, et M. Vechev, « Instruction tuning for secure code generation », 12 juillet 2024, arXiv: arXiv:2402.09497. doi: 10.48550/arXiv.2402.09497.

_________________________

Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

(NL) CodeQL is een statische code analyse tool gebaseerd op tientallen jaren onderzoek door een team aan de Universiteit van Oxford. Het kan worden gebruikt om applicaties automatisch te scannen op complexe kwetsbaarheden en bugs en om programmeurs te helpen bij het handmatig controleren van code.