doc-locale/fr-fr/user/application_security/get-started-security.md
Identifiez et remédiez aux vulnérabilités dans le code source de votre application. Intégrez les tests de sécurité dans le cycle de vie du développement logiciel en analysant automatiquement votre code pour détecter les problèmes de sécurité potentiels.
Vous pouvez analyser différents langages de programmation et frameworks, et détecter des vulnérabilités comme les injections SQL, le cross-site scripting (XSS) et les dépendances non sécurisées. Les résultats des analyses de sécurité sont affichés dans l'interface utilisateur GitLab, où vous pouvez les examiner et les traiter.
Ces fonctionnalités peuvent également être intégrées à d'autres fonctionnalités GitLab, comme les merge requests et les pipelines, pour garantir que la sécurité est une priorité tout au long du processus de développement.
<i class="fa-youtube-play" aria-hidden="true"></i> Pour une vue d'ensemble, voir Adopting GitLab application security
<i class="fa-youtube-play" aria-hidden="true"></i> View an interactive reading and how-to demo playlist
Ce processus fait partie d'un workflow plus large :
La détection des secrets analyse votre dépôt pour empêcher l'exposition de vos secrets. Elle fonctionne avec tous les langages de programmation.
L'analyse des dépendances examine les dépendances de votre application à la recherche de vulnérabilités connues. Elle fonctionne avec certains langages et gestionnaires de paquets.
Pour plus d'informations, consultez :
Si c'est la première fois que vous configurez l'analyse de sécurité GitLab, vous devriez commencer par un seul projet. Le projet doit :
Pour identifier les secrets divulgués et les paquets vulnérables dans le projet, créez une merge request qui active la détection des secrets et l'analyse des dépendances.
Cette merge request met à jour votre fichier .gitlab-ci.yml, afin que les analyses s'exécutent dans le cadre du pipeline CI/CD de votre projet.
Dans le cadre de cette merge request, vous pouvez modifier les paramètres pour adapter la structure ou la configuration de votre projet. Par exemple, vous pouvez exclure un répertoire de code tiers.
Une fois cette merge request fusionnée dans votre branche par défaut, le système crée un scan de référence. Cette analyse identifie les vulnérabilités qui existent déjà sur la branche par défaut. Ensuite, les merge requests mettront en évidence les nouveaux problèmes introduits.
Sans scan de référence, les merge requests affichent chaque vulnérabilité dans la branche, même si la vulnérabilité existe déjà sur la branche par défaut.
Pour plus d'informations, consultez :
Permettez à votre équipe de se familiariser avec la consultation des résultats de sécurité dans les merge requests et le rapport de vulnérabilités.
Établissez un workflow de triage des vulnérabilités. Envisagez de créer des labels et des tableaux des tickets pour faciliter la gestion des tickets créés à partir des vulnérabilités. Grâce aux tableaux des tickets, toutes les parties prenantes disposent d'une vue commune de tous les tickets et peuvent suivre la progression de la remédiation.
Surveillez les tendances du tableau de bord de sécurité pour évaluer le succès de la remédiation des vulnérabilités existantes et la prévention de l'introduction de nouvelles.
Pour plus d'informations, consultez :
Appliquez des jobs d'analyse de sécurité planifiés en utilisant une politique d'exécution de scan. Ces jobs planifiés s'exécutent indépendamment de toute autre analyse de sécurité que vous pourriez avoir définie dans un pipeline de framework de conformité ou dans le fichier .gitlab-ci.yml du projet.
Les analyses planifiées sont particulièrement utiles pour les projets ou les branches importantes avec une faible activité de développement et pour lesquels les analyses de pipeline sont peu fréquentes.
Pour plus d'informations, consultez :
Pour imposer les types d'analyses requis et garantir la séparation des responsabilités entre la sécurité et l'ingénierie, utilisez des politiques d'exécution de scan.
Pour limiter les nouvelles vulnérabilités fusionnées dans votre branche par défaut, créez une politique d'approbation des merge requests.
Une fois que vous êtes familiarisé avec le fonctionnement de l'analyse, vous pouvez choisir de :
Pour plus d'informations, consultez :
Au fil du temps, vous souhaitez vous assurer qu'aucune nouvelle vulnérabilité n'est introduite.
Pour plus d'informations, consultez :