GitHub vs GitLab et durcissement de GitLab en interne

GitHub et GitLab hébergent tous deux du code Git, mais ils ne reposent pas sur la même philosophie, ni sur le même modèle d'hébergement. Pour une entreprise qui choisit d'installer sa propre instance, la question centrale devient : comment la protéger ? Cet article compare les deux plateformes, puis détaille le durcissement de GitLab en interne : filtrage réseau, système, chiffrement, paramètres applicatifs et pipelines.

À retenir : une instance GitLab interne concentre le code source, les jetons d'accès, les clés de déploiement et les pipelines. Sa compromission ouvre la porte à toute l'infrastructure. Elle doit être traitée comme un système critique, pas comme un simple outil de développeurs.

GitHub et GitLab : les principales différences

D'après une comparaison de Spacelift, les deux plateformes n'ont ni la même origine ni le même modèle.

Selon la documentation de GitHub, GitHub Enterprise Server est une version auto-hébergée de la plateforme, déployée sous forme d'appliance virtuelle sur un hyperviseur (Hyper-V, KVM, VMware ESXi) ou chez un fournisseur cloud, dont l'administrateur gère les mises à jour et les sauvegardes.

En résumé : GitHub convient bien à la collaboration ouverte et à l'écosystème d'extensions ; GitLab séduit par sa plateforme DevSecOps unifiée et son édition auto-hébergée gratuite. Dans les deux cas, dès lors que l'instance est hébergée par vos soins, la sécurité devient votre responsabilité.

Pourquoi le durcissement de GitLab est indispensable en interne

Une faille dans GitLab peut avoir un impact critique. En septembre 2026, GitLab a publié un correctif pour la CVE-2026-85706, une lecture de fichiers sans authentification notée 10 sur 10 en CVSS. Elle rappelle que la surface d'attaque d'un GitLab exposé est bien réelle, et que le durcissement doit s'ajouter aux mises à jour, pas les remplacer.

Selon la documentation de GitLab, ses recommandations de durcissement visent les instances auto-hébergées et GitLab Dedicated, et se répartissent en cinq catégories : les concepts généraux, les paramètres applicatifs, les paramètres CI/CD, les paramètres de configuration et les paramètres du système d'exploitation. GitLab précise qu'il ne s'agit pas d'éliminer les attaques, mais d'en réduire fortement le risque, et qu'un déploiement progressif et une information des utilisateurs sont nécessaires, car certaines mesures limitent des fonctions.

1. Le filtrage réseau et le système d'exploitation

C'est la première ligne de défense. D'après les recommandations système de GitLab :

• N'ouvrir que les ports TCP 80 et 443, avec une redirection du 80 vers le 443, et fermer le port 5050 (registre de conteneurs) dans un environnement durci.
• Filtrer avec iptables, ufw ou un pare-feu cloud (groupes de sécurité), en restreignant tous les ports sauf pour les réseaux qui doivent accéder à l'instance.
• Appliquer les règles avant l'installation, avec un accès limité aux administrateurs et installateurs, puis n'ajouter les plages d'adresses des utilisateurs qu'après le durcissement.
• Sécuriser le serveur SSH (sshd_config) : authentification par mot de passe désactivée ou clés publiques uniquement, PermitRootLogin no, désactivation de AllowTcpForwarding et X11Forwarding, LoginGraceTime 60, algorithmes de chiffrement robustes et UseDNS no.
• Maîtriser les connexions sortantes : autoriser uniquement celles nécessaires, comme cloud.gitlab.com et customers.gitlab.com sur le port 443, et configurer un proxy web pour les nœuds Rails et Sidekiq.
• Renforcer le noyau : GitLab recommande par exemple kernel.randomize_va_space=2 (ASLR), kernel.kptr_restrict=2, kernel.dmesg_restrict=1, la désactivation des espaces de noms non privilégiés et de l'eBPF non privilégié, ainsi que les cookies SYN TCP.

En plus de ces règles, limitez l'accès à l'instance aux réseaux internes ou à un VPN, plutôt que de l'exposer directement sur Internet. Pour calculer les plages autorisées, l'outil Calculateur de sous-réseau de ForenShield est utile, et la référence des ports et protocoles permet de vérifier ce que chaque port transporte.

Attention si GitLab tourne dans Docker : selon l'OWASP, Docker peut contourner des règles de pare-feu comme UFW lorsqu'un port est publié sur l'hôte. Vérifiez l'exposition réelle des ports depuis l'extérieur.

Un exemple de règles de pare-feu

Voici un exemple avec UFW, à adapter à vos plages d'adresses (les valeurs sont des exemples) :

ufw default deny incoming
ufw default allow outgoing
ufw allow from 10.10.0.0/16 to any port 443 proto tcp
ufw allow from 10.10.0.0/16 to any port 80 proto tcp
ufw allow from 10.20.0.0/24 to any port 22 proto tcp   # administrateurs uniquement
ufw enable

2. Le chiffrement TLS

Les recommandations de configuration de GitLab portent notamment sur NGINX dans gitlab.rb :

• n'autoriser que TLS 1.2 et TLS 1.3 (nginx['ssl_protocols']) ;
• utiliser uniquement des suites de chiffrement robustes (AES-GCM) et préférer l'ordre du serveur ;
• désactiver la réutilisation des tickets de session (nginx['ssl_session_tickets'] = "off") ;
• définir la courbe (secp384r1), un fichier de paramètres Diffie-Hellman et un cache de session limité ;
• choisir un mot de passe root solide dès l'installation via GITLAB_ROOT_PASSWORD ;
• restreindre l'accès au registre de conteneurs à l'hôte local sur un système autonome.

3. Les paramètres applicatifs

Selon les recommandations applicatives de GitLab :

Comptes et authentification

• désactiver la création de comptes par les utilisateurs, exiger la confirmation de l'adresse e-mail et limiter les domaines autorisés ;
• imposer un mot de passe d'au moins 12 caractères avec une complexité minimale ;
• activer l'authentification à deux facteurs pour tous les utilisateurs, et réduire le délai de grâce de 48 heures par défaut à environ 8 heures ;
• activer le mode administrateur (Admin Mode), qui exige une authentification supplémentaire pour les tâches d'administration ;
• activer les notifications de connexion depuis des lieux inhabituels.

Visibilité et dépôts

• définir la visibilité par défaut des projets, extraits et groupes sur Privé ;
• activer les règles de poussée (« push rules ») : rejeter les utilisateurs non vérifiés, empêcher la suppression de tags, vérifier les auteurs des commits et bloquer les fichiers secrets ;
• éviter les clés de déploiement publiques et préférer des clés propres à chaque projet ;
• désactiver Gravatar pour limiter les communications externes.

Réseau et limitation de débit

• activer les limites de débit avec leurs valeurs par défaut ;
• activer la protection contre les attaques par « DNS rebinding » ;
• limiter les requêtes sortantes à des adresses ou noms d'hôtes de confiance, et n'utiliser les crochets système (« system hooks ») qu'avec des systèmes de confiance, en TLS.

Clés SSH

• privilégier ED25519, puis RSA (2048 bits minimum), puis ECDSA, et interdire DSA.

4. Les pipelines CI/CD et les runners

La page de GitLab sur le CI/CD reste générale : protéger les secrets, chiffrer les communications réseau, journaliser finement, et restreindre l'accès aux environnements avec les environnements protégés. Elle renvoie vers la documentation de sécurité des pipelines pour les détails.

En complément, quelques réflexes courants dans les équipes DevSecOps : isoler les runners des serveurs GitLab, éviter les exécutants en mode privilégié, limiter les variables sensibles aux branches protégées et rotationner régulièrement les jetons. Vérifiez chaque point dans la documentation officielle avant de l'appliquer.

5. Mises à jour, surveillance et sauvegardes

• Corriger vite. Activer la vérification de version aide à savoir quand un correctif de sécurité est disponible. Pour évaluer l'urgence d'une faille, consultez notre guide sur le score CVSS.
• Faire tourner les secrets des intégrations tierces, comme le recommande GitLab.
• Journaliser et surveiller les accès et les actions d'administration, et envoyer les journaux vers un système central.
• Tester les sauvegardes et les conserver hors de l'instance : une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Checklist rapide

1. Accès réseau limité (VPN ou réseaux internes), ports 80 et 443 seulement, pare-feu actif avant l'installation.
2. Serveur SSH durci, TLS 1.2 et 1.3 uniquement.
3. Inscription libre désactivée, 2FA obligatoire, Admin Mode activé.
4. Visibilité par défaut privée, règles de poussée activées.
5. Limites de débit activées, requêtes sortantes restreintes.
6. Runners isolés, secrets protégés, environnements protégés.
7. Correctifs appliqués rapidement, journaux centralisés, sauvegardes testées.

Sources

• GitLab : recommandations de durcissement du système d'exploitation
• GitLab : recommandations de configuration
• GitLab : recommandations applicatives
• GitLab : recommandations CI/CD
• GitLab : version corrective 19.3.2, 19.2.6, 19.1.8
• GitHub : à propos de GitHub Enterprise Server
• Spacelift : GitLab vs GitHub
• OWASP : Docker Security Cheat Sheet