Frameworks de conformité GitLab : adhérez à la norme SOC 2 en quelques minutes

La conformité est l'aspect de la livraison logicielle que tout le monde estime essentiel, mais que personne n'apprécie vraiment. Elle se résume souvent à des feuilles de calcul, des captures d'écran et la crainte diffuse d'un audit imminent. Les frameworks de conformité personnalisés de GitLab fonctionnent différemment. Au lieu de documenter ce que vos projets devraient respecter, vous définissez les contrôles une seule fois et laissez la plateforme vérifier en continu ce qu'il en est réellement.

Dans cet article, vous découvrirez l'importance de l'adhésion aux frameworks de conformité, comment mettre en place un framework SOC 2 en quelques minutes à l'aide d'un template, comment surveiller la conformité de façon continue, comment appliquer la conformité via des politiques et quelles normes sont déjà disponibles sous forme de templates prêts à l'emploi. Vous profiterez également d'un aperçu des templates de conformité spécifiques à l'IA en cours de développement. Regardez la vidéo ci-dessous pour voir tous ces éléments en action :

Remarque : les frameworks de conformité sont disponibles dans GitLab Premium et GitLab Ultimate. Les exigences et contrôles des frameworks, qui alimentent les rapports relatifs à l'adhésion aux frameworks de conformité et le rapport de statut de conformité, nécessitent GitLab Ultimate. Toutes les étapes décrites dans cet article s'appliquent à GitLab.com, GitLab Self-Managed et GitLab Dedicated.

L'importance de la conformité et des frameworks personnalisés

Les obligations réglementaires et contractuelles telles que les normes SOC 2, ISO 27001 et PCI DSS existent parce que les clients, les partenaires et les régulateurs veulent avoir la certitude que votre logiciel est développé et livré de manière responsable. Leur non-respect n'est pas qu'un problème administratif : il peut bloquer des signatures de contrats, entraîner des amendes, retarder des lancements de produits et éroder la confiance. La conformité n'est pas non plus une démarche ponctuelle. Un projet conforme au moment de l'audit peut dériver dès qu'un scanner est désactivé, qu'une protection de branche est supprimée ou qu'une merge request est fusionnée sans les autorisations requises.

Les frameworks de conformité personnalisés sont conçus pour combler ces lacunes. Un framework de conformité dans GitLab est un label que vous créez dans un groupe principal pour identifier les projets soumis à des obligations de conformité spécifiques ou nécessitant une surveillance accrue. En lui-même, ce label offre organisation et visibilité. Dans GitLab Ultimate, un framework peut également comporter des exigences composées de contrôles, soit des vérifications automatisées de la configuration et du comportement de chaque projet auquel le framework est appliqué.

Plutôt que de demander à un ingénieur de confirmer que le test statique de sécurité des applications (SAST) est en cours d'exécution, que la branche par défaut est protégée et que les merge requests nécessitent deux approbations, GitLab évalue ces conditions pour vous à une cadence précise et à chaque modification des paramètres concernés du projet. La conformité cesse d'être un instantané constitué avant un audit pour devenir un élément que vous surveillez tout au long de l'année. Les frameworks sont créés au niveau du groupe principal et hérités par tous les sous-groupes et projets qui en dépendent. Vous pouvez appliquer jusqu'à 20 frameworks à un seul projet lorsqu'il doit satisfaire plusieurs normes simultanément.

Cette approche fait évoluer le travail quotidien de plusieurs façons. La conformité est déplacée en amont dans le workflow de développement, la préparation des audits devient une simple exportation de rapport plutôt qu'une reconstitution de preuves, et la cohérence est assurée par la plateforme plutôt que par les bonnes intentions.

Appliquer un template pour adhérer à la norme SOC 2

Construire un framework manuellement implique de définir chaque exigence et chaque contrôle un par un. Pour une norme comme SOC 2 qui couvre de nombreux contrôles, le processus est répétitif et source d'erreurs. Les templates résolvent ce problème en vous fournissant un framework complet et prédéfini, avec le nom, la description, la couleur, les exigences et les contrôles déjà configurés, que vous pouvez adopter en une seule étape.

Le projet Compliance Adherence Templates héberge une bibliothèque de ces frameworks sous forme de fichiers JSON, dont soc2.json.

Deux méthodes permettent d'intégrer un template dans votre groupe.

Option A : création à partir d'un template dans le Centre de conformité

Vous pouvez créer un framework directement à partir d'un template intégré sans quitter l'interface :

1. Accédez à votre groupe principal.
2. Dans l'onglet latéral, sélectionnez Sécurisation > Centre de conformité.
3. Cliquez sur le bouton Nouveau framework.
4. Choisissez Créer à partir d'un modèle.
5. Faites défiler jusqu'au template SOC 2 et sélectionnez Afficher les détails pour voir les contrôles implémentés par le template.
6. Cliquez sur le bouton Utiliser ce modèle pour implémenter le template SOC 2. Personnalisez le nom, la description et la couleur si vous le souhaitez. Sélectionnez Suivant lorsque vous avez terminé.
7. Prévisualisez les exigences et les contrôles inclus.
8. Appliquez le framework aux groupes/projets concernés.
9. Cliquez sur le bouton Créer un framework.

Votre framework est créé et sera appliqué aux groupes/projets que vous avez sélectionnés.

Option B : importation d'un template SOC 2 au format JSON

Si vous utilisez une version de GitLab sans le sélecteur de templates intégré, ou si vous souhaitez conserver le template sous contrôle de version et le modifier au préalable, importez directement le fichier JSON :

1. Accédez au projet Compliance Adherence Templates et téléchargez soc2.json.
2. Accédez à votre groupe principal.
3. Sélectionnez Sécurisation > Centre de conformité.
4. Dans l'onglet Frameworks, sélectionnez Nouveau framework, puis Importer un framework.
5. Choisissez le fichier soc2.json depuis votre système local.
6. Une fois l'importation réussie, le framework SOC 2 apparaît dans votre liste de frameworks.

Un framework n'a d'effet qu'une fois associé à des projets. Veillez à appliquer ce framework aux groupes/projets où il sera utilisé.

Remarque : les importations échouent avec l'erreur Unable to determine the correct upload URL si un framework portant le même nom existe déjà. Renommez ou supprimez d'abord le framework existant.

Modifier et appliquer le framework à vos projets

Vous pouvez également modifier le framework que vous venez de créer et l'appliquer à des groupes/projets supplémentaires :

1. Dans Sécurisation > Centre de conformité, ouvrez l'onglet Frameworks.
2. Survolez le framework SOC 2 et sélectionnez Modifier le framework.
3. Dans la section Exigences et contrôles, sous Action, sélectionnez ... > Modifier.
4. Effectuez les modifications nécessaires aux exigences ou aux contrôles.
5. Dans la section Définition du périmètre, sélectionnez les groupes/projets pertinents pour la norme SOC 2.
6. Sélectionnez Mettre à jour le framework.

Si vous souhaitez que chaque nouveau projet du groupe hérite automatiquement de la norme SOC 2, définissez le framework comme framework par défaut du groupe dans la section Informations de base. Le framework sera alors appliqué à tous les projets créés et importés par la suite.

Ce que le template SOC 2 vérifie concrètement

Une fois appliqué, le framework SOC 2 associe les contrôles GitLab aux critères de services de confiance pertinents. Voici quelques points clés :

Une fois le framework appliqué à un projet, GitLab exécute une analyse de conformité et commence à indiquer si chaque contrôle est respecté. Aucune collecte manuelle de preuves n'est nécessaire.

Surveiller en continu le statut de conformité

Appliquer un framework ne représente que la moitié de la valeur. L'autre moitié consiste à connaître, à tout moment, votre statut de conformité. C'est le rôle du rapport de statut de conformité (GitLab Ultimate), accessible dans votre groupe principal sous Sécurisation > Centre de conformité > Statut.

Le rapport présente les instances les plus récentes où les projets respectent et ne respectent pas les contrôles d'un framework, afin que vous puissiez identifier et corriger rapidement les failles. Chaque ligne vous indique :

• Le statut : si une exigence est conforme ou non
• L'exigence : les contrôles spécifiques d'une exigence qui ont échoué (par exemple, « Au moins deux approbations »)
• Le framework : le framework auquel appartient le contrôle (par exemple, SOC 2)
• Le projet : où la non-conformité a été détectée
• La dernière analyse : quand l'écart a été enregistré pour la première fois
• Les suggestions de correction : informations sur la façon de résoudre le problème

Vous pouvez filtrer par projet, framework ou exigence, accéder directement à la vue détaillée de conformité d'un projet et exporter l'intégralité du rapport (livré dans votre boîte de réception en pièce jointe) lorsqu'un auditeur demande des preuves.

En coulisses, les analyses qui actualisent le rapport sont déclenchées automatiquement lorsqu'un framework est ajouté à un projet, lorsque les exigences d'un framework associé changent et selon une cadence récurrente de 12 heures. Les résultats apparaissent généralement cinq à dix minutes après l'exécution d'une analyse. Cela signifie que les dérives de conformité deviennent visibles en quelques heures plutôt qu'au prochain audit annuel. Pour consulter le rapport, vous devez être administrateur ou disposer du rôle Responsable de sécurité ou Propriétaire du groupe concerné.

Assurer la conformité via des politiques

Les rapports indiquent la présence d'un problème. Les politiques empêchent les problèmes de se produire en premier lieu. C'est là que les frameworks de conformité passent de l'observation à l'application, et il s'agit d'une capacité de GitLab Ultimate liée au label du framework.

Un framework de conformité peut servir de portée pour les politiques de sécurité. Les politiques d'exécution des scans, les politiques d'exécution des pipelines et les politiques d'approbation des merge requests peuvent être limitées à un framework de conformité, de sorte que chaque projet portant ce label les hérite automatiquement. Par exemple, vous pouvez exiger que le SAST, la détection des secrets et l'analyse des dépendances s'exécutent sur la branche par défaut, et exiger l'approbation d'une équipe de sécurité désignée avant qu'une merge request introduisant de nouvelles vulnérabilités critiques puisse être fusionnée. Comme la politique est liée au framework plutôt qu'à des projets individuels, l'ajout d'un nouveau projet au framework lui fait immédiatement hériter des mêmes garde-fous.

Tous ces éléments fonctionnent ensemble : le framework définit l'obligation, les contrôles et le rapport de statut évaluent l'adhésion au framework de conformité, et les politiques et pipelines de conformité appliquent le comportement. Vous ne vous contentez pas de documenter que la norme SOC 2 exige deux approbations et des scanners. Vous faites en sorte qu'il soit difficile de livrer tout ce qui enfreindrait ces exigences. Lorsqu'un contrôle échoue, le rapport de statut le signale. Lorsqu'une politique est en place, la modification non conforme est bloquée avant son merge.

Templates disponibles

GitLab propose une bibliothèque croissante de templates de frameworks prédéfinis dans le projet Compliance Adherence Templates , chacun associant une norme reconnue aux contrôles GitLab. À la date de publication de cet article, la bibliothèque propose les templates suivants :

Le mappage précis exigences-contrôles de chaque template est documenté dans la référence des normes de conformité. Vous pouvez importer chaque template tel quel, ou l'utiliser comme point de départ. Exportez un framework au format JSON, ajustez les exigences et les contrôles souhaités par votre organisation en fonction de son interprétation de la norme, puis réimportez-le. Le schéma JSON est simple. Un framework possède les éléments suivants : un nom (name), une description (description), une couleur (color) et des exigences sous forme de tableau (requirements), chacune avec ses propres contrôles (controls) et une expression d'évaluation (expression). Il est ainsi facile de gérer le contrôle de version des templates et de les partager.

Perspectives : les templates de conformité spécifiques à l'IA

Les normes de conformité abordées dans cet article ont été rédigées en grande partie pour les logiciels traditionnels. À mesure que les organisations intègrent l'IA dans leurs produits et leurs propres workflows de développement, une nouvelle catégorie d'obligations émerge autour de la gouvernance de la conception, de l'approbation et de la surveillance des systèmes d'IA. Parmi les exemples figurent le règlement européen sur l'intelligence artificielle, la norme ISO/IEC 42001 et l'AI Risk Management Framework du NIST.

GitLab explore des templates de conformité pour la gouvernance de l'IA (epic 16808, avec suivi de la planification dans l'élément de travail 22336) pour étendre le même modèle basé sur des templates à ce domaine. L'objectif est de permettre aux équipes d'adopter un framework de gouvernance de l'IA aussi facilement qu'elles adoptent la norme SOC 2 aujourd'hui, avec des exigences et des contrôles prédéfinis associés aux obligations spécifiques à l'IA, appliqués aux projets qui développent ou déploient des capacités d'IA, et présentés via le même rapport de statut de conformité.

Il convient de garder à l'esprit une distinction importante. La conformité est l'état de satisfaction d'un ensemble défini d'exigences, tandis que la gouvernance est la capacité continue à maintenir la conformité des systèmes d'IA à mesure que les systèmes et les règles évoluent. La stratégie globale de GitLab associe la détection assistée par l'IA à l'approbation humaine et à une application basée sur des politiques auditables, de sorte que les résultats de l'IA éclairent les décisions, mais que des humains responsables et des contrôles mesurables continuent de valider ce qui est livré. Les templates spécifiques à l'IA constitueraient la rampe d'accès, vous offrant un moyen rapide d'intégrer les exigences émergentes en matière d'IA dans le même système (framework, contrôle, rapport de statut et politique) que vous utilisez déjà pour tout le reste.

Résumé

Les frameworks de conformité personnalisés vous permettent de définir vos obligations une seule fois et de laisser GitLab les vérifier en continu. Les templates éliminent la configuration manuelle au démarrage, de sorte qu'un framework SOC 2 n'est qu'à quelques clics ou à une seule importation JSON. Le rapport de statut de conformité maintient l'adhésion visible selon une cadence de 12 heures, et les politiques de sécurité ainsi que les pipelines de conformité transforment cette visibilité en application concrète. Avec une bibliothèque de normes déjà disponible et des templates spécifiques à l'IA à l'horizon, passer de la simple intention de conformité à la preuve continue de cette conformité n'a jamais été aussi rapide.

Découvrez plus d'informations dans notre documentation sur les frameworks de conformité et essayez la démonstration interactive des frameworks de conformité personnalisés.

Cet article de blog contient des déclarations de nature prospective au sens de la Section 27A du Securities Act de 1933, telle que modifiée, et de la Section 21E du Securities Exchange Act de 1934. Bien que nous pensions que les attentes reflétées dans ces déclarations sont raisonnables, elles sont soumises à des risques, incertitudes, hypothèses et autres facteurs connus et inconnus qui peuvent entraîner des résultats ou conséquences sensiblement différents. De plus amples informations sur ces risques et autres facteurs sont incluses sous la rubrique « Facteurs de risque » dans nos documents déposés auprès de la SEC. Nous ne nous engageons pas à mettre à jour ou à réviser ces déclarations après la date de publication de cet article de blog, sauf si la loi l'exige.