Évaluation des modules - Training

1.

Qu’est-ce qui rend les secrets codés en dur dans le code source plus dangereux que d’autres vulnérabilités de sécurité ?

Ils nécessitent des compétences techniques avancées pour exploiter.

Ils fournissent un accès immédiat et illimité aux ressources protégées sans exiger que les attaquants contournent les mesures de sécurité.

Ils affectent uniquement les environnements de développement, et non les systèmes de production.

2.

Quelle est la réponse la plus sécurisée lorsqu’un secret est découvert dans le code source ?

Supprimez le secret du code actuel, mais laissez-le dans l’historique Git.

Révoquez immédiatement les informations d’identification exposées, générez-en une nouvelle, supprimez-la du code et de l’historique Git, puis mettez à jour toutes les applications qui l’utilisent.

Ajoutez des commentaires pour avertir les développeurs de ne pas utiliser les informations d’identification exposées.

3.

Comment l’analyse des secrets GitHub détecte-t-elle les informations d’identification dans les référentiels ?

GitHub Secret Scanning examine manuellement le code pendant les révisions de demandes de tirage.

L’analyse des secrets GitHub examine les fichiers en fonction des modèles secrets connus à l’aide d’expressions régulières et valide les modèles détectés avec les fournisseurs de services.

GitHub Secret Scanning analyse uniquement les nouveaux commits et ignore l’historique du dépôt.

4.

Quelle est la principale différence entre l’analyse de secrets GitHub et la protection push ?

L’analyse des secrets détecte les informations d’identification déjà dans le référentiel, tandis que la protection push empêche les secrets d’entrer dans le référentiel.

L’analyse des secrets fonctionne uniquement sur les référentiels publics, tandis que la protection push fonctionne uniquement sur les référentiels privés.

La protection Push détecte uniquement les clés API, tandis que l’analyse des secrets détecte tous les types d’informations d’identification.

5.

Lorsque la protection push bloque un envoi, quelle est la marche à suivre ?

Pour continuer rapidement, demandez un contournement avec une brève justification.

Supprimez localement le secret des commits, implémentez le stockage sécurisé et envoyez à nouveau.

Supprimez l’intégralité du référentiel et recommencez.

6.

Quel est l’objectif principal de l’utilisation du mode Demande de GitHub Copilot pour analyser les alertes de détection de secrets ?

Pour résoudre automatiquement tous les problèmes de sécurité sans intervention du développeur.

Pour comprendre pourquoi les alertes ont été déclenchées, évaluez les implications de sécurité et planifiez des stratégies de correction avant d’apporter des modifications au code.

Pour générer de nouvelles informations d’identification afin de remplacer celles qui sont exposées.

7.

Lorsque le mode Ask de GitHub Copilot est utilisé pour analyser un secret exposé, quelle est la méthode de prompt la plus efficace ?

Poser des questions générales sans sélectionner de code ni fournir de contexte.

Sélection du code contenant le secret et poser des questions spécifiques sur le type d’informations d’identification, le risque et les options de correction.

Demandez uniquement du code non lié pour éviter d’exposer le secret à l’IA.

8.

Quelle est la principale différence entre le mode Demander de GitHub Copilot et le mode Agent pour la correction des secrets ?

Le mode Demander fournit une analyse et des suggestions sans modifier de code, tandis que le mode Agent implémente les modifications directement dans les fichiers de code.

Le mode Demander fonctionne uniquement avec du code C#, tandis que le mode Agent prend en charge tous les langages de programmation.

Le mode Agent ne peut supprimer que les secrets, tandis que le mode Ask peut implémenter des modèles de stockage sécurisés.

9.

Lorsque vous utilisez le mode Agent de GitHub Copilot pour corriger les informations confidentielles, quel type de demande produit les meilleurs résultats ?

Demandes vagues telles que « résoudre ce problème de sécurité » sans spécificités.

Des invites spécifiques et actionnables qui décrivent la correction souhaitée, telles que « Supprimer la clé API Stripe codée en dur et la remplacer par l’accès aux variables d’environnement ».

Instructions en conflit multiples dans une seule invite.

10.

Selon le flux de travail de correction, quand un développeur doit-il faire pivoter les informations d’identification exposées ?

Pour éviter d’interrompre le développement, faites pivoter les informations d’identification exposées après avoir terminé les mises à jour du code et testé l’application.

Immédiatement comme première étape, avant d’apporter des modifications de code, pour invalider les informations d’identification exposées.

Uniquement si les informations d’identification sont marquées comme « Valide » dans l’onglet Sécurité GitHub.

11.

Pourquoi un développeur doit-il utiliser le mode Demander de GitHub Copilot avant d’utiliser le mode Agent pour la correction des secrets ?

Le mode Demander est plus rapide et peut terminer la correction sans mode Agent.

Pour comprendre l’étendue de l’exposition, analyser les dépendances et formuler un plan de correction complet avant d’apporter des modifications.

Le mode Demander est requis pour l’authentification avant que le mode Agent fonctionne.

12.

Quel est l’objectif de supprimer les secrets de l’historique Git dans le cadre du flux de travail de correction ?

Pour améliorer les performances du référentiel en réduisant les tailles de fichiers.

Pour vous assurer que les informations d’identification sont supprimées du référentiel, car elles restent accessibles dans les validations historiques, même après la suppression du code actuel.

Pour révoquer automatiquement les informations d’identification exposées sur la plateforme du fournisseur de services.

Évaluation du module

Vérifier vos connaissances

Commentaires