View a markdown version of this page

Passez en revue les résultats de sécurité du code dans les pull requests - Agent de sécurité AWS
Comment fonctionne la révision du code dans les pull requestsComprendre les résultats de la révision du codeRéagir aux constatations relatives à la sécuritéRésultats de l'examen du code de filtrageÉtapes suivantes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Passez en revue les résultats de sécurité du code dans les pull requests

Après avoir activé la révision du code pour les pull requests pour vos référentiels, AWS Security Agent analyse automatiquement les pull requests et publie les résultats de sécurité directement dans votre fournisseur de contrôle de source. Cela permet aux développeurs de résoudre les problèmes de sécurité dans le cadre de leur flux de travail normal sans avoir à quitter la pull request.

Note

Cette page s'applique aux GitHub pull requests, aux demandes de GitLab fusion et aux pull requests Bitbucket. L'expérience est similaire chez tous les fournisseurs.

Comment fonctionne la révision du code dans les pull requests

Lorsque vous soumettez une pull request (ou une demande de fusion GitLab) dans un référentiel où la révision du code est activée, AWS Security Agent lance automatiquement l'analyse.

  1. Déclencheur d'analyse des pull requests : la révision du code est déclenchée lorsqu'une pull request est marquée comme « prête à être révisée » dans les référentiels où vous avez activé la fonctionnalité de révision du code. Les brouillons de pull requests ne sont pas analysés.

  2. Confirmation de l'analyse : lorsqu'AWS Security Agent commence à analyser votre pull request, il publie un premier commentaire : « L'agent de sécurité AWS analyse votre code... » Cela vous indique que l'analyse a commencé et est en cours.

  3. Fin de la révision : une fois l'analyse terminée, l'agent de sécurité AWS publie un avis sur votre pull request avec les résultats. Tous les résultats de sécurité sont regroupés dans un seul examen afin d'organiser votre pull request et de minimiser les notifications.

Comprendre les résultats de la révision du code

AWS Security Agent fournit différents types de résultats en fonction de ce qu'il trouve lors de l'analyse.

Lorsque des problèmes de sécurité sont détectés

Si AWS Security Agent identifie des problèmes de sécurité dans vos modifications de code, il publie un avis qui inclut :

  • Résumé - Vue d'ensemble de tous les résultats de sécurité, décrivant les types de problèmes identifiés et leur impact potentiel

  • Conclusions individuelles - Les résultats de sécurité détaillés apparaissent sous forme de commentaires sous forme de fil de discussion sous la revue principale, chaque résultat incluant :

    • Description du problème de sécurité

    • Emplacement dans votre code où le problème a été détecté

    • Conseils de correction expliquant comment résoudre le problème

    • Contexte pertinent en fonction de vos paramètres de révision du code (violations des exigences de sécurité, vulnérabilités courantes, ou les deux)

Note

Les types de problèmes de sécurité analysés dépendent de vos paramètres de révision du code. Si vous avez configuré la validation des exigences de sécurité, les résultats feront référence aux exigences de sécurité personnalisées de votre organisation. Si vous avez configuré les résultats des vulnérabilités de sécurité, les résultats identifieront les vulnérabilités de sécurité courantes. Pour plus d'informations sur les paramètres de révision du code, consultezActiver la révision du code de pull request pour les GitHub référentiels.

Lorsqu'aucun problème de sécurité n'est détecté

Si AWS Security Agent termine son analyse et ne détecte aucun problème de sécurité dans vos modifications de code, il publie le commentaire suivant : « Aucun problème identifié ». Cela confirme que la révision s'est terminée correctement et que les modifications apportées au code n'ont entraîné aucun résultat de sécurité sur la base des paramètres de révision du code que vous avez configurés.

Réagir aux constatations relatives à la sécurité

Après avoir examiné les résultats de sécurité publiés par l'agent de sécurité AWS, vous pouvez prendre des mesures directement auprès de votre fournisseur de contrôle de source.

  • Corriger les résultats : mettez à jour votre code en fonction des conseils de correction fournis dans les résultats, puis envoyez de nouveaux validations à la pull request. L'agent de sécurité AWS analysera le code mis à jour.

  • Résoudre les conversations : après avoir répondu à un problème de sécurité, marquez la conversation comme étant résolue pour suivre votre progression.

Astuce

Chaque résultat inclut des conseils de correction spécifiques adaptés au problème de sécurité identifié. Lisez attentivement ce guide pour comprendre le risque de sécurité et savoir comment y faire face efficacement.

Résultats de l'examen du code de filtrage

Vous pouvez personnaliser la façon dont AWS Security Agent analyse votre code en ajoutant un filtering.md fichier à votre référentiel. Ce fichier vous permet de réduire le nombre de faux positifs en fournissant le contexte de votre base de code et en excluant des fichiers ou des dossiers de l'analyse.

Création du fichier de filtrage

Créez un fichier nommé filtering.md dans le .awssecurityagent répertoire à la racine de votre dépôt :

.awssecurityagent/filtering.md

AWS Security Agent lit ce fichier depuis la branche principale de votre référentiel (par exemple, main oumainline) lors de l'analyse des pull requests.

Structure de fichier

Le filtering.md fichier utilise le format Markdown standard avec des sections spécifiques reconnues par AWS Security Agent. Le fichier doit inclure un Code Review titre suivi de l'une ou des deux sections suivantes : IgnorePatterns et ContextHints (sans espace).

L'exemple suivant montre la structure complète d'un filtering.md fichier :

# filtering.md

## Code Review

### IgnorePatterns

**/*.md

/myapp/src/**/*.snap

/myapp/config/README

### ContextHints

- The backend is a trusted system and won't return non-standard protocols.
- URL is generated from server with presigned token, so no SSRF security vulnerabilities.
- AppSec has verified that we are allowed to use cache with an eviction policy.

Ignorer les modèles

Cette IgnorePatterns section indique les fichiers et les dossiers que l'agent de sécurité AWS doit ignorer lors de la révision du code. Permet glob patterns de définir les chemins à exclure de l'analyse.

Exigences relatives au format :

  • Chaque motif doit être sur sa propre ligne.

  • Séparez chaque motif par une ligne vide entre eux. Cela garantit que le fichier s'affiche correctement lorsqu'il est affiché dans les GitHub outils de révision du code.

  • Les motifs suivent le format standard du globe. Par exemple, **/*.md correspond à tous les fichiers Markdown et /myapp/src/**/*.snap correspond à tous les .snap fichiers du /myapp/src/ dossier situé à la racine.

  • Nous prenons en charge jusqu'à 1 000 modèles d'ignorance dans cette section.

Indications contextuelles

Cette ContextHints section fournit un contexte supplémentaire sur votre base de code afin d'aider AWS Security Agent à effectuer des évaluations plus précises. Utilisez des indications contextuelles pour expliquer les décisions architecturales, les exceptions de sécurité ou d'autres informations susceptibles d'affecter la façon dont les résultats sont interprétés.

Exigences relatives au format :

  • Chaque indice doit commencer par un tiret (-) suivi d'un espace.

  • Écrivez chaque indice sous la forme d'une seule ligne de texte libre limitée à 500 caractères.

  • Chaque indice doit décrire un élément de contexte spécifique concernant votre base de code.

  • Nous prenons en charge jusqu'à 20 indices contextuels dans cette section.

Les indications contextuelles sont appliquées une fois qu'AWS Security Agent a terminé son analyse initiale, ce qui permet de filtrer les résultats qui ne s'appliquent pas à votre cas d'utilisation spécifique.

Étapes suivantes

Après avoir examiné les résultats relatifs à la sécurité du code :

  • Mettez à jour votre code en fonction des conseils de correction

  • Proposez de nouvelles validations pour déclencher une nouvelle analyse de vos modifications

  • Ajustez les paramètres de révision du code si nécessaire (voirActiver la révision du code de pull request pour les GitHub référentiels)

  • Passez en revue les exigences de sécurité de votre organisation pour comprendre les critères de validation

  • Envisagez des tests de pénétration pour une validation complète de la sécurité des applications déployées