Qui a accès au code source, à la chaîne de construction et à l'environnement de production ?
Le contrôle d'accès dans le développement de logiciels concerne la question de savoir qui peut effectuer quelle action sur quelle partie de votre chaîne de développement : qui peut lire le code, qui peut modifier et fusionner le code, qui peut lancer une compilation et qui peut déployer une version en production. C'est une question plus spécifique que le contrôle d'accès pour une organisation en général, car une équipe de développement travaille généralement avec plusieurs systèmes simultanément : un dépôt de code source, un environnement de compilation et de test, et généralement un environnement de production distinct où le logiciel fonctionne réellement.
La raison pour laquelle ce sujet revient particulièrement dans les questionnaires de sécurité et dans les mesures de diligence requise de la Directive (EU) 2022/2555, c'est qu'une faille dans l'accès à votre chaîne de développement a des répercussions directes sur quiconque utilise votre logiciel. Celui qui peut modifier le code sans détection et qui le fait ensuite déployer affecte non seulement votre propre organisation mais aussi vos clients. C'est pourquoi un autorité de contrôle tout comme un acheteur qui relève lui-même de la diligence requise demande comment vous avez organisé cela.
Pourquoi cela concerne spécifiquement le code source et la chaîne de construction
Une équipe de développement a généralement plus de personnes avec des droits plus larges que strictement nécessaire, simplement parce que c'est pratique : chacun peut accéder à tout, personne n'a à attendre. Du point de vue de la diligence requise, c'est précisément le point sur lequel on approfondit. Non pas parce que la confiance serait mauvaise, mais parce que la vérifiabilité est différente de la confiance : une autorité de contrôle ou un acheteur veut savoir si vous pouvez prouver qui a accès, non pas seulement si vous leur faites confiance.
Les questions qui reviennent généralement concernent trois niveaux. Le premier est le dépôt de code source lui-même : qui peut lire, qui peut modifier, et y a-t-il une vérification obligatoire avant qu'une modification soit fusionnée avec la version principale. Le deuxième est l'environnement de compilation et de test : qui peut lancer une compilation, et cet environnement a-t-il accès à des données ou des systèmes qui ne sont pas destinés à des fins de test. Le troisième est l'environnement de production : qui peut réellement déployer une version, et s'agit-il d'un groupe de personnes différent de celui qui écrit le code.
Séparation entre l'écriture et le déploiement
Une distinction récurrente dans les questionnaires est de savoir si la personne qui écrit le code est aussi celle qui déploie la version en production. Là où c'est la même personne, sans étape intermédiaire d'une autre personne, une situation se crée où une erreur ou une modification malveillante passe inaperçue en production. De nombreuses organisations résolvent ce problème en imposant un examen obligatoire par une autre personne avant que le code soit fusionné, et en mettant en place un rôle distinct ou des droits distincts pour le déploiement réel. Comment cela se manifeste en pratique varie considérablement selon l'équipe et la taille ; la directive elle-même n'impose pas une méthode spécifique, mais les autorités de contrôle et les acheteurs regardent bien la question sous-jacente : une seule personne peut-elle mettre en œuvre des modifications non contrôlées qui affectent les clients.
Secrets et clés séparés du code
Un deuxième point sur lequel les questionnaires demandent régulièrement des précisions concerne le lieu où les mots de passe, les clés API et autres secrets sont stockés. Les secrets qui figurent dans le code source lui-même sont visibles pour quiconque ayant accès en lecture à ce code, ce qui peut être un groupe beaucoup plus large que celui qui devrait réellement travailler avec cette clé. Un coffre-fort séparé pour les secrets, avec ses propres droits d'accès indépendants du dépôt de code, est un moyen courant de les séparer. Le fait que et comment vous organisez cela est un choix technique ; ce qui est pertinent pour le dossier est principalement de pouvoir expliquer pourquoi l'approche choisie est appropriée à la taille et aux risques de ce que vous développez.
Ce que vous documentez, non seulement ce que vous configurez
La mise en place technique des droits d'accès est une chose; pouvoir la démontrer en est une autre, et ce dernier point est en pratique souvent oublié. Une liste indiquant qui a accès à quel système, quand cet accès a été accordé et sur quelle base constitue précisément le document justificatif que demandent un questionnaire ou une autorité de contrôle. Sans cette liste, vous devez rechercher la réponse à chaque question; avec un registre vivant à côté de chaque mesure, la réponse est déjà prête. consulter l'explication pour chaque mesure donne une vue d'ensemble de la manière dont la gestion des accès se rapporte aux neuf autres mesures de l'obligation de diligence.
Qu'il s'agisse de déterminer si votre organisation est elle-même soumise à l'obligation de diligence, ou si vous recevez cette question parce qu'un client l'est, peut être déterminé en quelques questions. Pour ceux qui se demandent à quel point les exigences en matière de gestion des accès sont strictes lorsqu'un client demande de démontrer ce qui a été mis en place, l'explication sur la protection et la sécurité des données donne une vue d'ensemble plus large d'où proviennent ce type d'exigences.
Pour votre situation spécifique, par exemple savoir si une configuration particulière de votre pipeline de développement est conforme à l'obligation de diligence qui pèse sur vous ou sur votre client, un juriste ou l'autorité de contrôle compétente est le lieu approprié; secria.eu prépare la documentation mais ne se prononce pas sur la conformité individuelle.
Souhaitez-vous voir comment la gestion des accès s'inscrit dans le reste de votre dossier, ou avez-vous d'autres questions sur ce que signifie exactement cette mesure? consulter les questions fréquemment posées fournit déjà une réponse brève sur bon nombre de ces points, et le scan rapide gratuit montre en quelques minutes où en est votre organisation sur ce sujet.