Protéger la source

Ce document décrit les bonnes pratiques de gestion du code source des logiciels.

Une étape fondamentale des équipes logicielles pour gérer leur source consiste à adopter un système de contrôle des versions (VCS). Les systèmes de contrôle des versions offrent un historique des modifications et la possibilité de réaliser des audits. 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 à d'autres parties du pipeline CI/CD.

Ce document explore les considérations relatives à la sécurité sur la chaîne d'approvisionnement logicielle pour la configuration d'un système de contrôle des versions. Il décrit les bonnes pratiques décrites dans le document Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels, un framework conçu pour protéger votre chaîne d'approvisionnement logicielle. Le framework comprend des exigences à plusieurs niveaux pour vous aider à mettre en œuvre des modifications de manière incrémentielle, y compris les exigences concernant les sources.

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

Au niveau SLSA 3, les plates-formes de source et de compilation respectent des exigences de sécurité plus strictes, y compris un historique validé de la source et une règle de conservation de la source. Le SLSA de niveau 4 ajoute des avis de deux personnes aux exigences concernant les sources.

Utilisez le contrôle des versions pour d'autres domaines 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 examens et des audits historiques sont nécessaires. Toutefois, d'autres types de sources bénéficient également du contrôle des versions, tels que la configuration, les règles et les données. Cela inclut les fichiers qui:

  • Impact sur la disponibilité et la sécurité de votre infrastructure de calcul
  • Collaboration requise pour la finalisation
  • Nécessite un processus d'approbation reproductible
  • Exiger un historique des modifications

En voici quelques exemples :

  • Infrastructure as Code: les entreprises qui souhaitent gérer leur infrastructure de manière évolutive et sécurisée utilisent la méthodologie 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 d'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 de vos bases de données produit et de vos bases de données analytiques ou de journalisation.
  • Notebooks Jupyter: les notebooks stockés dans GitHub peuvent être utilisés de différentes manières, y compris avec l'[extension pour JupyterLab][jlab], Colaboratory et [Vertex AI Workbench][vertex].
  • Règles de sécurité: stockez des fichiers de règles pour automatiser l'application 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 stratégies Sentinel qui empêchent Terraform de provisionner une infrastructure non conforme aux règles.

Le contrôle des versions est l'une des capacités techniques identifiées par l'étude DevOps de DORA qui permet d'améliorer les performances organisationnelles et de 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, ainsi qu'à réagir rapidement aux défauts.

Configuration du dépôt

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

Les problèmes pouvant survenir avec la configuration du dépôt sont les suivants:

  • La configuration des dépôts n'est pas standardisée. Il est 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 compte des centaines ou des milliers de dépôts.
  • La personne qui crée le dépôt devient propriétaire et dispose de toutes les autorisations d'administration, y compris la possibilité d'effectuer des fusions avec aucun autre réviseur.
  • L'intégration de dépôts dans l'analyse du code, de serveurs de compilation, d'outils de suivi des problèmes, de services de notification et d'autres parties de l'infrastructure CI/CD peut représenter un travail considérable. Disposer d'une méthode standard pour créer et configurer des dépôts vous permet d'économiser le travail répétitif et de respecter les bonnes pratiques.

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

  • Configurez des dépôts à l'aide d'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 à laquelle le dépôt est destiné. Les applications hautement sécurisées nécessitent davantage d'approbateurs de fusion différents que les applications moins sécurisées.
  • Donnez aux administrateurs de dépôt un moyen de choisir parmi un ensemble de modèles de configuration qui pilotent la configuration d'un 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 implique généralement l'utilisation d'un système de contrôle de l'authentification et des accès (IAM) hiérarchique qui reflète les applications et l'infrastructure de votre organisation, ainsi que les utilisateurs qui en sont responsables.
  • Exiger une gestion centralisée des identités avec 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 changent d'équipe, vous appliquez le principe du moindre privilège à 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 SLSA de niveau 4 pour les approbateurs de code.
  • Limitez les propriétaires de dépôts à un petit nombre d'employés de confiance. Cela peut nécessiter d'intégrer le contrôle des versions à un système de gestion des identités et de déplacer la possibilité de définir des règles à un niveau plus élevé dans l'organisation. Si possible, empêchez les propriétaires de dépôts d'effectuer des fusions sans deuxième examinateur.

Réviser le code

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

  • Introduction de code présentant des défauts logiciels ou une conception rigide
  • API mal définies
  • Introduction de problèmes de sécurité dus à un code non sécurisé écrit par le développeur
  • Introduction de problèmes de sécurité dus à l'ajout de bibliothèques tierces non sécurisées ou susceptibles de le devenir.

Voici quelques moyens d'atténuer les risques:

  • Mettez en œuvre 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.
  • Assurez-vous que le nombre et l'identité des examinateurs sont adaptés 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 métier critique accessible au public.
  • Désignez des examinateurs en fonction de l'expertise technique et du niveau de confiance requis pour la modification du commit. Il doit être un expert du langage étudié, des systèmes avec lesquels le code interagit et des risques de sécurité associés à cette classe d'application. L'exigence d'expertise technique comporte de nombreuses dimensions. Exemple :
    • Le code est-il lisible ?
    • Est-il sécurisé ?
    • Utilise-t-il les bibliothèques tierces appropriées ?
    • Un processus de sécurisation des bibliothèques tierces a-t-il été mis en place ?
    • Le code est-il composable ?
    • La conception de l'API respecte-t-elle les bonnes pratiques ?

  • Les avis ne doivent pas être une étape bureaucratique, mais une conversation continue autour des bonnes pratiques. Créez des checklists, des guides de style et des normes de conception pour chaque partie de votre pile technologique, ainsi que des programmes éducatifs pour les nouveaux développeurs. Certains IDE, tels que VS Code et IntelliJ, fournissent des lint qui peuvent signaler automatiquement les erreurs programmatiques ou stylistiques. 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 difficiles à identifier avec des vérifications automatisées.

    Developing Secure Software (Développer des logiciels sécurisés) est un cours en ligne gratuit créé par l'Open Source Security Foundation (OpenSSF). Il décrit les pratiques fondamentales de développement de logiciels dans le contexte de la sécurité sur la chaîne d'approvisionnement logicielle.

  • Effectuez des revues de code avec des demandes d'extraction de branche de fonctionnalité dès qu'un développeur individuel est prêt. N'attendez pas qu'une nouvelle version soit testée pour procéder à des contrôles de sécurité et à l'examen 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 le plus rapidement possible. L'API On-Demand Scanning de Google Cloud vous permet de rechercher des failles en local dans les conteneurs.

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

Approbations de fusion

Dans les pipelines CI/CD intégrés en continu, 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. C'est pourquoi la sécurisation des utilisateurs autorisés à fusionner est un élément essentiel de la sécurisation des déploiements logiciels. Voici quelques points à prendre en compte :

  • Configurez des propriétaires de branches protégées dans vos branches de production. Le nombre et l'identité des entités autorisées à fusionner doivent être adaptés aux exigences de sécurité de l'application. Le niveau SLSA 4 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ôts, car dans la plupart des systèmes de contrôle des versions, ils peuvent effectuer des fusions par eux-mêmes.
  • Séparer les processus de déploiement et de fusion pour les déploiements multidépôts et multi-artefacts.

Outils pour sécuriser le développement

Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle de bout en bout entièrement gérée. Elle fournit un ensemble complet et modulaire de fonctionnalités et d'outils sur les services Google Cloud que les développeurs, les équipes DevOps et les équipes de sécurité peuvent utiliser pour améliorer la stratégie de sécurité de la chaîne d'approvisionnement logicielle. Les composants suivants de Software Delivery Shield contribuent à protéger le code source du logiciel:

  • Cloud Workstations (preview)

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

    Cloud Workstations aide à déplacer la sécurité vers l'amont en renforçant 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, l'entrée ou la sortie privées, la mise à jour forcée des images, et les règles d'accès Identity and Access Management. Pour en savoir plus, consultez la documentation de Cloud Workstations.

  • Cloud Code Source Protect (preview)

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

    Disponibilité des fonctionnalités: la source protect de Cloud Code n'est pas accessible au public. Pour accéder à cette fonctionnalité, consultez la page de demande d'accès.

Étapes suivantes