Partager via

Recommandations de sécurité pour les ressources DevOps

  • Article

Cet article répertorie les recommandations que vous pouvez voir dans Microsoft Defender pour le cloud si vous connectez un environnement Azure DevOps, GitHub ou GitLab à l’aide de la page paramètres de l’environnement. Les recommandations qui apparaissent dans votre environnement sont basées sur les ressources que vous protégez et sur votre configuration personnalisée.

Pour en savoir plus sur les actions que vous pouvez effectuer en réponse à ces recommandations, consultez Correction des recommandations dans Defender pour le cloud.

En savoir plus sur les avantages et les fonctionnalités de la sécurité DevOps.

Les recommandations DevOps n’affectent pas votre score de sécurisation. Pour déterminer les recommandations à résoudre en premier, examinez la gravité de chaque recommandation et son impact potentiel sur votre score sécurisé.

Recommandations Azure DevOps

GitHub Advanced Security pour Azure DevOps (GHAzDO) doit être activé dans les dépôts Azure DevOps

Description : La sécurité DevOps dans Defender pour le cloud utilise une console centrale pour permettre aux équipes de sécurité de protéger les applications et les ressources du code vers le cloud dans Azure DevOps. Avec l’activation de dépôts GitHub Advanced Security pour Azure DevOps (GHAzDO), notamment GitHub Advanced Security pour Azure DevOps, vous obtenez des résultats sur les secrets, les dépendances et les vulnérabilités de code dans vos référentiels Azure DevOps exposés dans Microsoft Defender pour le cloud.

Gravité : élevée

Les découvertes de l’analyse des secrets doivent être résolues pour les dépôts Azure DevOps

Description : Les secrets ont été trouvés dans les référentiels de code. Corrigez cela immédiatement pour éviter une violation de la sécurité. Les secrets trouvés dans les référentiels peuvent fuiter ou être découverts par des adversaires, ce qui entraîne la compromission d’une application ou d’un service. L’outil d’analyse des informations d’identification Microsoft Security DevOps analyse uniquement les builds sur lesquelles il est configuré pour s’exécuter. Par conséquent, les résultats peuvent ne pas refléter l’état complet des secrets dans vos dépôts.

Gravité : élevée

Les découvertes de l’analyse du code doivent être résolues pour les dépôts Azure DevOps

Description : Les vulnérabilités ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

Les découvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les dépôts Azure DevOps

Description : vulnérabilités de dépendance trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les dépôts Azure DevOps

Description : Problèmes de configuration de sécurité de l’infrastructure en tant que code trouvés dans les référentiels. Les problèmes ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.

Gravité : moyenne

Les pipelines Azure DevOps ne doivent pas avoir de secrets disponibles pour les builds de fourche

Description : dans les référentiels publics, il est possible que les personnes extérieures à l’organisation créent des duplications et exécutent des builds sur le référentiel dupliqué. Dans un tel cas, si ce paramètre est activé, des tiers peuvent accéder à la création de secrets de pipeline de build censés être internes.

Gravité : élevée

Les connexions du service Azure DevOps ne doivent pas accorder l'accès à tous les pipelines

Description : les connexions de service sont utilisées pour créer des connexions à partir d’Azure Pipelines vers des services externes et distants pour l’exécution de tâches dans un travail. Les autorisations de pipeline contrôlent quels pipelines sont autorisés à utiliser la connexion de service. Pour prendre en charge la sécurité des opérations du pipeline, les connexions de service ne doivent pas avoir accès à tous les pipelines YAML. Cela permet de maintenir le principe du privilège minimum, car une vulnérabilité dans les composants utilisés par un pipeline peut être utilisée par un attaquant pour attaquer d’autres pipelines ayant accès aux ressources critiques.

Gravité : élevée

Les fichiers sécurisés Azure DevOps ne doivent pas accorder l'accès à tous les pipelines

Description : Les fichiers sécurisés permettent aux développeurs de stocker des fichiers qui peuvent être partagés entre des pipelines. Ces fichiers sont généralement utilisés pour stocker des secrets tels que la signature de certificats et de clés SSH. Si un fichier sécurisé a accès à tous les pipelines YAML, un utilisateur non autorisé peut voler des informations dans les fichiers sécurisés en créant un pipeline YAML et en accédant au fichier sécurisé.

Gravité : élevée

Les groupes de variables Azure DevOps avec des variables de secret ne doivent pas accorder l'accès à tous les pipelines

Description : les groupes de variables stockent des valeurs et des secrets que vous souhaiterez peut-être passer dans un pipeline YAML ou rendre disponibles sur plusieurs pipelines. Vous pouvez partager et utiliser des groupes de variables entre plusieurs pipelines dans le même projet. Si un groupe de variables contenant des secrets est marqué comme accessible à tous les pipelines YAML, alors un attaquant peut exploiter les actifs impliquant les variables secrètes en créant un nouveau pipeline.

Gravité : élevée

Les connexions du service classique Azure DevOps ne doivent pas être utilisées pour accéder à un abonnement

Description : Utilisez le type de connexions de service Azure Resource Manager (ARM) au lieu des connexions de service Azure Classic pour vous connecter à des abonnements Azure. Le modèle ARM offre de multiples améliorations de sécurité, notamment un contrôle d'accès plus fort, un audit amélioré, un déploiement/gouvernance basé sur ARM, l'accès aux identités gérées et au coffre-fort de clés pour les secrets, l'authentification basée sur les autorisations Entra et la prise en charge des balises et des groupes de ressources pour une gestion rationalisée.

Gravité : moyenne

(Préversion) Les dépôts Azure DevOps doivent avoir des résultats de test de sécurité d’API résolus

Description : vulnérabilités de sécurité des API trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

(Préversion) Les référentiels Azure DevOps doivent exiger une approbation minimale à deux réviseurs pour les envois de code

Description : Pour empêcher les modifications involontaires ou malveillantes d’être validées directement, il est important d’implémenter des stratégies de protection pour les branche par défaut dans les référentiels Azure DevOps. Nous vous recommandons d’exiger au moins deux réviseurs de code pour approuver les demandes de tirage avant la fusion du code avec le branche par défaut. En exigeant l’approbation d’un nombre minimal de deux réviseurs, vous pouvez réduire le risque de modifications non autorisées, ce qui peut entraîner une instabilité du système ou des vulnérabilités de sécurité.

Cette recommandation est fournie dans Defender pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.

Gravité : élevée

(Préversion) Les référentiels Azure DevOps ne doivent pas autoriser les demandeurs à approuver leurs propres demandes de tirage

Description : Pour empêcher les modifications involontaires ou malveillantes d’être validées directement, il est important d’implémenter des stratégies de protection pour les branche par défaut dans les référentiels Azure DevOps. Nous vous recommandons d’interdire aux créateurs de demandes de tirage d’approuver leurs propres soumissions pour s’assurer que chaque modification subit un examen objectif par quelqu’un d’autre que l’auteur. En procédant ainsi, vous pouvez réduire le risque de modifications non autorisées, ce qui peut entraîner une instabilité du système ou des vulnérabilités de sécurité.

Cette recommandation est fournie dans Defender pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.

Gravité : élevée

Recommandations GitHub

Les organisations GitHub ne doivent pas rendre les secrets d’action accessibles à tous les référentiels

Description : Pour les secrets utilisés dans les flux de travail GitHub Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les dépôts qui peuvent utiliser des secrets d’organisation. Les secrets au niveau de l’organisation vous permettent de partager des secrets entre plusieurs référentiels. Cela réduit la nécessité de créer des secrets en double. Toutefois, une fois qu’un secret est rendu accessible à un référentiel, toute personne disposant d’un accès en écriture sur le référentiel peut accéder au secret à partir de n’importe quelle branche d’un flux de travail. Pour réduire la surface d’attaque, assurez-vous que le secret est accessible uniquement à partir de référentiels sélectionnés.

Cette recommandation est fournie dans Defender pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.

Gravité : élevée

L’analyse des secrets doit être activée dans les référentiels GitHub

Description : GitHub analyse les référentiels pour les types connus de secrets afin d’empêcher l’utilisation frauduleuse de secrets qui ont été accidentellement validés dans les référentiels. L’analyse des secrets analyse l’intégralité de l’historique Git sur toutes les branches présentes dans le dépôt GitHub à la recherche de secrets. Les jetons et les clés privées qu’un fournisseur de services peut émettre pour l’authentification sont des exemples de secrets. Si un secret est archivé dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut utiliser le secret pour accéder au service externe avec ces privilèges. Les secrets doivent être stockés dans un emplacement dédié et sécurisé en dehors du dépôt du projet.

Gravité : élevée

L’analyse du code doit être activée dans les référentiels GitHub

Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités de sécurité et des erreurs dans le code. L’analyse du code peut être utilisée pour rechercher, trier et hiérarchiser les correctifs pour les problèmes existants dans votre code. L’analyse du code peut également empêcher les développeurs d’introduire de nouveaux problèmes. Des analyses peuvent être planifiées pour des jours et heures spécifiques, ou être déclenchées lorsqu’un événement spécifique se produit dans le dépôt, tel qu’un envoi (push). Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans le code, GitHub affiche une alerte dans le dépôt. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour endommager la confidentialité, l’intégrité ou la disponibilité du projet.

Gravité : moyenne

L’analyse Dependabot doit être activée dans les dépôts GitHub

Description : GitHub envoie des alertes Dependabot lorsqu’il détecte les vulnérabilités dans les dépendances de code qui affectent les dépôts. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour altérer la confidentialité, l’intégrité ou la disponibilité du projet ou d’autres projets qui utilisent son code. Les vulnérabilités varient en fonction du type, de la gravité et de la méthode d’attaque. Quand le code dépend d’un package qui présente une faille de sécurité, cette dépendance vulnérable peut entraîner une série de problèmes.

Gravité : moyenne

Les découvertes de l’analyse des secrets doivent être résolues pour les dépôts GitHub

Description : Secrets trouvés dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service.

Gravité : élevée

Les découvertes de l’analyse du code doivent être résolues pour les dépôts GitHub

Description : Vulnérabilités trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

Les découvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les dépôts GitHub

Description : Les dépôts GitHub doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.

Gravité : moyenne

Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les dépôts GitHub

Description : Les problèmes de configuration de sécurité de l’infrastructure en tant que code ont été détectés dans les référentiels. Les problèmes ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.

Gravité : moyenne

Les stratégies de protection pour la branche par défaut doivent être activées pour les dépôts GitHub

Description : la branche par défaut du référentiel doit être protégée via des stratégies de protection de branche pour empêcher les modifications involontaires/malveillantes d’être directement validées dans le référentiel.

Gravité : élevée

Les envois (push) forcés à la branche par défaut doivent être désactivés pour les dépôts GitHub

Description : étant donné que le branche par défaut est généralement utilisé pour le déploiement et d’autres activités privilégiées, toutes les modifications apportées à celle-ci doivent être abordées avec prudence. L'activation des poussées forcées peut introduire des modifications involontaires ou malveillantes dans la branche par défaut.

Gravité : moyenne

La protection des envois (push) de l’analyse des secrets doit être activée pour les organisations GitHub

Description : La protection Push bloque les validations qui contiennent des secrets, ce qui empêche l’exposition accidentelle des secrets. Pour éviter tout risque d'exposition des informations d'identification, la protection Push doit être automatiquement activée pour chaque référentiel activé pour l'analyse secrète.

Gravité : élevée

Les dépôts GitHub ne doivent pas utiliser d’exécuteurs auto-hébergés

Description : Les exécuteurs auto-hébergés sur GitHub ne garantissent pas l’opération dans des machines virtuelles propres éphémères et peuvent être compromis de manière persistante par du code non approuvé dans un flux de travail. En tant que tels, les coureurs auto-hébergés ne doivent pas être utilisés pour les flux de travail d'action.

Gravité : élevée

Les organisations GitHub doivent avoir des autorisations de workflow d'actions définies en lecture seule

Description : Par défaut, les flux de travail Action doivent disposer d’autorisations en lecture seule pour empêcher les utilisateurs malveillants d’exploiter des flux de travail sur-autorisés pour accéder aux ressources et les falsifier.

Gravité : élevée

Les organisations GitHub doivent avoir plus d'une personne disposant d'autorisations d'administrateur

Description : Avoir au moins deux administrateurs réduit le risque de perdre l’accès administrateur. Ceci est utile en cas de scénarios de compte brisé.

Gravité : élevée

Les organisations GitHub doivent avoir des autorisations de base définies sur aucune autorisation ou en lecture

Description : Les autorisations de base doivent être définies sur aucune ou lue pour qu’une organisation suive le principe du privilège minimum et empêche l’accès inutile.

Gravité : élevée

Les découvertes des tests de sécurité des API doivent être résolues pour les dépôts GitHub

Description : Les vulnérabilités de sécurité des API ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

(Préversion) Les organisations GitHub ne doivent pas rendre les secrets d’action accessibles à tous les référentiels

Description : Pour les secrets utilisés dans les flux de travail GitHub Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les dépôts qui peuvent utiliser les secrets de l’organisation. Les secrets au niveau de l’organisation vous permettent de partager des secrets entre plusieurs référentiels, ce qui réduit la nécessité de créer des secrets en double. Toutefois, lorsqu’un secret est rendu accessible à un référentiel, toute personne disposant d’un accès en écriture sur le référentiel peut accéder au secret à partir de n’importe quelle branche d’un flux de travail. Pour réduire la surface d’attaque, assurez-vous que le secret est accessible uniquement à partir de référentiels sélectionnés.

Gravité : élevée

Recommandations GitLab

Les découvertes de l’analyse des secrets doivent être résolues pour les projets GitLab

Description : Les secrets ont été trouvés dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service.

Gravité : élevée

Les découvertes de l’analyse du code doivent être résolues pour les projets GitLab

Description : Les vulnérabilités ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.

Gravité : moyenne

Les découvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les projets GitLab

Description : Les dépôts GitHub doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.

Gravité : moyenne

Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les projets GitLab

Description : Les problèmes de configuration de sécurité de l’infrastructure en tant que code ont été détectés dans les référentiels. Les problèmes indiqués ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.

Gravité : moyenne

Recommandations de sécurité DevOps dépréciées

Les dépôts de code doivent avoir les résultats de l’analyse du code résolus

Description : La sécurité DevOps dans Defender pour le cloud a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse des secrets résolus

Description : La sécurité DevOps dans Defender pour le cloud a trouvé un secret dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service. Pour Azure DevOps, l’outil Microsoft Security DevOps CredScan analyse uniquement les builds sur lesquelles il a été configuré pour s’exécuter. Par conséquent, les résultats peuvent ne pas refléter l’état complet des secrets dans vos dépôts. (Aucune stratégie associée)

Gravité : élevée

Les dépôts de code doivent avoir les résultats de l’analyse Dependabot résolus

Description : La sécurité DevOps dans Defender pour le cloud a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse de l’infrastructure en tant que code résolus

Description : La sécurité DevOps dans Defender pour le cloud a trouvé l’infrastructure en tant que problèmes de configuration de sécurité du code dans les référentiels. Les problèmes indiqués ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes. (Aucune stratégie associée)

Gravité : moyenne

L’analyse du code doit être activée dans les référentiels GitHub

Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités de sécurité et des erreurs dans le code. L’analyse du code peut être utilisée pour rechercher, trier et hiérarchiser les correctifs pour les problèmes existants dans votre code. L’analyse du code peut également empêcher les développeurs d’introduire de nouveaux problèmes. Des analyses peuvent être planifiées pour des jours et heures spécifiques, ou être déclenchées lorsqu’un événement spécifique se produit dans le dépôt, tel qu’un envoi (push). Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans le code, GitHub affiche une alerte dans le dépôt. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour endommager la confidentialité, l’intégrité ou la disponibilité du projet. (Aucune stratégie associée)

Gravité : moyenne

L’analyse des secrets doit être activée dans les référentiels GitHub

Description : GitHub analyse les référentiels pour les types connus de secrets afin d’empêcher l’utilisation frauduleuse de secrets qui ont été accidentellement validés dans les référentiels. L’analyse des secrets analyse l’intégralité de l’historique Git sur toutes les branches présentes dans le dépôt GitHub à la recherche de secrets. Les jetons et les clés privées qu’un fournisseur de services peut émettre pour l’authentification sont des exemples de secrets. Si un secret est archivé dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut utiliser le secret pour accéder au service externe avec ces privilèges. Les secrets doivent être stockés dans un emplacement dédié et sécurisé en dehors du dépôt du projet. (Aucune stratégie associée)

Gravité : élevée

L’analyse Dependabot doit être activée dans les dépôts GitHub

Description : GitHub envoie des alertes Dependabot lorsqu’il détecte les vulnérabilités dans les dépendances de code qui affectent les dépôts. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour altérer la confidentialité, l’intégrité ou la disponibilité du projet ou d’autres projets qui utilisent son code. Les vulnérabilités varient en fonction du type, de la gravité et de la méthode d’attaque. Quand le code dépend d’un package qui présente une faille de sécurité, cette dépendance vulnérable peut entraîner une série de problèmes. (Aucune stratégie associée)

Gravité : moyenne

Contenu connexe