Date de la publication : 22 janvier 2025

Lecture : 16 min

Mise en conformité SOC 2 : GitLab vous simplifie la tâche

Découvrez les fonctionnalités de sécurité applicative de la plateforme DevSecOps de GitLab pour vous conformer aux exigences de la norme SOC 2.

Pour les entreprises qui traitent les informations sensibles des clients, la conformité à la norme System and Organization Controls 2 (SOC 2) dépasse le cadre des bonnes pratiques : c'est souvent un impératif commercial. La norme d'audit SOC 2, développée par l'American Institute of Certified Public Accountants, évalue les contrôles internes d'un prestataire de services autour de cinq piliers essentiels : la sécurité, la disponibilité, l'intégrité des traitements de données, la confidentialité et la confidentialité.

Bien qu'elle ne soit pas imposée par la loi, la conformité SOC 2 est devenue un enjeu stratégique, renforcée par la fréquence et la médiatisation croissantes des violations de données. Obtenir la certification SOC 2 vous permet d'établir un lien de confiance avec vos clients, de leur démonter que leurs données sont protégées et de leur garantir que vos contrôles de sécurité ont été évalués par un auditeur tiers indépendant.

Découvrez dans ce guide les exigences à remplir pour obtenir la certification SOC 2 et comment GitLab peut aider votre entreprise à respecter les normes les plus strictes en matière de sécurité applicative.

Quelles sont les exigences fixées par la norme SOC 2 ?

Le processus de conformité repose sur un audit réalisé par un cabinet indépendant, chargé d'évaluer à la fois la conception et l'efficacité opérationnelle des contrôles mis en place par l'entreprise concernée. L'audit SOC 2 peut durer près d'un an et s'avérer particulièrement coûteux. Nombreuses sont les entreprises qui s'y confrontent sans préparation suffisante, d'où l'importance de bien se préparer en amont.

Pour obtenir la certification SOC 2, une entreprise doit répondre aux exigences basées sur les critères de services de confiance suivants :

| Critères | Exigences |

| :---- | :---- |

| Sécurité | - Mettre en place des contrôles pour prévenir tout accès non autorisé
- Définir des procédures d'identification et d'atténuation des risques
- Mettre en œuvre des systèmes de détection et de traitement des incidents de sécurité |

| Disponibilité | - Garantir la disponibilité des systèmes selon les engagements contractuels
- Surveiller l'utilisation et la capacité des systèmes en temps réel
- Identifier et traiter les menaces environnementales susceptibles d'affecter la disponibilité des systèmes |

| Intégrité des opérations de traitement | - Tenir des registres précis des entrées et sorties du système
- Mettre en place des procédures pour détecter et corriger rapidement les erreurs
- Veiller à ce que les opérations de traitement respectent les spécifications des produits et services |

| Confidentialité | - Identifier et protéger les informations confidentielles
- Définir des politiques claires de conservation des données pour une période définie
- Mettre en place des méthodes sécurisées de suppression de ces données à l'issue de la période de conservation |

| Vie privée | - Obtenir le consentement avant toute collecte de données personnelles sensibles
- Communiquer de façon claire et compréhensible les politiques de confidentialité
- Collecter les données uniquement par des moyens légaux et auprès de sources fiables |


Il est essentiel de noter que la conformité SOC 2 n'est pas un état ponctuel, mais un processus continu. Les auditeurs devront vérifier l'efficacité des contrôles au fil du temps.

Comment atteindre et maintenir les exigences de sécurité ?

GitLab fournit un ensemble de fonctionnalités intégrées à sa plateforme pour vous aider à satisfaire les exigences de sécurité de la norme SOC 2. En voici un aperçu :

| Exigence de sécurité | Fonctionnalités associées |

| :---- | :---- |

| Mettre en œuvre des contrôles pour prévenir tout accès non autorisé | - Tickets et merge requests confidentiels
- Rôles personnalisés et autorisations granulaires
- Stratégies de sécurité
- Validations vérifiées
- Images de conteneur signées
- CodeOwners
- Branches protégées |

| Mettre en œuvre des systèmes de détection et de traitement des incidents de sécurité | - Scanning de détection des vulnérabilités
- Widget de sécurité intégré aux merge requests
- Centre de conformité avec tous les détails sur les vulnérabilités
- Événements d'audit
- Liste des dépendances dans les rapports de vulnérabilités
- IA : explication des vulnérabilités
- IA : résolution des vulnérabilités |

| Définir des procédures d'identification et d'atténuation des risques | L'ensemble de ces fonctionnalités permet aux équipes de sécurité de définir des procédures claires pour la gestion des vulnérabilités, de leur identification à leur atténuation.


| Passons maintenant en revue chaque section pour détailler les fonctionnalités de sécurité de GitLab qui permettent de répondre à ces exigences. Remarque : la plupart de ces fonctionnalités nécessitent un abonnement GitLab Ultimate ainsi que les rôles et autorisations adéquats. Pour en savoir plus, consultez la documentation officielle.

Quels contrôles mettre en place éviter tout accès non autorisé ?

La mise en œuvre de contrôles d'accès rigoureux est essentielle pour protéger les actifs de votre entreprise, garantir la conformité réglementaire, maintenir la continuité des opérations et instaurer la confiance. Avec GitLab, vous pouvez appliquer le principe de moindre privilège afin de sécuriser vos projets contre tout accès non autorisé. Voici un aperçu des fonctionnalités disponibles :

Stratégies de sécurité

Les stratégies de sécurité de GitLab, connues sous le nom de garde-fous, permettent aux équipes de sécurité et de conformité d'appliquer des contrôles cohérents à l'échelle de l'entreprise. Elles contribuent à prévenir les incidents de sécurité, à maintenir les normes de conformité et à réduire les risques en automatisant l'application des bonnes pratiques de sécurité à grande échelle.

Vue de la politique d'approbation des merge requests

Vue de la politique d'approbation des merge requests

GitLab propose les différents types de stratégies de sécurité suivants :

  • Stratégie d'exécution des scans : impose l'exécution de scans de sécurité, soit dans les pipelines CI/CD, soit selon un calendrier précis.

  • Politique d'approbation des merge requests : applique des paramètres et des règles d'approbation au niveau du projet en fonction des résultats des scans.

  • Stratégie d'exécution des pipelines : impose l'exécution de jobs CI/CD critiques dans les pipelines.

  • Stratégie de gestion des vulnérabilités : automatise les workflows de gestion des vulnérabilités.

Voici à titre d'exemple les étapes de mise en conformité en appliquant une stratégie d'exécution des pipelines :

  1. Créez un projet dédié aux jobs de conformité, contenant plusieurs tâches applicables à différents projets. Par exemple, un job peut avoir pour objectif de vérifier les autorisations d'accès aux fichiers déployés. Ces jobs doivent être suffisamment génériques pour être réutilisés sur plusieurs applications

.2. Limitez les autorisations sur ce projet aux seuls responsables sécurité ou conformité. Les équipes de développement ne doivent pas pouvoir modifier ou supprimer ces jobs, afin de garantir une séparation claire des responsabilités.

  1. Injectez ces jobs de conformité par lots dans les projets concernés. Configurez-les pour qu'ils s'exécutent systématiquement, sans possibilité de suppression, mais autorisez un responsable d'équipe à approuver leur exécution afin de ne pas bloquer le développement. Ainsi, vous vous assurez que les jobs de conformité sont toujours lancés, qu'ils ne peuvent pas être désactivés par les développeurs, et que votre environnement reste conforme aux exigences établies.
Pour approfondir vos connaissances sur le sujet, consultez notre documentation dédiée aux stratégies de sécurité.

Rôles personnalisés et autorisations granulaires

Les autorisations personnalisées dans GitLab permettent de définir des contrôles d'accès plus précis que ceux des autorisations standard basées sur les rôles. Elles offrent plusieurs avantages, tels que :

  • Un contrôle d'accès plus précis

  • Une meilleure conformité aux exigences de sécurité

  • Une réduction du risque d'accès accidentel

  • Une gestion des utilisateurs simplifiée

  • Une prise en charge adaptée aux structures organisationnelles complexes

Rôles personnalisés dans GitLab

Paramètres des rôles et autorisations, y compris les rôles personnalisés
Pour approfondir vos connaissances sur le sujet, consultez notre documentation dédiée aux rôles personnalisés.

Protections des branches et CodeOwners

GitLab vous aide à mieux contrôler qui peut modifier votre code à l'aide de ces deux fonctionnalités avancées :

  • La protection des branches, qui permet de définir des règles précises sur qui peut mettre à jour des branches spécifiques, par exemple en imposant une approbation avant de fusionner les modifications.

  • La propriété du code, qui identifie automatiquement les relecteurs appropriés pour examiner les modifications apportées au code en associant chaque fichier à ses propriétaires désignés.

Combinées, ces fonctionnalités vous aident à garantir la sécurité et la qualité de votre code en vous assurant que les bonnes personnes examinent et approuvent chaque modification.

Branches protégées

Paramètres de branches protégées
Pour approfondir vos connaissances sur le sujet, consultez notre documentation dédiée aux branches protégées et aux propriétaires de code.

Validations vérifiées

En signant vos validations numériquement, vous prouvez que vous en êtes l'auteur et non une personne qui se fait passer pour vous. Considérez cette signature numérique comme un tampon unique que vous seul pouvez créer. En téléversant votre clé publique GPG sur la plateforme GitLab, cette dernière peut vérifier l'authenticité de ce tampon. Si la signature et le tampon correspondent, GitLab marque votre validation comme Verified. Vous pouvez ensuite configurer des règles pour rejeter les validations non signées ou bloquer toutes les validations des utilisateurs qui n'ont pas vérifié leur identité.

Validation signée avec une signature vérifiée

Validation signée avec une signature vérifiée

Les validations peuvent être signées avec :

  • Une clé SSH

  • Une clé GPG

  • Un certificat x.509 personnel

Pour approfondir vos connaissances sur le sujet, consultez notre documentation dédiée aux validations signées

Comment mettre en place des systèmes de détection et de gestion des incidents°?

La mise en place de systèmes de détection et de gestion des incidents de sécurité est essentielle pour maintenir une posture de sécurité robuste, garantir la conformité réglementaire, limiter les dommages potentiels et permettre à votre entreprise de réagir efficacement à des menaces en constante évolution.

GitLab propose des scannings de sécurité et de gestion des vulnérabilités pour l'ensemble du cycle de vie des applications. Voici un aperçu des principales fonctionnalités :

Scanning de sécurité et gestion des vulnérabilités

GitLab fournit une variété de scanners de sécurité différents, qui couvrent l'ensemble du cycle de vie de votre application :

  • Test statique de sécurité des applications (SAST)

  • Test dynamique de sécurité des applications (DAST)

  • Analyse des conteneurs

  • Analyse des dépendances

  • Analyse de l'Infrastructure as Code (IaC)

  • Test à données aléatoires guidé par la couverture de code

  • Test d'API web par injection de données aléatoires

Ces scanners peuvent être ajoutés à votre pipeline CI/CD à l'aide de templates. Par exemple, pour exécuter des jobs de SAST et de scanning des dépendances à l'étape de test, ajoutez simplement ce qui suit à votre fichier .gitlab-ci.yml :


stages:   - test

include:   - template: Jobs/Dependency-Scanning.gitlab-ci.yml   - template: Jobs/SAST.gitlab-ci.yml   ```


Ces jobs sont entièrement configurables via des variables d'environnement et à l'aide de la syntaxe des jobs GitLab. Une fois le pipeline CI/CD lancé, les scanners de sécurité s'exécutent et détectent les vulnérabilités dans le diff entre la branche actuelle et la branche cible. La vulnérabilité s'affiche directement dans la merge request (MR) correspondante, fournissant ainsi une vue détaillée avant que le code ne soit fusionné vers la branche cible. Dans la MR, chaque vulnérabilité détectée est présentée avec les informations suivantes :


* Description

* Statut

* Gravité

* Preuves

*Identifiants

* URL (le cas échéant)

* Requête/réponse (le cas échéant)

* Actifs de reproduction (le cas échéant)

* Ressources de formation (le cas échéant)

* Chemin d'exécution dans le code (si vous utilisez un analyseur Advanced SAST)


![Vue d'une MR présentant la vulnérabilité détectée](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)


<center><i>Vue d'une MR présentant la vulnérabilité introduite</i></center><br>


Les équipes de développement peuvent ainsi utiliser ces données pour corriger les vulnérabilités sans ralentir les workflows de l'équipe de sécurité. Les développeurs peuvent rejeter une vulnérabilité en justifiant leur décision, accélérant ainsi le processus de revue de code. Ils ont également la possibilité de créer un ticket confidentiel pour assurer un suivi sur cette vulnérabilité.


Une fois le code d'une MR fusionné vers la branche par défaut (généralement celle de l'environnement de production), le rapport de vulnérabilités est automatiquement mis à jour avec les résultats du scanner de sécurité. Les équipes de sécurité peuvent utiliser ces données pour gérer et hiérarchiser les vulnérabilités ayant atteint l'environnement de production.


![Rapport de vulnérabilités avec le paramètre de statut par lot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)


<center><i>Rapport de vulnérabilités avec le paramètre de statut par lot</i></center><br>


Lorsque vous cliquez sur la description d'une vulnérabilité dans le rapport de vulnérabilités, vous accédez à la page dédiée à cette vulnérabilités, qui contient les mêmes informations que dans la MR. Vous disposez ainsi d'une source unique de vérité lors de l'évaluation de son impact et de la correction possible. Depuis cette page, vous pouvez également utiliser les fonctionnalités d'IA de [GitLab Duo](https://about.gitlab.com/fr-fr/gitlab-duo/) pour obtenir une explication de la vulnérabilité et générer automatiquement une merge request pour la corriger, ce qui accélère considérablement le temps de résolution.


> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée à la sécurité aplicative](https://docs.gitlab.com/ee/user/application_security/).


### Nomenclature logicielle


GitLab peut créer une liste complète de tous les composants constituant votre logiciel, un peu comme une liste d'ingrédients pour votre code. Cette liste, appelée nomenclature logicielle ([SBOM](https://about.gitlab.com/fr-fr/blog/the-ultimate-guide-to-sboms/)), répertorie l'ensemble du code des composants externes que vous avez ajoutés à votre projet, ainsi que leurs propres dépendances. Pour chaque composant, vous pouvez consulter la version utilisée, le type de licence ainsi que les éventuelles failles de sécurité détectées. Vous pouvez ainsi conserver une trace des composants de votre logiciel et anticiper les risques potentiels.


![Liste des dépendances au niveau du groupe (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)


<center><i>Liste des dépendances au niveau du groupe (SBOM)</i></center>


> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée à la liste des dépendances](https://docs.gitlab.com/ee/user/application_security/dependency_list/).


### Audit système et examen de la posture de sécurité


GitLab consigne de manière exhaustive toutes les actions effectuées dans votre système : qui a réalisé une modification, de quel type, et à quel moment. Cette fonctionnalité agit en quelque sorte comme une caméra de surveillance pour votre code. Cette traçabilité vous aide à :


* repérer toute activité suspecte

* prouver votre conformité aux régulateurs

* retracer les événements en cas d'incident de sécurité

* analyser l'utilisation réelle de GitLab au sein de l'entreprise


Toutes ces informations d'audit sont centralisées, ce qui facilite grandement leur examen a posteriori et leur analyse en cas de besoin. Par exemple, les événements d'audit vous permettent d'identifier :


* qui a modifié le niveau d'autorisation d'un utilisateur pour un projet GitLab, et à quelle date

* qui a ajouté ou supprimé un utilisateur, et à quelle date


![Événements d'audit au niveau du projet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)


<center><i>Événements d'audit au niveau du projet</i></center>


> ##### Pour approfondir vos connaissances sur le sujet, consultez la [documentation dédiée aux événements d'audit](https://docs.gitlab.com/ee/user/compliance/audit_events.html).


## Supervision de la conformité et de la posture de sécurité


Le tableau de bord de sécurité de GitLab, telle une salle de contrôle centralisée, vous offre une vue globale claire de tous les risques de sécurité identifiés sur l'ensemble de vos projets. Plutôt que de jongler entre plusieurs outils de sécurité, toutes les informations critiques sont accessibles depuis un seul et même endroit. Cette fonctionnalité facilite la détection et la résolution des vulnérabilités à l'échelle de vos projets.


![Tableau de bord de sécurité au niveau du groupe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)

<center><i>Tableau de bord de sécurité au niveau du groupe</i></center>


> ##### Pour approfondir vos connaissances sur le sujet, consultez notre [documentation dédiée au tableau de bord de sécurité]( https://docs.gitlab.com/ee/user/application_security/security_dashboard/).


## Comment définir des procédures pour identifier et atténuer les risques ?


Les vulnérabilités suivent un cycle de vie précis et il est essentiel de mettre en place des procédures structurées. Par exemple, l'une d'elles peut exiger qu'aucun code vulnérable ne soit fusionné vers des branches protégées sans approbation préalable, en s'appuyant sur les stratégies de sécurité en place. Elle peut également stipuler qu'un code vulnérable détecté dans l'environnement de production doit se voir attribuer un ordre de priorité, puis être évalué, corrigé, puis validé :


* Les critères de priorisation peuvent être basés sur la gravité de la vulnérabilité déterminée par les scanners GitLab.

* L'évaluation peut s'appuyer sur les informations générées par l'IA lors de l'explication des vulnérabilités.

* Une fois la correction apportée, celle-ci est validée à l'aide des tests de régression et des scanners GitLab intégrés.


Chaque entreprise ayant ses spécificités, la plateforme GitLab permet d'identifier et valider les vulnérabilités plus efficacement qu'avec un ensemble d'outils disparates.


### Bonnes pratiques pour la conformité SOC 2


* Instaurer une culture de la sécurité : favorisez une culture de sensibilisation à la sécurité et de responsabilisation à tous les niveaux de votre entreprise.

* Documenter chaque processus : conservez une documentation complète des stratégies, procédures et contrôles de sécurité en place.

* Automatiser dans la mesure du possible : utilisez des outils d'automatisation pour rationaliser les processus de conformité et réduire les risques d'erreur.

* Communiquer efficacement : tenez les parties prenantes informées de vos processus en matière de conformité.

* Demander conseil à des experts : envisagez de vous associer à un consultant qualifié pour vous aider dans votre parcours de conformité SOC 2.


Obtenir la certification SOC 2 demande un investissement important, mais les bénéfices en valent largement la peine. En démontrant votre engagement en faveur de la sécurité applicative et de l'excellence opérationnelle, vous renforcez la confiance de vos clients, améliorez votre réputation tout en vous distinguant sur un marché concurrentiel.


## Autres ressources


Pour en savoir plus sur GitLab et découvrir comment nous pouvons vous aider à atteindre la conformité SOCv2 tout en renforçant votre posture de sécurité, consultez les ressources suivantes :


* [GitLab Ultimate](https://about.gitlab.com/fr-fr/pricing/ultimate/)

* [Solutions de sécurité et de conformité de GitLab](https://about.gitlab.com/fr-fr/solutions/security-compliance/)

* [Documentation GitLab sur la sécurité applicative](https://docs.gitlab.com/ee/user/application_security/)

* [Projet de tutoriel DevSecOps de GitLab](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)

Votre avis nous intéresse

Cet article de blog vous a plu ou vous avez des questions ou des commentaires ? Partagez vos réflexions en créant un sujet dans le forum de la communauté GitLab.
Share your feedback

Plus de 50 % des entreprises du classement Fortune 100 font confiance à GitLab

Commencez à livrer des logiciels de meilleurs qualité plus rapidement

Découvrez comment la plateforme DevSecOps intelligente

peut aider votre équipe.