Protéger la source

Ce document décrit les bonnes pratiques pour gérer le code source des logiciels.

Une étape fondamentale que les équipes logicielles doivent suivre pour gérer leur source consiste à adopter un système de contrôle des versions. Les systèmes de contrôle des versions fournissent un historique et une vérifiabilité des modifications. Les systèmes de contrôle des versions hébergés, tels que GitHub, offrent des avantages supplémentaires, tels que la disponibilité, la stabilité, les contrôles de sécurité, les outils intégrés de revue de code et l'intégration à d'autres services cloud.

Bien que la plupart des équipes utilisent aujourd'hui le contrôle des versions, il existe de nombreuses façons de configurer un système de contrôle des versions et ses intégrations avec d'autres parties du pipeline CI/CD.

Ce document explore les considérations de sécurité de la chaîne d'approvisionnement logicielle pour la configuration d'un système de contrôle des versions. Il décrit les bonnes pratiques de Supply-chain Levels for Software Artifacts, un framework permettant de protéger votre chaîne d'approvisionnement logicielle. Le framework inclut des exigences à plusieurs niveaux pour vous aider à implémenter les modifications de manière progressive, y compris les exigences de la source.

Un système de contrôle des versions avec un historique des modifications et des révisions immuables est une exigence du niveau 2 de SLSA. Nous vous recommandons de vous aligner sur le niveau 2 de SLSA comme niveau de référence de départ pour votre chaîne d'approvisionnement logicielle.

Au niveau 3 de SLSA, les plates-formes source et de compilation respectent des exigences de sécurité plus strictes, y compris l'historique de la source vérifié et la règle de conservation de la source. Le niveau 4 de SLSA ajoute des révisions par deux personnes aux exigences de la source.

Utiliser le contrôle des versions pour plus que la source de votre application

Le stockage de la source de l'application dans le contrôle des versions est une pratique bien établie lorsque des révisions et des audits historiques sont nécessaires. Toutefois, d'autres types de sources bénéficient également du contrôle des versions, y compris la configuration, les règles et les données. Cela inclut tous les fichiers qui :

  • ont un impact sur la disponibilité et la sécurité de votre infrastructure de calcul ;
  • nécessitent une collaboration pour être finalisés ;
  • nécessitent un processus d'approbation reproductible ;
  • nécessitent un historique des modifications.

En voici quelques exemples :

  • Infrastructure as code : les organisations qui souhaitent gérer leur infrastructure de manière évolutive et sécurisée utilisent l'infrastructure as code comme méthodologie clé. Par exemple, vous pouvez stocker des modules Terraform dans le contrôle des versions qui créent des dépôts Artifact Registry.
  • Gestion de la configuration : la gestion de la configuration est semblable à l' infrastructure as code, mais se concentre sur la gestion de la configuration des applications avec des outils tels qu'Ansible, Puppet et Chef. Vous stockez et gérez les fichiers de configuration de l'application dans votre système de contrôle des versions.
  • Configurations de base de données et scripts de migration : stockez la configuration et les scripts pour les bases de données de votre produit, ainsi que pour les bases de données d'analyse ou de journalisation.
  • Notebooks Jupyter : il existe différentes façons d'utiliser les notebooks stockés dans GitHub, y compris l'extension pour JupyterLab, Colaboratory et Vertex AI Workbench.
  • Règles de sécurité : stockez les fichiers de règles pour l'application automatisée des règles. Par exemple, vous pouvez stocker des règles Gatekeeper qui autorisent ou refusent le comportement de déploiement dans GKE ou des règles Sentinel qui empêchent Terraform de provisionner une infrastructure qui enfreint les règles.

Le contrôle des versions est l'une des capacités techniques identifiées par la recherche DORA DevOps qui améliore les performances organisationnelles et celles de la livraison de logiciels. Le stockage de vos scripts, de votre code source et de vos fichiers de configuration dans le contrôle des versions vous aide à reproduire et à récupérer des environnements, à suivre et à auditer les modifications, et à répondre rapidement aux défauts.

Configuration du dépôt

Les dépôts sont l'unité logique fondamentale pour organiser le code et les rôles, autorisations, intégrations et approbations associés.

Les problèmes qui peuvent survenir avec la configuration du dépôt incluent les suivants :

  • La configuration du dépôt n'est pas standardisée. Il devient donc difficile de s'assurer que la sécurité du dépôt est adaptée à l'application qu'il représente, en particulier dans le scénario courant où une organisation possède des centaines ou des milliers de dépôts.
  • La personne qui crée le dépôt devient propriétaire avec des autorisations d'administration complètes, y compris la possibilité d'effectuer des fusions sans autre réviseur.
  • L'intégration de dépôts avec l'analyse du code, les serveurs de compilation, les outils de suivi des problèmes, les services de notification et d'autres parties de l'infrastructure CI/CD peut être un travail considérable. Une méthode standard pour créer et configurer des dépôts permet d'éviter les tâches répétitives et de respecter les bonnes pratiques.

Pour résoudre ces problèmes, les bonnes pratiques incluent les suivantes :

  • Configurez les dépôts avec un processus automatisé, reproductible et axé sur la sécurité. Par exemple, vous pouvez configurer des modules Terraform qui intègrent les exigences de sécurité de l'application pour laquelle le dépôt est destiné. Les applications à haute sécurité nécessitent plus d'approbateurs de fusion différents que les applications à faible sécurité.
  • Permettez aux administrateurs de dépôt de choisir parmi un ensemble de modèles de configuration de dépôt qui pilotent la configuration du nouveau dépôt plutôt que de configurer chaque dépôt à partir de zéro. Ces modèles doivent refléter les différents niveaux de sécurité de vos applications et être synchronisés avec les identités utilisateur requises pour chaque niveau de sécurité. En pratique, cela signifie généralement utiliser un système hiérarchique de gestion des identités et des accès (IAM) qui reflète les applications et l'infrastructure de votre organisation, ainsi que les utilisateurs qui en sont responsables.
  • Exigez une gestion centralisée des identités avec l'authentification multifacteur pour les utilisateurs du dépôt.
    • La gestion centralisée des identités garantit que lorsque les utilisateurs quittent l'organisation ou rejoignent de nouvelles équipes, vous conservez le principe du moindre privilège pour la gestion des sources.
    • L'authentification multifacteur réduit considérablement le risque d'hameçonnage et d'autres types d'attaques sur votre source. L'authentification à deux facteurs est l'une des exigences du niveau 4 de SLSA pour les approbateurs de code.
  • Limitez le nombre de propriétaires de dépôt à un petit nombre d'employés de confiance. Cela peut nécessiter l'intégration du contrôle des versions à un système de gestion des identités et le déplacement de la possibilité de définir des règles plus haut dans l'organisation. Si possible, supprimez la possibilité pour les propriétaires de dépôt d'effectuer des fusions sans deuxième réviseur.

Revue de code

La revue de code est le principal moyen pour les organisations de maintenir la qualité et la sécurité de leurs logiciels. La révision du code tente de résoudre différents modes de défaillance, tels que :

  • l'introduction de code avec des défauts logiciels ou une conception inflexible ;
  • des API mal définies ;
  • l'introduction de problèmes de sécurité en raison d'un code non sécurisé écrit par le développeur ;
  • l'introduction de problèmes de sécurité en raison de l'ajout de bibliothèques tierces non sécurisées ou susceptibles de le devenir.

Voici quelques moyens d'atténuer les risques :

  • Implémentez l'automatisation des tests tout au long du cycle de vie du logiciel. Les tests automatisés qui se déclenchent lorsque vous validez la source dans le système de contrôle des versions permettent aux développeurs d'obtenir rapidement des commentaires sur les problèmes détectés par les tests.
  • Adaptez le nombre et l'identité des réviseurs au niveau de sécurité de l'application. Par exemple, une application intranet peu utilisée aura des exigences de sécurité inférieures à celles d'une application critique pour l'entreprise accessible au public.
  • Attribuez des réviseurs en fonction de leur expertise technique et du niveau de confiance requis pour la modification dans la validation. Le réviseur doit être un expert dans le langage examiné, les systèmes avec lesquels le code interagit et les risques de sécurité dans cette classe d'application. L'exigence d'expertise technique comporte de nombreuses dimensions. Exemple :
    • Le code est-il lisible ?
    • Cette fonctionnalité est-elle sécurisée ?
    • Utilise-t-elle des bibliothèques tierces appropriées ?
    • Existe-t-il un processus de sécurisation des bibliothèques tierces ?
    • Le code est-il composable ?
    • La conception de l'API suit-elle les bonnes pratiques ?

  • Les révisions ne doivent pas être une étape bureaucratique, mais une conversation continue sur les bonnes pratiques. Créez des listes de contrôle, des guides de style et des normes de conception pour chaque partie de votre pile technologique, ainsi que des programmes de formation pour les nouveaux développeurs. Certains IDE, tels que VS Code et IntelliJ, fournissent des linters qui peuvent signaler automatiquement les erreurs de programmation ou de style. Les linters aident les développeurs à créer un code plus cohérent et permettent aux réviseurs de code de se concentrer davantage sur les problèmes qui ne sont pas faciles à identifier avec des vérifications automatisées.

    Developing Secure Software est un cours en ligne sans frais créé par Open Source Security Foundation (OpenSSF). Il décrit les pratiques fondamentales de développement logiciel dans le contexte de la sécurité de la chaîne d'approvisionnement logicielle.

  • Effectuez des révisions de code avec des demandes d'extraction de branche de fonctionnalité dès qu'un développeur individuel est prêt. N'attendez pas juste avant de placer une nouvelle version en test pour effectuer des vérifications de sécurité et une révision du code.

  • L'intégration de l'analyse des failles, y compris l'analyse des bibliothèques tierces, dans les demandes d'extraction et les IDE permet d'identifier les problèmes dès que possible. L'API On-Demand Scanning vous per Google Cloud met d'analyser localement les conteneurs pour détecter les failles.

  • Intégrez des tests automatisés avant la fusion afin que les développeurs puissent identifier et corriger les modifications qui interrompront l'application. En savoir plus sur l'automatisation des tests.

Approbations de fusion

Dans les pipelines CI/CD à intégration continue, la fusion de code dans une branche de production peut entraîner des modifications en aval, y compris une compilation et un déploiement automatisés. Pour cette raison, sécuriser qui peut effectuer la fusion est essentiel pour sécuriser les déploiements de logiciels. Voici quelques points à prendre en compte :

  • Configurez des propriétaires de branche protégée sur vos branches de production. Le nombre et l'identité des personnes autorisées à effectuer la fusion doivent être adaptés aux exigences de sécurité de l'application. Le niveau 4 de SLSA nécessite deux approbateurs fortement authentifiés, mais le nombre d'approbateurs doit être adapté au contenu du dépôt.
  • Contrôlez étroitement les identités des propriétaires de dépôt, car dans la plupart des systèmes de contrôle des versions, ils peuvent effectuer des fusions eux-mêmes.
  • Séparez les processus de déploiement et d'approbation de fusion pour les déploiements multirepôts et multi-artefacts.

Outils pour sécuriser le développement

Google Cloud fournit un ensemble de fonctionnalités et d'outils modulaires que vous pouvez utiliser pour améliorer la stratégie de sécurité de votre chaîne d'approvisionnement logicielle. Les composants suivants permettent de protéger le code source des logiciels :

  • Cloud Workstations (aperçu)

    Cloud Workstations fournit des environnements de développement entièrement gérés sur Google Cloud. Il permet aux administrateurs informatiques et de sécurité de provisionner, faire évoluer, gérer et sécuriser facilement leurs environnements de développement, et permet aux développeurs d'accéder à des environnements de développement avec des configurations cohérentes et des outils personnalisables.

    Cloud Workstations contribue à la sécurité en améliorant la stratégie de sécurité de vos environnements de développement d'applications. Il dispose de fonctionnalités de sécurité telles que VPC Service Controls, une entrée ou une sortie privée, une mise à jour forcée des images et des stratégies d'accès Identity and Access Management. Pour en savoir plus, consultez la documentation Cloud Workstations.

  • Cloud Code source protect (aperçu)

    Cloud Code fournit une compatibilité IDE pour créer, déployer et intégrer des applications à Google Cloud. Il permet aux développeurs de créer et de personnaliser une application à partir d'exemples de modèles et d'exécuter l'application terminée. Cloud Code source protect fournit aux développeurs des commentaires de sécurité en temps réel, tels que l'identification des dépendances vulnérables et la création de rapports sur les licences, lorsqu'ils travaillent dans leurs IDE. Il fournit des commentaires rapides et exploitables qui permettent aux développeurs d'apporter des corrections à leur code au début du processus de développement logiciel.

    Fonctionnalités disponibles : Cloud Code source protect n'est pas disponible pour l'accès public. Pour accéder à cette fonctionnalité, consultez la page de demande d'accès.

Étape suivante