doc-locale/fr-fr/user/application_security/vulnerabilities/_index.md
{{< details >}}
{{< /details >}}
Chaque vulnérabilité dans un projet possède une page de vulnérabilité contenant les détails de la vulnérabilité, notamment :
Pour les vulnérabilités figurant dans le catalogue Common Vulnerabilities and Exposures (CVE), ces détails incluent également :
Pour plus de détails sur ces données supplémentaires, voir les données d'évaluation des risques de vulnérabilité.
Si le scanner a déterminé que la vulnérabilité est un faux positif, un message d'alerte est inclus en haut de la page de la vulnérabilité.
Pour les vulnérabilités détectées par SAST, GitLab Duo peut les analyser automatiquement et générer une merge request avec des corrections de code adaptées au contexte. Pour plus d'informations, voir Agentic SAST vulnerability resolution.
{{< details >}}
{{< /details >}}
{{< history >}}
duo_secret_detection_false_positive. Activé sur GitLab.com, GitLab Self-Managed et GitLab Dedicated.{{< /history >}}
GitLab Duo analyse automatiquement les résultats de détection des secrets pour identifier les faux positifs potentiels. Rejeter les faux positifs réduit le bruit dans votre rapport de vulnérabilités en signalant les résultats qui ne constituent probablement pas des risques de sécurité réels.
Pour chaque vulnérabilité analysée, GitLab Duo fournit les informations suivantes :
Pour plus d'informations, voir Secret false positive detection.
{{< details >}}
{{< /details >}}
{{< collapsible title="Informations sur le modèle" >}}
{{< /collapsible >}}
{{< history >}}
{{< /history >}}
Utilisez GitLab Duo Vulnerability resolution pour créer automatiquement une merge request qui résout la vulnérabilité. Par défaut, il est propulsé par le modèle claude-3.5-sonnet d'Anthropic.
GitLab ne peut pas garantir que le grand modèle de langage produit des résultats corrects. Vous devez toujours examiner la modification proposée avant de la fusionner. Lors de la révision, vérifiez que :
<i class="fa-youtube-play" aria-hidden="true"></i> Regarder un aperçu
Prérequis :
Apprenez-en davantage sur comment activer toutes les fonctionnalités GitLab Duo.
Pour résoudre la vulnérabilité :
Une merge request contenant les suggestions de correction par l'IA est ouverte. Examinez les modifications suggérées, puis traitez la merge request selon votre workflow standard.
Donnez votre avis sur cette fonctionnalité dans le ticket 476553.
Pour garantir que les résolutions suggérées sont de haute qualité, Vulnerability Resolution est disponible pour un ensemble spécifique de vulnérabilités. Le système décide de proposer ou non la Vulnerability Resolution en fonction de l'identifiant Common Weakness Enumeration (CWE) de la vulnérabilité.
L'ensemble actuel de vulnérabilités est sélectionné sur la base de tests effectués par des systèmes automatisés et des experts en sécurité. GitLab travaille activement à étendre la couverture à davantage de types de vulnérabilités.
<details><summary style="color:#5943b6; margin-top: 1em;"><a>Voir la liste complète des CWE pris en charge pour Vulnerability Resolution</a></summary> <ul> <li>CWE-23 : Relative Path Traversal</li> <li>CWE-73 : External Control of File Name or Path</li> <li>CWE-78 : Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')</li> <li>CWE-80 : Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</li> <li>CWE-89 : Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')</li> <li>CWE-116 : Improper Encoding or Escaping of Output</li> <li>CWE-118 : Incorrect Access of Indexable Resource ('Range Error')</li> <li>CWE-119 : Improper Restriction of Operations within the Bounds of a Memory Buffer</li> <li>CWE-120 : Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')</li> <li>CWE-126 : Buffer Over-read</li> <li>CWE-190 : Integer Overflow or Wraparound</li> <li>CWE-200 : Exposure of Sensitive Information to an Unauthorized Actor</li> <li>CWE-208 : Observable Timing Discrepancy</li> <li>CWE-209 : Generation of Error Message Containing Sensitive Information</li> <li>CWE-272 : Least Privilege Violation</li> <li>CWE-287 : Improper Authentication</li> <li>CWE-295 : Improper Certificate Validation</li> <li>CWE-297 : Improper Validation of Certificate with Host Mismatch</li> <li>CWE-305 : Authentication Bypass by Primary Weakness</li> <li>CWE-310 : Cryptographic Issues</li> <li>CWE-311 : Missing Encryption of Sensitive Data</li> <li>CWE-323 : Reusing a Nonce, Key Pair in Encryption</li> <li>CWE-327 : Use of a Broken or Risky Cryptographic Algorithm</li> <li>CWE-328 : Use of Weak Hash</li> <li>CWE-330 : Use of Insufficiently Random Values</li> <li>CWE-338 : Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)</li> <li>CWE-345 : Insufficient Verification of Data Authenticity</li> <li>CWE-346 : Origin Validation Error</li> <li>CWE-352 : Cross-Site Request Forgery</li> <li>CWE-362 : Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')</li> <li>CWE-369 : Divide By Zero</li> <li>CWE-377 : Insecure Temporary File</li> <li>CWE-378 : Creation of Temporary File With Insecure Permissions</li> <li>CWE-400 : Uncontrolled Resource Consumption</li> <li>CWE-489 : Active Debug Code</li> <li>CWE-521 : Weak Password Requirements</li> <li>CWE-539 : Use of Persistent Cookies Containing Sensitive Information</li> <li>CWE-599 : Missing Validation of OpenSSL Certificate</li> <li>CWE-611 : Improper Restriction of XML External Entity Reference</li> <li>CWE-676 : Use of potentially dangerous function</li> <li>CWE-704 : Incorrect Type Conversion or Cast</li> <li>CWE-754 : Improper Check for Unusual or Exceptional Conditions</li> <li>CWE-770 : Allocation of Resources Without Limits or Throttling</li> <li>CWE-1004 : Sensitive Cookie Without 'HttpOnly' Flag</li> <li>CWE-1275 : Sensitive Cookie with Improper SameSite Attribute</li> </ul> </details>Vulnerability Resolution ne peut parfois pas générer de correctif suggéré. Les causes courantes sont les suivantes :
an unexpected error has occurred, the upstream AI provider request timed out, something went wrong, ou une cause similaire.Les données suivantes sont partagées avec des API d'IA tierces :
{{< details >}}
{{< /details >}}
{{< history >}}
resolve_vulnerability_in_mr a été supprimé.{{< /history >}}
Utilisez GitLab Duo Vulnerability resolution pour créer automatiquement un commentaire de suggestion de merge request qui résout le résultat de la vulnérabilité. Par défaut, il est propulsé par le modèle claude-3.5-sonnet d'Anthropic.
Pour résoudre le résultat de la vulnérabilité :
Un commentaire contenant les suggestions de correction par l'IA est ouvert dans la merge request. Examinez les modifications suggérées, puis appliquez la suggestion de merge request selon votre workflow standard.
Donnez votre avis sur cette fonctionnalité dans le ticket 476553.
Vulnerability Resolution dans une merge request ne peut parfois pas générer de correctif suggéré. Les causes courantes sont les suivantes :
an unexpected error has occurred, the upstream AI provider request timed out, something went wrong, ou une cause similaire.Resolution target could not be found in the merge request, unable to create suggestion :
{{< details >}}
{{< /details >}}
Pour certains types de vulnérabilités, GitLab Advanced SAST fournit des informations sur le flux de code. Le flux de code d'une vulnérabilité est le chemin que les données empruntent depuis l'entrée utilisateur (source) jusqu'à la ligne de code vulnérable (sink), en passant par toutes les affectations, manipulations et opérations de nettoyage.
Pour plus de détails sur la façon d'afficher le flux de code d'une vulnérabilité, voir le flux de code de la vulnérabilité.
Le statut d'une vulnérabilité peut être :
Une vulnérabilité suit généralement le cycle de vie suivant :
%%{init: { "fontFamily": "GitLab Sans" }}%%
stateDiagram
accTitle: Vulnerability lifecycle
accDescr: Typical lifecycle of a vulnerability
direction LR
Needs_triage: Needs triage
[*] --> Needs_triage
Needs_triage --> Confirmed
Needs_triage --> Dismissed
Dismissed --> [*]
Confirmed --> Resolved
Resolved --> Needs_triage: If reintroduced and detected again
Resolved --> [*]
{{< history >}}
vulnerability_representation_information a été supprimé.{{< /history >}}
Une vulnérabilité peut ne plus être détectée en raison de modifications apportées délibérément pour la corriger ou comme effet secondaire d'autres changements. Lorsqu'un scan de sécurité s'exécute et qu'une vulnérabilité n'est plus détectée dans la branche par défaut, le scanner ajoute N'est plus détectée au journal d'activité de l'enregistrement, mais le statut de l'enregistrement ne change pas. Vous devez plutôt vérifier et confirmer que la vulnérabilité a été résolue et, le cas échéant, modifier manuellement son statut en Résolue. Vous pouvez également utiliser une politique de gestion des vulnérabilités pour modifier automatiquement le statut des vulnérabilités correspondant à des critères spécifiques en Résolue.
Vous pouvez trouver un lien vers le commit qui a résolu la vulnérabilité en haut ou en bas de la page de la vulnérabilité.
{{< history >}}
dismissal_reason.dismissal_reason a été supprimé.{{< /history >}}
Lorsque vous rejetez une vulnérabilité, vous devez choisir l'une des raisons suivantes :
{{< history >}}
Developer de modifier le statut d'une vulnérabilité (admin_vulnerability) a été dépréciée dans GitLab 16.4 et supprimée dans GitLab 17.0.{{< /history >}}
Prérequis :
admin_vulnerability.Pour modifier le statut d'une vulnérabilité depuis sa page de vulnérabilité :
Les détails du changement de statut, notamment qui a effectué le changement et quand, sont enregistrés dans le journal des actions de la vulnérabilité.
Vous pouvez créer un ticket GitLab pour suivre toute action entreprise pour résoudre ou atténuer une vulnérabilité. Pour créer un ticket GitLab pour une vulnérabilité :
Le ticket est créé dans le projet GitLab avec les informations du rapport de vulnérabilités.
Pour créer un ticket Jira, voir Créer un ticket Jira pour une vulnérabilité.
Vous pouvez lier une vulnérabilité à un ou plusieurs tickets GitLab ou Jira existants. Une seule fonctionnalité de liaison est disponible à la fois. L'ajout d'un lien permet de suivre le ticket qui résout ou atténue une vulnérabilité.
Prérequis :
Pour lier une vulnérabilité à des tickets GitLab existants :
#).Les tickets GitLab sélectionnés sont ajoutés à la section Éléments liés et le compteur de tickets liés est mis à jour.
Les tickets GitLab liés à une vulnérabilité sont affichés dans le rapport de vulnérabilités et sur la page de la vulnérabilité.
Soyez conscient des conditions suivantes entre une vulnérabilité et un ticket GitLab lié :
Prérequis :
Pour lier une vulnérabilité à des tickets Jira existants, ajoutez la ligne suivante à la description du ticket Jira :
/-/security/vulnerabilities/<id>
<id> correspond à tout identifiant de vulnérabilité. Vous pouvez ajouter plusieurs lignes avec des identifiants différents à une même description.
Les tickets Jira dont la description est appropriée sont ajoutés à la section Tickets Jira associés et le compteur de tickets liés est mis à jour.
Les tickets Jira liés à une vulnérabilité s'affichent uniquement sur la page de la vulnérabilité.
Soyez conscient des conditions suivantes entre une vulnérabilité et un ticket Jira lié :
Pour certaines vulnérabilités, une solution est déjà connue mais doit être implémentée manuellement. Le champ Solution de la page de vulnérabilité est fourni par l'outil de scan de sécurité qui a signalé le résultat de sécurité, ou saisi lors de la création manuelle d'une vulnérabilité. Les outils GitLab utilisent les informations de la base de données des avis GitLab.
De plus, certains outils peuvent inclure un correctif logiciel pour appliquer la solution suggérée. Dans ces cas, la page d'une vulnérabilité inclut une option Résoudre avec une requête de fusion.
Les scanners suivants sont pris en charge par cette fonctionnalité :
Analyse des dépendances. La création automatique de correctifs est uniquement disponible pour les projets Node.js gérés avec yarn. La création automatique de correctifs est uniquement prise en charge lorsque le mode FIPS est désactivé.
Pour résoudre une vulnérabilité, vous pouvez soit :
Pour résoudre la vulnérabilité avec une merge request :
Une merge request est créée, qui applique le correctif nécessaire pour résoudre la vulnérabilité. Traitez la merge request selon votre workflow standard.
Pour appliquer manuellement le correctif généré par GitLab pour une vulnérabilité :
git apply remediation.patch.[!note] La formation à la sécurité n'est pas accessible dans un environnement hors ligne, c'est-à-dire des ordinateurs isolés du réseau Internet public à des fins de sécurité. Plus précisément, le serveur GitLab doit pouvoir interroger les points de terminaison d'API de tout fournisseur de formation que vous choisissez d'activer. Certains fournisseurs de formation tiers peuvent vous demander de créer un compte gratuit. Créez un compte en vous rendant sur l'un des sites suivants : Secure Code Warrior, Kontra ou SecureFlag. GitLab n'envoie aucune information utilisateur à ces fournisseurs tiers ; GitLab envoie uniquement l'identifiant CWE ou OWASP et le nom du langage de l'extension de fichier.
La formation à la sécurité aide vos équipes de développement à apprendre à corriger les vulnérabilités. Les équipes de développement peuvent consulter la formation à la sécurité auprès de fournisseurs éducatifs sélectionnés, pertinente par rapport à la vulnérabilité détectée.
Pour activer la formation à la sécurité pour les vulnérabilités dans votre projet :
Chaque intégration soumet l'identifiant de vulnérabilité, par exemple CWE ou OWASP, ainsi que le langage au fournisseur de formation à la sécurité. Le lien résultant vers la formation du fournisseur est ce qui apparaît dans une vulnérabilité GitLab.
La page de vulnérabilité peut inclure un lien de formation pertinent pour la vulnérabilité détectée si la formation à la sécurité est activée. La disponibilité de la formation dépend du fait que le fournisseur de formation activé dispose d'un contenu correspondant à la vulnérabilité particulière. Le contenu de formation est demandé sur la base des identifiants de vulnérabilité. L'identifiant attribué à une vulnérabilité varie d'une vulnérabilité à l'autre et le contenu de formation disponible varie selon les fournisseurs. Certaines vulnérabilités n'affichent pas de contenu de formation. Les vulnérabilités avec un CWE sont les plus susceptibles de renvoyer un résultat de formation.
Pour afficher la formation à la sécurité pour une vulnérabilité :
{{< history >}}
dependency_paths. Désactivée par défaut. Désactivée par défaut.dependency_paths activé par défaut.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique.
Lors de la gestion des vulnérabilités trouvées dans les dépendances dans les détails de la vulnérabilité, sous Emplacement, vous pouvez afficher :
Si la vulnérabilité se produit dans une ou plusieurs dépendances transitives, connaître uniquement la dépendance directe peut ne pas être suffisant. Les dépendances transitives sont des dépendances indirectes qui ont une dépendance directe comme ancêtre.
Si des dépendances transitives existent, vous pouvez afficher les chemins vers toutes les dépendances, y compris les dépendances transitives qui contiennent la vulnérabilité.