Gérer les risques liés à la programmation intuitive

Complaisance

L’une des principales limites de l’IA à l’heure actuelle vient du fait qu’elle est entraînée à donner raison aux utilisatrices et utilisateurs. Les modèles d’IA ont tendance à adapter leurs réponses en fonction de ce qu’ils perçoivent comme étant les attentes de la personne. Ce phénomène, appelé complaisance, peut présenter un risque important pour la cybersécurité. Si l’agent d’IA produit des réponses qui renforcent les attentes de la personne qui l’utilise, celle-ci risque de ne pas remarquer certaines inexactitudes ou certains risques de sécurité.

Dans le contexte de la programmation intuitive, un agent d’IA qui fait preuve de complaisance peut compromettre la robustesse et la sécurité du code généré et produire du code peu robuste ou non sécurisé. Le fait que l’IA approuve une décision de la personne qui l’utilise ne signifie pas que le code est exact, robuste ou sécurisé.

Il est important de savoir comment interagir avec un agent d’IA pour réduire les comportements complaisants. Posez des questions neutres qui ne laissent pas entendre qu’une réponse est préférable à une autre. L’agent aura ainsi plus de difficulté à déterminer votre position sur un sujet et sera moins susceptible de fournir une réponse complaisante. Tenez-vous au courant des plus récents travaux de recherche et développements dans le domaine de l’IA et offrez une formation approfondie et continue à votre personnel.

Code de faible qualité et examen du code

Il est possible que le code généré par l’IA ne fonctionne pas comme prévu et contienne des erreurs, des vulnérabilités ou des choix de conception inadéquats. Les outils d’IA produisent du code à partir de schémas appris grâce aux données provenant d’Internet et du contexte fourni dans les requêtes. Le résultat constitue un point de départ qu’il faut ensuite examiner et améliorer.

L’IA n’exerce pas de pensée critique et ne comprend pas les risques et les exigences de la même façon qu’une personne. À moins de recevoir des instructions contraires, elle emprunte généralement la voie la plus efficace pour créer une application. Cela peut entraîner :

• des résultats inexacts;
• du code fragile ou inutilement lourd, c’est-à-dire plus volumineux et complexe que nécessaire pour accomplir la tâche;
• des applications qui ne peuvent pas être adaptées à l’échelle requise pour répondre aux besoins opérationnels;
• des vulnérabilités de sécurité intégrées au code;
• des fuites de données involontaires ou la divulgation d’information sensible.

Il n’est pas toujours facile de comprendre pourquoi un outil d’IA a fait un choix particulier. Avec une personne, il est possible de demander pourquoi elle a choisi un langage de programmation ou un style de mise en forme donné. Il est également possible de discuter de sa démarche et de comprendre pourquoi et comment certaines tâches ont été réalisées. Ce type d’échange peut être plus difficile avec l’IA, mais il demeure possible.

Même si l’IA n’a pas la capacité humaine de réfléchir et d’exercer une pensée critique, il est possible, et nécessaire, de remettre constamment ses résultats en question. On peut demander à l’outil d’IA d’expliquer ses décisions ou d’examiner le code qu’il a généré. Toutefois, ces explications ou cet autoexamen ne devraient jamais constituer le seul mécanisme de contrôle, surtout pour les tâches importantes d’une organisation. Bien qu’il soit possible de demander à un modèle d’IA d’examiner le code qu’il a lui-même généré, l’autoexamen par un seul modèle constitue à lui seul un mécanisme de contrôle peu fiable. Lorsque la situation s’y prête, utilisez un autre outil d’IA pour effectuer l’examen. Il demeure essentiel d’assurer une surveillance rigoureuse avec intervention humaine ou avec intervention de la gouvernance. Autrement dit, des personnes qualifiées doivent toujours examiner les décisions importantes et approuver le code définitif avant son déploiement.

Les spécialistes de la programmation et de l’examen du code mettent également à profit leur expérience, leur connaissance du contexte et leur jugement, ce qu’un système d’IA ne peut pas faire. Lorsqu’une requête est ambiguë ou porte sur un élément qui ne faisait pas partie de son entraînement, l’outil peut produire :

• des conclusions erronées;
• des adaptations étranges;
• des résultats inexacts;
• des hallucinations.

Dans le contexte de la programmation intuitive, les personnes ayant une expérience limitée en programmation risquent de ne pas reconnaître les défauts complexes du code généré par l’IA. Une personne qualifiée en programmation ou en examen du code devrait donc vérifier, corriger et approuver le code généré par l’IA avant son déploiement. Cette mesure peut contribuer à prévenir les atteintes à la réputation ou des coûts financiers pour l’organisation.

Testez la sécurité des logiciels à l’aide de solutions d’analyse statique de la sécurité des applications (SAST pour Static Application Security Testing) et d’analyse dynamique de la sécurité des applications (DAST pour Dynamic Application Security Testing). Ces outils permettent de vérifier si le code comporte des vulnérabilités avant son déploiement. Il convient également de configurer l’IA de façon à ce qu’elle exécute continuellement des tests de sécurité des applications tout au long du cycle de développement des logiciels.

Communiquer efficacement avec l’IA

La rédactique consiste à formuler des requêtes claires et efficaces à l’intention de l’IA. Commencez par déterminer les principales exigences de l’organisation, puis traitez chacune d’elles dans une requête distincte et précise.

La programmation intuitive peut se faire dans de nombreuses langues naturelles, mais la qualité des réponses peut varier selon la langue et les données utilisées pour entraîner le modèle, qui sont le plus souvent en anglais. Il faut structurer les requêtes de façon à ce que l’IA puisse les comprendre et y donner suite. L’examen du code généré par l’IA peut également nécessiter une certaine connaissance de la terminologie anglaise de la programmation, même si la logique sous-jacente et le déroulement des opérations ne dépendent pas de la langue.

Conseils pour une rédactique efficace

• Fournissez suffisamment de contexte sur le projet pour réduire les suppositions que fait l’IA à partir de schémas prédictifs.
• Exercez-vous avec des exemples de requêtes avant d’entreprendre le projet principal afin de mieux comprendre comment l’IA répond.
• Décrivez le résultat attendu et réitérez-le tout au long du développement.
• Axez chaque requête sur une tâche principale.
• Précisez les exigences en matière de sécurité, de protection de la vie privée et de conformité.
• Utilisez des consignes ouvertes pour favoriser l’expérimentation et la recherche d’idées.
• Utilisez des requêtes de suivi pour préciser le résultat.
• Fournissez à l’outil d’IA des exemples de projets semblables auxquels il peut se reporter.

Intégrité de la chaîne d’approvisionnement

L’intégrité de la chaîne d’approvisionnement dépend du fournisseur de l’outil d’IA et de ses dépendances, ainsi que des renseignements qui lui sont communiqués. Examinez les politiques de sécurité, les conditions relatives au traitement des données et les processus de chaque fournisseur afin de vous assurer qu’ils concordent avec ceux de votre organisation. Il est important d’effectuer une analyse des niveaux de confiance des fournisseurs d’outils d’IA afin de préserver l’intégrité de la chaîne d’approvisionnement. Cette analyse permet d’attribuer et de gérer différents niveaux d’accès et de contrôle selon les systèmes et les outils d’IA. Voici certains critères à prendre en compte pour évaluer les fournisseurs :

• l’endroit où le service d’IA et les données sont hébergés :
  • la propriété et la responsabilité juridique;
  • l’hébergement public ou privé;
• le contexte géopolitique;
• les politiques d’utilisation et de conservation des données;
• les pratiques commerciales et de sécurité du fournisseur;
• les vulnérabilités du produit, sa disponibilité et le soutien offert.

Les fournisseurs approuvés par le gouvernement ou qui hébergent leurs services et leurs données au pays peuvent présenter moins de risques. Consultez Évaluations des risques liés à l’intégrité de la chaîne d’approvisionnement : Critères d’évaluation (ITSAP.10.071) pour en savoir plus sur l’évaluation des profils de risque.

La souveraineté numérique et la souveraineté des données contribuent à renforcer la sécurité de la chaîne d’approvisionnement. Utilisez une nomenclature logicielle (SBOM pour Software Bill of Materials) pour répertorier les dépendances de source ouverte, en faire le suivi et en retracer la provenance. Pour en savoir plus sur la nomenclature logicielle et la façon d’établir un cadre résilient pour la chaîne d’approvisionnement, consultez le Bulletin conjoint sur les éléments de base d’une nomenclature logicielle.

En plus d’effectuer les recherches et les évaluations des risques appropriées, vous pouvez prendre certaines des mesures ci-dessous pour protéger l’intégrité de votre chaîne d’approvisionnement :

• Analysez et vérifiez continuellement le code généré par l’IA pour détecter les vulnérabilités courantes connues et les dépendances.
• Classez les menaces selon leur niveau de risque : critique, élevé, moyen ou faible.
• Appliquez les principes du droit d’accès minimal et de la vérification systématique.
• Surveillez continuellement les fournisseurs et les dépendances.
• Utilisez des images de conteneur minimales et renforcées.
• Effectuez périodiquement des audits de sécurité et des tests d’intrusion.
• Mettez à l’essai les procédures d’intervention en cas d’incident en simulant des attaques contre la chaîne d’approvisionnement afin de vérifier que les équipes peuvent détecter et isoler rapidement les menaces.

Provenance du code

Il peut être difficile de déterminer l’origine, ou la provenance, du code généré par l’IA. Pour générer du code, l’IA s’appuie sur des schémas appris à partir de ses données d’entraînement. Ces données peuvent comprendre des logiciels libres, des vulnérabilités, des pratiques désuètes et du code délibérément malveillant. Des schémas semblables peuvent se retrouver dans les résultats générés et accroître le nombre de menaces possibles. Comme les données utilisées par l’IA peuvent provenir de n’importe quelle source, il ne faut pas présumer que le code généré est sécurisé ou robuste.

Le code généré à partir de sources inconnues peut :

• hériter des vulnérabilités présentes dans le matériel source;
• entraîner des obligations liées aux licences, au droit d’auteur ou à l’attribution;
• être de qualité variable;
• contenir du code délibérément modifié par des auteurs de menace.

Il est possible de demander au modèle d’IA d’examiner et d’évaluer son propre code ou d’utiliser un autre outil d’IA pour en vérifier les vulnérabilités. Toutefois, de nombreuses vulnérabilités peuvent passer inaperçues, et un outil d’IA utilisé pour l’examen pourrait ne pas détecter celles que l’IA a délibérément introduites. Une surveillance avec intervention humaine ou avec intervention de la gouvernance demeure nécessaire pour confirmer que le code ne contient aucun paquet malveillant. Pour en savoir plus sur l’utilisation sécurisée des logiciels ouverts, consultez la publication Considérations liées à la sécurité dans le cadre de l’utilisation de logiciels libres (ITSAP.10.059).

Fuites de renseignements et architecture

Avant de recourir à la programmation intuitive, les organisations devraient tenir compte de la sécurité de l’information et de la robustesse des systèmes. Donner à l’IA accès à des renseignements sensibles peut entraîner une fuite de données, que ce soit par le code produit ou par l’outil d’IA lui-même. Il faut savoir où le fournisseur du service d’IA stocke les renseignements et comment il peut utiliser les données saisies. Selon le service d’IA choisi, le fournisseur peut conserver ces renseignements ou les utiliser pour entraîner ses modèles. Examinez les conditions du fournisseur relatives au traitement des données avant de saisir toute information de l’organisation. Choisissez des fournisseurs dont les conditions de service ou les ententes destinées aux entreprises interdisent contractuellement l’utilisation des données de la clientèle pour entraîner leurs modèles.

Il faut également tenir compte de la sécurité de l’architecture du code. Lorsqu’une programmeuse ou un programmeur écrit du code manuellement, cette personne établit la structure et les paramètres de sécurité de l’architecture, notamment l’information autorisée. Lorsque l’IA génère le code, elle produit plutôt ce qu’elle juge le mieux adapté au projet, sans nécessairement tenir compte de tous les risques de cybersécurité qu’elle peut introduire. Si l’organisation ne valide pas et ne vérifie pas la sécurité du code produit par l’IA, elle risque de s’exposer à des accès non autorisés et à des cyberattaques.

Les organisations, y compris les ministères du gouvernement du Canada et les sociétés d’État, doivent aussi accorder une attention particulière aux risques liés à la résidence des données et au transfert transfrontalier de données. Ces considérations vont de pair avec l’utilisation de la nomenclature logicielle et l’évaluation du cadre de gestion des risques liés à la chaîne d’approvisionnement. Pour en savoir plus sur les exigences relatives aux données et aux actifs numériques canadiens ainsi qu’à leur stockage, consultez Souveraineté numérique.

Maliciels intégrés et accès par l’intermédiaire de bibliothèques

Le code généré par l’IA peut utiliser des paquets ou des bibliothèques de source ouverte pouvant contenir des composants vulnérables ou désuets. L’organisation peut alors être exposée à des risques comme :

• des paquets malveillants, des maliciels ou des portes dérobées;
• des vulnérabilités inconnues;
• des configurations non sécurisées qui permettent à des auteurs de menace d’accéder aux réseaux ou aux systèmes de l’organisation.

Maintien de la cybersécurité de l’organisation

Pour maintenir la cybersécurité de l’organisation, il est important d’effectuer régulièrement les mises à jour et l’application de correctifs. Comme les auteurs de menace utilisent de plus en plus l’IA agentive et l’IA de pointe, il demeure essentiel d’assurer la maintenance et la gestion des vulnérabilités en temps opportun.

Il faut notamment tenir compte des difficultés de maintenance suivantes :

• la difficulté à comprendre et à dépanner le code généré par l’IA :
  • la succession de requêtes peut compliquer la recherche des raisons pour lesquelles le code généré par l’IA ne fonctionne pas comme prévu;
  • des requêtes répétées ou reformulées peuvent modifier le code et son fonctionnement et compliquer le suivi de sa provenance;
  • une requête visant à corriger un problème, comme une erreur de code ou une faille logique, peut ajouter une complexité inutile;
  • la nécessité de recréer entièrement un logiciel produit par programmation intuitive ou d’en créer plusieurs sous-versions;
• la quantité de code que l’IA génère pour accomplir une tâche peut devenir excessive, ce qui risque de compliquer la maintenance à mesure que le code prend de l’ampleur.

La programmation intuitive peut permettre aux personnes qui ont une expérience limitée en programmation de créer du code, mais les outils d’IA ne peuvent pas, à eux seuls, assurer la maintenance d’un code base fonctionnel. Il faut que des programmeuses et programmeurs compétents assurent une surveillance humaine continue.

Les personnes qui examinent le code jouent un rôle essentiel dans son examen et sa maintenance, mais elles peuvent tout de même commettre des erreurs. Les organisations devraient tenir compte des facteurs humains ci-dessous lorsqu’elles établissent leurs mécanismes de surveillance.

Biais d’automatisation

Le biais d’automatisation est la tendance à faire davantage confiance aux systèmes automatisés qu’à son propre jugement et à sa propre expérience. Les personnes qui examinent le code peuvent accepter les suggestions de l’IA même lorsqu’elles sont erronées parce qu’elles croient que la technologie repose sur un meilleur processus d’analyse. Un manque d’esprit critique lors de l’examen humain peut nuire à la qualité et à la sécurité du produit.

Fatigue liée à la surveillance

La fatigue liée à la surveillance peut survenir lorsque les personnes responsables de la surveillance s’épuisent ou se sentent dépassées par un grand nombre d’alertes et de menaces ou par l’exécution de tâches répétitives. La quantité de code généré par la programmation intuitive, en plus des tâches de surveillance et de prise de décisions qui en découlent, peut contribuer à cette fatigue.

Selon l’ampleur de vos activités et les exigences de votre projet, vous pouvez prendre diverses mesures à l’interne pour atténuer ce risque. Veillez à ce que votre personnel soit bien informé et formé et qu’il possède les connaissances nécessaires pour accomplir ses tâches avec assurance. Les organisations devraient également élaborer des stratégies pour gérer la charge cognitive et favoriser l’analyse critique chez les personnes qui ont recours à la programmation intuitive.

Attaques et vulnérabilités courantes

La section ci-dessous présente les attaques et les vulnérabilités les plus courantes associées à la programmation intuitive.

Détournement de paquets hallucinés par l’IA

L’attaque par détournement de paquets hallucinés par l’IA cible la chaîne d’approvisionnement logicielle et exploite des dépendances logicielles inventées par l’IA. Des auteurs de menace enregistrent des noms de paquets fictifs que les outils de programmation fondés sur l’IA génèrent fréquemment, puis attendent que des développeuses ou développeurs les installent. Contrairement au typosquattage, qui exploite les erreurs humaines, le détournement de paquets hallucinés par l’IA tire parti des erreurs générées par l’IA et d’une confiance mal placée dans le code qu’elle produit. Pour atténuer ce risque, vous devriez prendre les mesures suivantes :

• empêcher les agents d’IA d’installer les paquets de façon autonome;
• exiger l’utilisation d’une liste d’autorisation ou une vérification humaine;
• épingler les versions des dépendances et vérifier les valeurs de hachage des paquets dans le pipeline de compilation;
• utiliser la nomenclature logicielle.

Injection ou manipulation de requêtes

L’injection de requêtes est une technique qui exploite l’incapacité de l’IA à distinguer les requêtes légitimes des requêtes malveillantes. Un auteur de menace peut dissimuler une requête malveillante et manipuler l’IA afin qu’elle ignore ses instructions habituelles ou extraie des données sensibles. Comme la programmation intuitive repose sur le langage naturel pour produire du code, un auteur de menace peut concevoir une entrée qui ressemble à la requête d’une développeuse ou d’un développeur afin de contourner les instructions établies du système. Pour contrer cette menace, vous devriez :

• déterminer les sujets sensibles et mettre en place des mécanismes distincts pour vérifier les entrées et les sorties;
• exiger une surveillance régulière ainsi qu’une approbation humaine ou de la gouvernance pour toutes les requêtes à risque élevé ou à incidence élevée;
• effectuer régulièrement les mises à jour et l’application des correctifs;
• utiliser l’agent d’IA et ses outils dans un bac à sable, c’est-à-dire un environnement contrôlé qui permet d’exécuter le code généré par l’IA tout en limitant l’accès aux systèmes et aux données, afin de contenir et de limiter les dommages.

Scripts intersites (XSS)

Les scripts intersites sont utilisés par les auteurs de menace pour injecter des entrées ou des scripts malveillants dans un site Web, ce qui amène le navigateur d’une utilisatrice ou d’un utilisateur à exécuter des commandes non autorisées. Cette vulnérabilité peut découler de code non sécurisé généré par l’IA, notamment lorsque celui-ci présente des schémas prévisibles ou des lacunes de sécurité. Le code qui ne valide pas et n’authentifie pas les entrées des utilisatrices et utilisateurs est vulnérable aux attaques par scripts intersites. Pour atténuer les risques d’attaques par scripts intersites, vous devriez :

• valider et nettoyer toutes les entrées non fiables et appliquer un codage de sortie sensible au contexte;
• utiliser le codage de sortie et le nettoyage du code HTML dans votre cadre de développement;
• utiliser des stratégies de sécurité du contenu pour limiter les sources à partir desquelles le contenu peut être chargé;
• utiliser un pare-feu d’applications Web (WAF pour Web Application Firewall) afin de surveiller et de filtrer le trafic HTTP.

Injection SQL

L’attaque par injection SQL cible le langage SQL (Structured Query Language) utilisé pour gérer les données dans les bases de données. La programmation intuitive génère souvent la requête la plus directe et la plus facile à lire. Les auteurs de menace peuvent exploiter cette tendance en insérant leurs propres requêtes SQL afin de voler ou de modifier des données, d’exécuter des opérations d’administration ou d’usurper l’identité d’une cliente ou d’un client. Pour contrer cette vulnérabilité, vous devriez :

• utiliser des requêtes de base de données sécurisées et des instructions préparées qui séparent les entrées des utilisatrices et utilisateurs des commandes de la base de données;
• préciser clairement à l’agent d’IA les exigences de sécurité de la base de données pendant la phase de production, notamment l’obligation d’utiliser des méthodes sécurisées pour interagir avec celle-ci.