Source de protection

Ce document décrit les bonnes pratiques à suivre pour gérer le code source d'un logiciel.

Les équipes logicielles adoptent un système de contrôle des versions (VCS) pour gérer leur source. Les systèmes de contrôle des versions fournissent un historique et une traçabilité 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 d'examen du code intégrés et l'intégration à d'autres services cloud.

Bien que la plupart des équipes utilisent le contrôle des versions aujourd'hui, il existe de nombreuses façons de configurer un système de contrôle des versions et son intégration à 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 (Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels), un framework permettant de protéger votre chaîne d'approvisionnement logicielle. Le framework inclut des exigences à plusieurs niveaux pour vous aider à implémenter des modifications de manière incrémentielle, y compris des exigences concernant les sources.

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

Au niveau 3 de la certification 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 la certification SLSA ajoute des examens par deux personnes aux exigences concernant les sources.

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

Le stockage du code source de l'application dans un système de 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, y compris la configuration, les règles et les données. Cela inclut les fichiers suivants:

  • avoir un impact sur la disponibilité et la sécurité de votre infrastructure de calcul ;
  • Nécessite une collaboration pour être finalisé
  • Exiger 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 l'infrastructure as code comme méthodologie clé. Par exemple, vous pouvez stocker des modules Terraform dans un contrôle de version qui crée des dépôts Artifact Registry.
  • Gestion de la configuration: la gestion de la configuration est semblable à l'infrastructure en tant que code, mais elle se concentre sur la gestion de la configuration des applications à l'aide d'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 vos bases de données de produits et vos bases de données d'analyse ou de journalisation.
  • Notebooks Jupyter: il existe de nombreuses façons de travailler avec des notebooks stockés dans GitHub, y compris l'extension pour JupyterLab, Colaboratory et Vertex AI Workbench.
  • Stratégies de sécurité: stockez les fichiers de stratégie pour une 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 ne respecte pas les règles.

Le contrôle des versions fait partie des capacités techniques identifiées par la recherche DevOps de DORA qui permettent d'optimiser les performances organisationnelles et de livraison de logiciels. Stocker vos scripts, votre code source et vos fichiers de configuration dans un système de contrôle des versions vous permet de reproduire et de récupérer des environnements, de suivre et d'auditer les modifications, et de répondre rapidement aux défauts.

Configuration du dépôt

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

Voici quelques exemples de problèmes pouvant survenir lors de la configuration d'un dépôt:

  • La configuration des dépôts n'est pas standardisée. Il devient donc difficile de s'assurer que la sécurité des dépôts est adaptée à l'application qu'ils représentent, en particulier dans le cas 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 administratives, y compris la possibilité d'effectuer des fusions sans autre examinateur.
  • 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 éléments 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 permet d'économiser du travail répétitif et de respecter les bonnes pratiques.

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

  • Configurez des 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 à laquelle le dépôt est destiné. Les applications à haute sécurité nécessitent plus d'approbateurs de fusion et différents que les applications à faible sécurité.
  • Créez un moyen pour les administrateurs de dépôts de choisir parmi un ensemble de modèles de configuration de dépôts qui dirigent la configuration 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 signifie généralement utiliser un système IAM (Identity and contrôle des accès) 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 des utilisateurs quittent l'organisation ou passent à de nouvelles équipes, vous conservez le 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 fait partie des exigences de niveau 4 du SLSA pour les approbateurs de code.
  • Limitez le nombre de 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 plus haut dans l'organisation. Si possible, empêchez les propriétaires de dépôts d'effectuer des fusions sans un deuxième examinateur.

Réviser le code

L'examen du code est le principal moyen pour les entreprises de maintenir la qualité et la sécurité de leurs logiciels. L'examen du code tente de résoudre différents modes d'échec, par exemple:

  • Introduction de code présentant des défauts logiciels ou d'une conception inflexible.
  • 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é en raison de l'ajout de bibliothèques tierces non sécurisées ou pouvant 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 effectuez un commit de code 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 examinateurs au niveau de sécurité de l'application. Par exemple, une application intranet peu utilisée aura des exigences de sécurité moins élevées qu'une application publique essentielle à l'activité.
  • Attribuez des examinateurs en fonction de leur expertise technique et du niveau de confiance requis pour le changement dans le commit. L'examinateur doit être un expert de la langue examinée, des systèmes avec lesquels le code interagit et des risques de sécurité de 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 des bibliothèques tierces appropriées ?
    • Un processus de sécurisation des bibliothèques tierces est-il en place ?
    • Le code est-il composable ?
    • La conception de l'API respecte-t-elle les bonnes pratiques ?

  • Les évaluations ne doivent pas être une étape bureaucratique, mais un dialogue continu sur 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 de formation pour les nouveaux développeurs. Certains IDE tels que VS Code et IntelliJ fournissent des outils de linting qui peuvent signaler automatiquement les erreurs de programmation ou de style. Les outils lint permettent aux développeurs de créer un code plus cohérent et aux examinateurs 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 la Open Source Security Foundation (OpenSSF). Il décrit les pratiques de base de développement logiciel dans le contexte de la sécurité de la chaîne d'approvisionnement logicielle.

  • Effectuez des examens du code avec des requêtes pull de branche de fonctionnalité dès qu'un développeur est prêt. N'attendez pas la veille d'un test d'une nouvelle version pour effectuer des vérifications de sécurité et un examen du code.

  • L'intégration de l'analyse des failles, y compris de celles des bibliothèques tierces, dans les requêtes pull et les IDE permet d'identifier les problèmes dès que possible. L'API On-Demand Scanning de Google Cloud vous permet de rechercher des failles dans les conteneurs en local.

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

Fusionner les approbations

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 la compilation et le déploiement automatisés. C'est pourquoi la sécurisation des utilisateurs autorisés à effectuer des fusions est un élément essentiel de la sécurisation des déploiements logiciels. Points à prendre en compte :

  • Configurez des propriétaires de branches protégées sur vos branches de production. Le nombre et l'identité des personnes autorisées à fusionner doivent être adaptés aux exigences de sécurité de l'application. Le niveau 4 de SLSA nécessite deux approbateurs authentifiés de manière forte, 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 eux-mêmes.
  • Séparez les processus d'approbation du déploiement et de la fusion pour les déploiements multirépertoires 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 aident à protéger 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, d'évoluer, de gérer et de sécuriser facilement leurs environnements de développement, et aux développeurs d'accéder à des environnements de développement avec des configurations cohérentes et des outils personnalisables.

    Cloud Workstations vous aide à déplacer la sécurité en amont en améliorant la posture de sécurité de vos environnements de développement d'applications. Il dispose de fonctionnalités de sécurité telles que VPC Service Controls, des entrées et des sorties privées, des mises à jour d'images forcées et des stratégies d'accès IAM. Pour en savoir plus, consultez la documentation Cloud Workstations.

  • Protection du code source protect Code (bêta)

    Cloud Code fournit la compatibilité IDE pour créer, déployer et intégrer des applications avec Google Cloud. Il 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. Source protect Cloud Code fournit aux développeurs des commentaires de sécurité en temps réel, tels que l'identification des dépendances vulnérables et les rapports sur les licences, lorsqu'ils travaillent 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é de la fonctionnalité: la source protect Cloud Code n'est pas disponible pour un accès public. Pour accéder à cette fonctionnalité, consultez la page de demande d'accès.

Étape suivante