Un développeur demande à un assistant de corriger une requête de recherche client défaillante. Le correctif proposé permet au test de réussir, mais remplace le filtre restreint au locataire (tenant) par une recherche basée uniquement sur l’identifiant client (customerId). Une fois la demande de fusion (pull request) intégrée, un utilisateur connaissant l’identifiant d’un autre locataire peut accéder à la fiche de ce client. L’attaquant n’a eu besoin d’aucun accès au dépôt, au système d’intégration continue (CI) ou à l’assistant de codage ; il a simplement utilisé une requête applicative standard ciblant un point de terminaison dont la vérification d’autorisation avait disparu sans laisser de trace.
Une modification non approuvée désigne toute proposition de modification de code, de dépendance, de configuration ou de flux de travail n’ayant pas encore fait l’objet de contrôles indépendants de son auteur. Le résultat fourni par l’assistant entre dans cette catégorie, même s’il compile, s’accompagne d’une explication plausible et corrige le défaut signalé. L’assistant a généré ce texte à partir de l’invite (prompt) et du contexte du dépôt, mais aucun de ces éléments ne garantit que la requête résultante préserve la séparation des données entre les locataires de l’application.
Le processus en question traverse plusieurs frontières. Le correctif de l’assistant, la version de paquet suggérée et toute configuration générée pénètrent dans le dépôt en tant qu’artefacts non approuvés. Le système d’intégration continue examine la modification proposée, mais ne vérifie pas automatiquement la validité de l’autorisation. L’environnement de production exécute uniquement l’artefact fusionné ; or, l’absence du filtre entraîne l’exposition des données d’un client à un autre locataire. Le schéma de délimitation suivant permet de distinguer ces différents artefacts :
La carte des limites illustre pourquoi l’approche adopte un contrat de sécurité unique. Tout artefact généré par une IA doit être considéré comme non fiable tant qu’une révision humaine indépendante et les contrôles automatisés requis n’ont pas validé la modification. Le modèle ne constitue jamais le point d’application des règles de sécurité. Une instruction (prompt) demandant l’isolation des locataires (tenant isolation) exprime une préférence transmise via le même canal que le code suggéré ; il ne s’agit pas d’un mécanisme de contrôle bloquant une fusion non sécurisée.
Dans le cas du correctif de recherche client, le réviseur de la pull request vérifie si la requête applique toujours les droits d’accès au locataire (tenant entitlement) de l’utilisateur authentifié. L’intégration continue (CI) examine différents éléments de preuve : l’analyse du code source inspecte les modèles d’implémentation, l’analyse des dépendances examine le paquet nouvellement ajouté, et la recherche de secrets (secret scanning) vérifie la présence d’identifiants dans le code source et la configuration modifiés. Les règles de protection des branches du dépôt garantissent l’application de la décision de fusion en exigeant ces contrôles et approbations. Aucun contrôle ne doit reposer sur la simple affirmation de l’assistant selon laquelle le correctif est sûr.
Règle d’examen
Le code généré par une IA n’est accepté que si une révision indépendante et les points de contrôle de sécurité requis produisent des preuves documentées. La sortie du modèle et la formulation de l’instruction ne suffisent pas à garantir le contrôle d’accès.
Chaque contrôle a ses limites. Une révision humaine peut laisser échapper une erreur subtile de flux de données ; les contrôles automatisés fournissent donc un signal supplémentaire. Un outil d’analyse peut manquer une logique d’autorisation nécessitant une compréhension du contexte applicatif ; une révision qualifiée reste donc indispensable. La réussite du pipeline ne prouve pas l’absence de vulnérabilités. Elle confirme simplement l’existence des preuves requises par les points de contrôle définis pour cette révision. En cas d’échec d’un point de contrôle obligatoire, le dépôt enregistre l’anomalie, bloque la fusion conformément à la politique en vigueur et conserve une trace d’audit pour la décision d’acceptation ou d’exception.
L’artefact en cours d’examen est une pull request qui ajoute un point de terminaison GET /search?q=... à un service web multi-locataire (multi-tenant) ainsi qu’une dépendance pour la recherche textuelle. Une requête utilisateur constitue une entrée non fiable. Le gestionnaire de requête (handler) reçoit l’identité de l’utilisateur authentifié, construit une requête de base de données et doit appliquer les droits d’accès au locataire de cet utilisateur avant que la base de données ne renvoie les résultats. L’opération de base de données s’exécute sous l’identité de service de l’application, tandis que la couche de requête ou de politique contrôle ce que l’utilisateur final peut voir. Si le nouveau point de terminaison accepte un tenantId provenant de la requête sans le comparer aux droits d’accès authentifiés, l’impact potentiel (ou « rayon d’action ») s’étend à tous les enregistrements accessibles via cette identité de service.
La demande de tirage (pull request) elle-même n’est pas considérée comme fiable. Le diff associé peut supprimer le prédicat de locataire (tenant predicate), le manifeste des dépendances peut introduire un paquet vulnérable ou inapproprié, et la configuration générée peut contenir un secret exposé. Les explications fournies par l’assistant ne permettent pas de trancher ces questions. Les éléments de preuve proviennent du diff, du manifeste des dépendances modifié, des catégories d’analyse, de l’approbation du réviseur et de l’historique de fusion.
Un test de sécurité statique des applications (SAST) analyse le code source et les flux de données au niveau du code à la recherche de modèles de vulnérabilités connus. L’analyse de la composition logicielle (SCA) examine les dépendances et les métadonnées des composants pour détecter des problèmes liés à la chaîne d’approvisionnement. La recherche de secrets (secret scanning) parcourt les artefacts modifiés du dépôt pour identifier des identifiants ou des jetons qui ne devraient pas être intégrés au code source (commit). Ces contrôles portent sur des artefacts différents ; par conséquent, un résultat positif pour l’un ne peut se substituer à un résultat positif pour l’autre. Le cheminement de la requête et celui de l’intégration continue (CI) indiquent l’origine des suggestions et les étapes où la vérification produit des preuves d’acceptation :