Accueil La cyber-sécurité Accroître la transparence dans la sécurité de l’IA

Accroître la transparence dans la sécurité de l’IA

0
Accroître la transparence dans la sécurité de l’IA


De nouvelles innovations et applications en matière d’IA parviennent presque quotidiennement aux consommateurs et aux entreprises. Développer l’IA en toute sécurité est une préoccupation majeure, et nous pensons que les objectifs de Google Cadre d’IA sécurisé (SAIF) peut aider à tracer la voie à suivre pour créer des applications d’IA auxquelles les utilisateurs peuvent faire confiance. Aujourd’hui, nous mettons en avant deux nouvelles façons de rendre les informations sur la sécurité de la chaîne d’approvisionnement de l’IA universellement détectables et vérifiables, afin que l’IA puisse être créée et utilisée de manière responsable.

Le premier principe du SAIF est de garantir que l’écosystème de l’IA dispose de bases de sécurité solides. En particulier, les chaînes d’approvisionnement logicielles pour les composants spécifiques au développement de l’IA, tels que les modèles d’apprentissage automatique, doivent être sécurisées contre les menaces, notamment falsification de modèle, empoisonnement des donnéeset le production de contenu préjudiciable.

Même si l’apprentissage automatique et l’intelligence artificielle continuent d’évoluer rapidement, certaines solutions sont désormais à la portée des créateurs de ML. Nous nous appuyons sur nos travaux antérieurs avec le Fondation de sécurité Open Source pour montrer comment Les créateurs de modèles ML peuvent et doivent se protéger contre les attaques de la chaîne logistique ML en utilisant SLSA et Sigstore.

Pour la sécurité de la chaîne d’approvisionnement des logiciels conventionnels (logiciels qui n’utilisent pas le ML), nous considérons généralement des questions telles que :

  • Qui a publié le logiciel? Sont-ils dignes de confiance ? Ont-ils utilisé des pratiques sécuritaires ?
  • Pour l’open source logicielquel était le source code?
  • Quoi dépendances suis allé dans bâtiment que logiciel?
  • Le logiciel ont été remplacés par une version falsifiée suite à leur publication ? Cela aurait-il pu se produire pendant construire temps?

Toutes ces questions s’appliquent également à des centaines de modèles ML gratuits qui sont disponibles pour une utilisation sur Internet. Utiliser un modèle ML signifie faire confiance à chaque partie de celui-ci, comme vous le feriez pour n’importe quel autre logiciel. Cela inclut des préoccupations telles que :

  • Qui a publié le modèle? Sont-ils dignes de confiance ? Ont-ils utilisé des pratiques sécuritaires ?
  • Pour l’open source des modèlesquel était le entraînement code?
  • Quoi ensembles de données suis allé dans entraînement que modèle?
  • Le modèle ont été remplacés par une version falsifiée suite à leur publication ? Cela aurait-il pu se produire pendant entraînement temps?

Nous devons traiter la falsification des modèles ML avec la même gravité que l’injection de logiciels malveillants dans des logiciels conventionnels. En fait, depuis les modèles sont des programmes, beaucoup autorisent les mêmes types d’exploitations d’exécution de code arbitraire que celles utilisées pour les attaques contre les logiciels conventionnels. De plus, un modèle falsifié pourrait divulguer ou voler des données, causer des préjudices dus à des préjugés ou diffuser des informations erronées dangereuses.

L’inspection d’un modèle ML est insuffisante pour déterminer si de mauvais comportements ont été injectés. Cela revient à essayer de procéder à l’ingénierie inverse d’un exécutable pour identifier un logiciel malveillant. Pour protéger les chaînes d’approvisionnement à grande échelle, nous devons savoir comment le modèle ou le logiciel a été créé pour répondre aux questions ci-dessus.

Ces dernières années, nous avons vu comment fournir publique et vérifiable les informations sur ce qui se passe au cours des différentes étapes du développement logiciel constituent une méthode efficace pour protéger les logiciels conventionnels contre les attaques de la chaîne logistique. Cette transparence de la chaîne d’approvisionnement offre une protection et des informations avec :

  • Les signatures numériques, comme celles de Sigstorequi permettent aux utilisateurs de vérifier que le logiciel n’a pas été falsifié ou remplacé
  • Des métadonnées telles que Provenance SLSA qui nous indiquent le contenu du logiciel et comment il a été construit, permettant ainsi aux consommateurs de garantir la compatibilité des licences, d’identifier les vulnérabilités connues et de détecter les menaces plus avancées.

Ensemble, ces solutions contribuent à lutter l’énorme augmentation des attaques contre la chaîne d’approvisionnement qui ont transformé chaque étape du cycle de vie du développement logiciel en une cible potentielle pour les activités malveillantes.

Nous pensons que la transparence tout au long du cycle de développement contribuera également à sécuriser les modèles ML, puisque le développement de modèles ML suit un cycle de vie similaire comme pour les artefacts logiciels classiques :

Similitudes entre le développement de logiciels et le développement de modèles ML

Un processus de formation ML peut être considéré comme une « build » : il transforme certaines données d’entrée en données de sortie. De même, les données de formation peuvent être considérées comme une « dépendance » : ce sont des données qui sont utilisées pendant le processus de construction. En raison de la similitude des cycles de vie du développement, les mêmes vecteurs d’attaque de la chaîne d’approvisionnement logicielle qui menacent le développement logiciel s’appliquent également au développement de modèles :

Vecteurs d’attaque sur le ML à travers le prisme de la chaîne d’approvisionnement du ML

Sur la base des similitudes entre le cycle de vie du développement et les vecteurs de menace, nous proposons d’appliquer les mêmes solutions de chaîne d’approvisionnement de SLSA et Sigstore aux modèles ML pour les protéger de la même manière contre les attaques de la chaîne d’approvisionnement.

La signature de code est une étape cruciale dans la sécurité de la chaîne d’approvisionnement. Il identifie le producteur d’un logiciel et empêche toute falsification après publication. Mais normalement, la signature de code est difficile à mettre en place : les producteurs doivent gérer et alterner les clés, mettre en place une infrastructure de vérification et expliquer aux consommateurs comment procéder. Souvent, des secrets sont également divulgués car la sécurité est difficile à mettre en place pendant le processus.

Nous suggérons de contourner ces défis en utilisant Sigstore, un ensemble d’outils et de services qui rendent la signature de code sécurisée et simple. Sigstore permet à tout producteur de logiciels de signer son logiciel en utilisant simplement un jeton OpenID Connect lié soit à une charge de travail, soit à l’identité du développeur, le tout sans avoir besoin de gérer ou de faire pivoter des secrets de longue durée.

Alors, comment la signature de modèles ML profiterait-elle aux utilisateurs ? En signant les modèles après la formation, nous pouvons garantir aux utilisateurs qu’ils disposent du modèle exact que le constructeur (alias « formateur ») a téléchargé. Signer des modèles décourage propriétaires de hubs de modèles d’échange de modèles, aborde le problème d’un compromis de hub de modèles, und peut aider à empêcher les utilisateurs d’être amenés à utiliser un mauvais modèle.

Les signatures de modèles provoquent des attaques similaires à PoisonGPT détectable. Les modèles falsifiés échoueront à la vérification de la signature ou pourront être directement retracés jusqu’à l’acteur malveillant. Notre travail actuel pour encourager cette norme industrielle comprend :

  • Faire en sorte que les frameworks ML intègrent la signature et la vérification dans les API de sauvegarde/chargement du modèle
  • Les hubs de modèles ML ajoutent un badge à tous les modèles signés, guidant ainsi les utilisateurs vers les modèles signés et encourageant les signatures des développeurs de modèles.
  • Signature de modèle à grande échelle pour les LLM

La signature avec Sigstore donne aux utilisateurs confiance dans les modèles qu’ils utilisent, mais elle ne peut pas répondre à toutes les questions qu’ils se posent sur le modèle. SLSA va encore plus loin pour donner plus de sens à ces signatures.

SLSA (Supply-chain Levels for Software Artifacts) est une spécification permettant de décrire la manière dont un artefact logiciel a été construit. Les plates-formes de construction compatibles SLSA mettent en œuvre des contrôles pour empêcher la falsification et les sorties signées provenance décrivant comment l’artefact logiciel a été produit, y compris toutes les entrées de construction. De cette façon, SLSA fournit des métadonnées fiables sur ce qui est entré dans un artefact logiciel.

L’application de SLSA au ML pourrait fournir des informations similaires sur la chaîne d’approvisionnement d’un modèle de ML et s’attaquer aux vecteurs d’attaque non couverts par la signature du modèle, tels qu’un contrôle de source compromis, un processus de formation compromis et une injection de vulnérabilités. Notre vision est d’inclure des informations ML spécifiques dans un fichier de provenance SLSA, ce qui aiderait les utilisateurs à repérer un modèle sous-entraîné ou formé sur de mauvaises données. En détectant une vulnérabilité dans un framework ML, les utilisateurs peuvent rapidement identifier les modèles qui doivent être recyclés, réduisant ainsi les coûts.

Nous n’avons pas besoin d’extensions ML spéciales pour SLSA. Étant donné qu’un processus de formation ML est une construction (illustré dans le diagramme précédent), nous pouvons appliquer les directives SLSA existantes à la formation ML. Le processus de formation ML doit être renforcé contre la falsification et la provenance des résultats, tout comme un processus de construction conventionnel. Plus de travail sur SLSA est nécessaire pour le rendre pleinement utile et applicable au ML, en particulier pour décrire les dépendances telles que les ensembles de données et les modèles pré-entraînés. La plupart de ces efforts bénéficieront également aux logiciels conventionnels.

Pour la formation de modèles sur des pipelines qui ne nécessitent pas de GPU/TPU, l’utilisation d’une plate-forme de construction existante compatible SLSA est une solution simple. Par exemple, Google Cloud Build, Actions GitHubou GitLabCI sont toutes des plates-formes de construction compatibles SLSA généralement disponibles. Il est possible d’exécuter une étape de formation ML sur l’une de ces plates-formes pour rendre toutes les fonctionnalités intégrées de sécurité de la chaîne d’approvisionnement disponibles pour les logiciels conventionnels.

En intégrant dès maintenant la sécurité de la chaîne d’approvisionnement dans le cycle de vie du développement du ML, alors que les problèmes sont encore en cours, nous pouvons relancer le travail avec la communauté open source pour établir des normes industrielles afin de résoudre les problèmes urgents. Cet effort est déjà en cours et disponible pour des tests.

Notre référentiel d’outils pour la signature de modèles et la prise en charge expérimentale de la provenance SLSA pour les petits modèles ML est disponible dès maintenant. Nos futures intégrations de framework ML et de hub de modèles seront également publiées dans ce référentiel.

Nous apprécions la collaboration avec la communauté ML et sommes impatients de parvenir à un consensus sur la meilleure façon d’intégrer les normes de protection de la chaîne d’approvisionnement dans les outils existants (tels que Cartes modèles). Si vous avez des retours ou des idées, n’hésitez pas ouvrir un sujet et faites-le-nous savoir.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici