Condition et bonnes pratiques d'usage et de sécurité pour GitLab-forge - Charte du Développeur


Date d’application : 27/09/2024

En tant que développeur travaillant au sein de notre organisation (agents État ou prestataires) et ayant accès à notre instance GitLab-forge on-premises, vous vous engagez à suivre les conditions et bonnes pratiques d'usage et de sécurité énoncées ci-dessous.

Ces mesures visent à garantir la sécurité de la plate-forme et des données hébergées sur GitLab-forge, ainsi certaines des étapes permettant d'être en conformité notamment avec l'arrêté du 8 décembre 2023 portant instruction pour les contrôles annuels de maintenance préventive des systèmes d'information.

En acceptant cette charte, vous vous engagez ainsi à respecter les directives de bonne conduite et de sécurité décrites ci-après et à contribuer à la protection du code, des données et des ressources de notre organisation.

1. Gestion des Identifiants et des Accès :

a. Ne partagez jamais vos identifiants d'accès (nom d'utilisateur, mots de passe, clés SSH, jetons) avec quiconque ;

b. Utilisez des clés SSH sécurisées et gérez-les de manière responsable, en les régénérant si nécessaire ou en cas de perte ;

c. Révoquez immédiatement tout accès non autorisé ou clé compromise.

2. Authentification et Autorisation :

a. Respectez les politiques d'authentification et d'autorisation définies par la Direction du Numérique du Ministère pour accéder aux projets et aux ressources ;

b. N'accordez que les permissions nécessaires pour effectuer vos tâches. Ne pas abuser de privilèges excessifs.

3. Sécurité du code :

a. Vérifiez régulièrement la sécurité de votre code en utilisant des outils d'analyse statique et dynamique ;

b. Signalez et corrigez immédiatement les vulnérabilités de sécurité identifiées dans le code ;

c. Suivez les pratiques de codage sécurisé et évitez les vulnérabilités connues, comme les injections SQL, les failles XSS, etc (l'outil SonarQube mis à disposition peut vous y aider).

4. Gestion des Dépendances :

a. Utilisez uniquement des dépendances et des bibliothèques tierces approuvées et vérifiées pour la sécurité ;

b. Mettez à jour régulièrement les dépendances pour inclure les correctifs de sécurité (l'analyse DAST peut vous aider à résoudre ces challenges, une analyse SAST peut compléter ces points) que ce soit sur les bibliothèques tierces ou des images de conteneurs.

5. Communication Sécurisée :

Utilisez des canaux sécurisés et chiffrés pour toute communication liée au code, y compris les discussions, les tickets et les transferts de fichiers.

6. Protection des données sensibles :

a. N'incluez jamais de données sensibles (mots de passe, clés d'API, données personnelles) dans le code source ;

b. Utilisez des mécanismes sécurisés pour gérer et stocker les données sensibles.

7. Reporting des Incidents de Sécurité :

a. Signalez immédiatement toute suspicion de compromission, vulnérabilité ou incident de sécurité à l'équipe de sécurité ;

b. Ne pas divulguer publiquement les détails des vulnérabilités.

8. Surveillance et Audit :

a. Soyez conscient de l'activité de votre projet, en particulier les pipelines CI/CD et signalez toute activité suspecte ou non autorisée (ticket SPS Architecture et Méthodes ) ;

b. N'hésitez pas à contacter l'équipe du Centre d'Opération de Sécurité - SOC en cas de compromission ou si besoin d'une levée de doute ;

c. Coopérez pleinement lors d'audits de sécurité ou d'enquêtes.

9. Bonnes pratiques d’utilisation de la plate-forme :

a. L'usage de la forge nécessite que vous vous engagiez à communiquer vers l'équipe produit GitLab-forge quant à vos besoins, vos enjeux afin qu'elle y réponde au mieux ;

b. Vous vous engagez par ailleurs à partager vos challenges, pratiques, supports et expériences avec les autres utilisateurs tant au sein du canal Tchap dédié #gitlab-forge que des séquences d'échanges Apéro GitLab ;

c. L'espace disque n'étant pas extensible à l'infini et afin de diminuer votre empreinte carbone, vous vous engagez à régulièrement faire du ménage dans vos projets (dépôts git, registres et artefacts), en supprimant les objets obsolètes et en occupant un espace disque raisonnable ;

d. La puissance de calcul et la RAM ne sont pas non plus extensible et pour les mêmes raisons que l'espace disque, vous vous engagez à être éco-responsable dans l'usage de vos CI/CD . 10. Disponibilité de la plate-forme :

a. La plate-forme peut être mise en maintenance à n'importe quel moment pour appliquer les patchs de sécurité en cas d’alertes de sécurité critiques, ou à tout autre moment planifié (les sauvegardes programmées autour de 23h chaque nuit entraînant l'indisponibilité de la plate-forme sur au minimum 30 mn, au maximum 2h). À compter de la date d'application, pour les opérations de maintenance planifiée (les mises à jour de GitLab CE et les modifications d’infrastructure portant GitLab) après décision en CAB (26/02/2024), l'équipe produit GitLab-forge en informe les utilisateurs au moins une semaine avant cette opération de maintenance. Cette annonce est effectuée : - via un ticket d'indisponibilité programmée sur le PSIN ; - via un bandeau d'annonce publié sur la plate-forme ; - via le canal dédié #gitlab-forge.

b. L'utilisateur prend en compte cet état de fait dans la planification de ses propres opérations qui nécessiterait la disponibilité de la forge (opérations telles que des mises en production, ...) ;

c. Dans le cas où l'utilisateur souhaite planifier une opération en amont de la semaine de prévenance énoncée au a) ; opération nécessitant la disponibilité de la plate-forme : l'utilisateur s'engage à informer l'équipe produit GitLab-forge de ce souhait (ce afin d'éviter les opérations de maintenance planifiées sur les créneaux convenus entre l'équipe produit et l'utilisateur par ticket SPS sur le projet DAM en indiquant une priorité Haute, une catégorie à Projet GitLab et en cochant Demande urgente et sur le canal dédié #gitlab-forge.


Cette charte peut être régulièrement mise à jour et adaptée en fonction de l'évolution des technologies, des menaces et des politiques de sécurité de l'organisation. Elle doit être approuvée par tous les développeurs nouvellement intégrés et mise à disposition pour consultation à chacune des mises-à-jour.