Fait partie du Sovereign Stack · Famille: Souverain
Sovereign Code
Hébergez votre code source dans un environnement GitLab géré en Europe ou sur vos propres serveurs. Contrôlez les accès et recherchez les mots de passe et clés d’accès exposés.
Où votre code est hébergé
- Conserver les fichiers et leur historique dans des dépôts contrôlés par l’entreprise.
- Définir qui peut lire, modifier, relire et publier le code.
- Préciser l’hébergement, les sauvegardes et les contrôles des mots de passe et clés d’accès.
Comment cela fonctionne
- Créer les comptes professionnels et transférer les projets convenus avec leur historique.
- Relire les changements et les vérifier avant leur intégration dans la version principale.
- Tenir l’inventaire, retirer les accès inutiles et tester la récupération des projets.
Faites défiler horizontalement pour lire le dessin.
Le code de votre équipe, sous contrôle de l’entreprise.
- Votre équipe technique
- Équipes et partenaires
- Comptes des projets de l’entreprise
- Des accès pour les bonnes personnes
- Sovereign Code
- GitLab sous votre contrôle
- Branches principales protégées
- Vérifier les clés exposées
- Un projet récupérable
- Conserver l’historique du projet
- Réviser et retirer les accès
- Sauvegarder et tester la reprise
Hébergement européen ou dans vos locaux ; accès administrateur documentés.
- Dépôt
- Fichiers d’un projet et historique des changements.
- Secret
- Mot de passe, jeton ou clé permettant à un logiciel d’accéder à un autre service.
- Contrôle avant enregistrement
- Vérifications sur le poste du développeur pour repérer les identifiants exposés.
- Branche protégée
- Version partagée du code avec des règles de relecture et d’acceptation.
- Commit signé
- Changement signé cryptographiquement, dont l’identité doit être vérifiée.
- CLOUD Act
- Clarifying Lawful Overseas Use of Data Act. Loi américaine sur les preuves électroniques ; le pays de stockage ne détermine pas seul les obligations du prestataire.
Qui peut consulter et modifier le code ?
Un dépôt contient les fichiers d’un projet et leur historique. Les comptes professionnels, les règles d’accès et les branches protégées appliquent le processus de relecture convenu.
Des contrôles sur le poste du développeur et dans le processus partagé aident à repérer les mots de passe et clés d’accès. Nous précisons où ils s’exécutent ; une clé exposée doit aussi être révoquée et l’incident examiné.
Transférer vos projets existants
Nous inventorions d’abord les dépôts, personnes et intégrations. Le plan de migration couvre l’historique, les tickets lorsque c’est possible, l’automatisation, les accès et les sauvegardes.
Avant le changement, nous vérifions que l’équipe peut récupérer le code, proposer une modification et exécuter la publication convenue.
Une leçon tirée de notre propre projet
Un étudiant sur l’un de nos projets a copié le dépôt vers son compte GitHub personnel. Il contenait un jeton d’accès SendGrid. Le prestataire nous a ensuite informés de sa découverte dans un dépôt public et de sa révocation.
La leçon pratique : utiliser des comptes professionnels, vérifier les identifiants exposés et inventorier les projets. Révoquer le jeton n’a pas supprimé les copies du code.
Le choix d’hébergement demande aussi d’examiner le prestataire, les accès administrateur et les obligations applicables ; le pays de stockage ne suffit pas.
Détails techniques
Pour les informaticiens : GitLab, auto-hébergé ou hébergé dans l’UE, détection des secrets en pre-commit, branches protégées, commits signés, inventaire des dépôts.
Former votre équipe
- Durée
- Une demi-journée
- Pour qui
- Responsables et équipes de développement
- Au programme
- Utiliser les comptes professionnels, vérifier les identifiants et préparer accès et migration.
Sujets de sécurité liés
Consultez les mesures pratiques et références liées à ce service.