Protéger la source

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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

L'une des étapes fondamentales 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 fournissent un historique et des possibilités de vérification 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é, des outils intégrés d'examen de code et l'intégration à d'autres services cloud.

Bien que la plupart des équipes utilisent actuellement 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 de sécurité de la chaîne d'approvisionnement logicielle pour configurer un système de contrôle des versions. Il décrit les bonnes pratiques du niveau d'approvisionnement des artefacts logiciels, un framework qui protège votre chaîne d'approvisionnement logicielle. Le framework comprend des exigences à plusieurs niveaux pour vous aider à implémenter les modifications de manière incrémentielle, y compris des 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 de niveau 2 pour 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 du SLSA, les plates-formes sources et de compilation respectent des exigences de sécurité plus strictes, y compris un historique des sources validé et des règles de conservation des sources. Le niveau 4 de SLSA permet d'ajouter des avis de deux personnes aux exigences des sources.

Utiliser le contrôle des versions au-delà de 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 historiques et des audits sont nécessaires. Cependant, d'autres types de sources bénéficient également du contrôle des versions, comme la configuration, les règles et les données. y compris ceux qui:

  • Impact sur la disponibilité et la sécurité de votre infrastructure de calcul
  • Exiger la collaboration pour finaliser
  • Exiger un processus d'approbation reproductible
  • Exiger 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 de clé. Par exemple, vous pouvez stocker les modules Terraform dans le contrôle des versions qui créent des dépôts Artifact Registry.
  • Gestion de la configuration : elle 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 pour vos bases de données de produits et vos bases de données d'analyse ou de journalisation.
  • Notebooks Jupyter : les notebooks sont stockés de différentes manières, notamment dans l'[extension pour JupyterLab][jlab], Colaboratory et [Vertex AI Workbench][vertex].
  • Règles de sécurité : stockez les fichiers de règles pour l'application automatique 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 ne respecte pas les règles.

Le contrôle des versions est l'une des fonctionnalités techniques identifiées par l'étude DevOps de DORA visant à améliorer la livraison de logiciels et les performances organisationnelles. 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éagir rapidement aux défaillances.

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 liés à la configuration du dépôt peuvent être les suivants:

  • La configuration du dépôt 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'elle représente, en particulier dans le cas où une organisation possède des centaines ou des milliers de dépôts.
  • Quiconque crée le dépôt devient un propriétaire disposant des autorisations d'administration complètes, y compris la capacité d'effectuer des fusions sans aucun autre réviseur.
  • L'intégration de dépôts à l'analyse de code, à des serveurs de compilation, à des outils de suivi des problèmes, à des services de notification et à d'autres parties de l'infrastructure CI/CD peut représenter un travail considérable. Avoir une méthode standard de création et de configuration de dépôts permet d'éviter les tâches répétitives et les bonnes pratiques.

Pour résoudre ces problèmes, voici quelques bonnes pratiques :

  • Configurez des dépôts avec un processus automatisé, reproductible et respectueux de 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 à haute sécurité nécessitent davantage d'approbateurs de fusion et des applications différentes que les applications à sécurité plus faible.
  • Offrez aux administrateurs de dépôts la possibilité de choisir parmi un ensemble de modèles de configuration de dépôt qui permettent de configurer de nouveaux dépôts 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 d'utiliser un système de contrôle des identités 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.
  • 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 migrent vers de nouvelles équipes, vous conservez le moindre privilège concernant la gestion des sources.
    • L'authentification multifacteur réduit considérablement le risque d'hameçonnage et d'autres types d'attaques contre votre source. L'authentification à deux facteurs est l'une des exigences du niveau 4 de la loi SLSA pour les approbateurs du code.
  • Limitez le nombre de propriétaires de dépôts à un petit nombre d'employés de confiance. Pour ce faire, vous devrez peut-être intégrer le contrôle des versions à un système de gestion des identités et désactiver la possibilité de définir des règles plus élevées dans l'organisation. Si possible, supprimez la possibilité pour les propriétaires de dépôts d'effectuer des fusions sans un second réviseur.

Réviser le code

La révision du code est le principal moyen utilisé par les organisations pour veiller à la qualité et à la sécurité de leurs logiciels. La révision du code tente de résoudre différents modes de défaillance, par exemple:

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

Voici quelques moyens de limiter les risques:

  • Implémentez les tests continus 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 à celle d'une application critique publique.
  • Attribuez des évaluateurs en fonction de votre expertise technique et du niveau de confiance requis pour la modification du commit. L'examinateur doit être un expert du langage examiné, des systèmes avec lesquels le code interagit et des risques de sécurité de cette classe d'application. Le niveau d'expertise technique nécessite 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 est-il mis en place ?
    • Le code est-il composable ?
    • La conception de l'API respecte-t-elle les bonnes pratiques ?
  • Les examens ne doivent pas être une démarche bureaucratique, mais un dialogue continu concernant les 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 lints qui peuvent signaler automatiquement des erreurs programmatiques ou stylistiques. Linters permet aux développeurs de créer un code plus cohérent et de permettre aux réviseurs de code de se concentrer sur les problèmes difficiles à identifier grâce aux vérifications automatisées.

    Developing Secure Software 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é de la chaîne d'approvisionnement logicielle.

  • Examiner le code avec les demandes d'extraction de branche de fonctionnalité dès qu'un développeur individuel est prêt N'attendez pas juste qu'une nouvelle version soit testée pour effectuer des contrôles de sécurité et examiner le code.

  • Intégrer l'analyse des failles, y compris l'analyse des bibliothèques tierces, aux demandes d'extraction et aux IDE permet d'identifier les problèmes le plus rapidement possible. L'API On-Demand Scanning dans Google Cloud vous permet d'analyser les failles des conteneurs en local.

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

Fusionner les approbations

Dans les pipelines CI/CD intégrés en continu, la fusion du code dans une branche de production peut entraîner des modifications en aval, y compris la compilation et le déploiement automatisés. Pour cette raison, la sécurisation des personnes autorisées à fusionner est un élément essentiel de la sécurisation des déploiements de logiciels. Voici quelques points à prendre en compte :

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

Outils de développement sécurisé

Software Delivery Shield est une solution de sécurité de la chaîne d'approvisionnement logicielle entièrement gérée de bout en bout. Il fournit un ensemble complet de fonctionnalités et d'outils modulaires dans les services Google Cloud. Les développeurs, le DevOps et les équipes de sécurité peuvent les utiliser pour améliorer la sécurité de la chaîne d'approvisionnement logicielle. Les composants suivants de Software Delivery Shield protègent le code source des logiciels:

  • Cloud Workstations (bêta)

    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. Les développeurs peuvent ainsi accéder aux environnements de développement à l'aide de configurations cohérentes et d'outils personnalisables.

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

  • Cloud Source Code Protect (bêta)

    Cloud Code fournit la compatibilité IDE pour la création, le déploiement et l'intégration d'applications avec 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 finale. La protection des sources Cloud Code fournit aux développeurs des commentaires en temps réel sur la sécurité, tels que l'identification des dépendances vulnérables et la création de rapports de licence, lorsqu'ils fonctionnent dans leurs IDE. Il 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 protection des sources Cloud Code n'est pas disponible pour l'accès public. Pour accéder à cette fonctionnalité, consultez la page de demande d'accès.

Étapes suivantes