> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Swarm
> Détectez, triez et corrigez les vulnérabilités de sécurité dans l'ensemble de vos dépôts
Security Swarm est le produit de Devin dédié à l’analyse de sécurité et à la remédiation. Il élabore un modèle de menace adapté à votre code, examine et valide les vulnérabilités potentielles, puis vous aide à corriger les problèmes détectés via des pull requests. Il peut identifier des vulnérabilités telles que l’exécution de code à distance (RCE), l’injection SQL, la traversée de chemins, la falsification de requêtes côté serveur (SSRF), les contournements d’autorisation, les bogues de sécurité mémoire, les vulnérabilités de déni de service, et bien plus encore. Il peut même identifier des chaînes d’exploitation s’étendant sur plusieurs fichiers.
Security Swarm est une orchestration personnalisée de Devins que nous appelons [Agentic MapReduce](https://devin.ai/blog/agentic-mapreduce). Il répartit votre dépôt entre plusieurs Devins exécutés en parallèle, afin d’offrir une large couverture et une investigation approfondie tout en maîtrisant les coûts, ce qui en fait une solution rentable pour analyser de grandes bases de code. Nous avons également [évalué Security Swarm](https://devin.ai/blog/security-eval) à partir d’un ensemble de référence de vulnérabilités publiées issu de la GitHub Advisory Database.
Pour lancer une analyse :
* Votre organisation doit avoir accès au dépôt que vous souhaitez analyser.
* Vous devez être autorisé à utiliser les sessions Devin.
* Vous devez disposer de l’autorisation **Use code scans**.
* Pour configurer une planification Auto Scan, vous devez également disposer de **Manage code scans** et de l’autorisation de gérer les automatisations.
Si vous ne voyez pas **Security** dans la barre latérale ou si vous ne pouvez pas lancer une analyse, demandez à un administrateur de vérifier votre rôle. Consultez [Access and permissions](#access-and-permissions) pour plus de détails.
## Lancez votre première analyse
1. Ouvrez **Security** dans la barre latérale de gauche et cliquez sur **Démarrer l’analyse**.
2. Sous **Single repo**, choisissez un dépôt à analyser.
3. Assurez-vous que **Interactive mode** est activé.
4. Cliquez sur **Lancer l’analyse**.
5. Lorsque le [modèle de menace](#interactive-mode) proposé est prêt, examinez-le, puis cliquez soit sur **C'est bon, lancer l’analyse**, soit donnez votre retour.
6. À mesure que les constats apparaissent, examinez les éléments de preuve et [traitez les constats](#act-on-a-finding) qui nécessitent une attention particulière.
Pour des analyses reproductibles, créez un profil qui regroupe votre périmètre, votre modèle de menace, vos critères de gravité, vos étapes de validation et vos contraintes de remédiation.
## Examiner les problèmes détectés et agir
Ouvrez une analyse pour voir les constats. La page affiche une liste des constats à gauche, regroupés par gravité, et les détails du constat sélectionné à droite.
Les onglets de statut affichent un décompte en temps réel :
* **Open** — nécessite une attention.
* **Reviewed** — a été examiné et ne nécessite plus d’action.
* **Dismissed** — a été identifié comme faux positif ou doublon.
Pendant qu’une analyse est en cours, la page se met à jour automatiquement à mesure que les constats arrivent.
**Reviewed** est un statut de workflow, et non la confirmation qu’un correctif a été fusionné. Un constat peut être marqué Reviewed manuellement ou lorsqu’une analyse ultérieure détermine qu’il n’est plus présent.
### Ce que contient un constat
Un constat comprend :
* La **gravité, le statut, l’exploitabilité, le niveau de confiance et la catégorie**.
* Le **chemin du fichier et les extraits de code** concernés.
* Une **description** du problème et une **recommandation de remédiation**.
* Un **résultat de validation de l’environnement d’exécution**, des éléments probants et des artéfacts de validation.
* Les **pull requests** associées et leur état : ouverte, fusionnée ou fermée.
* Les **responsables du code** et des notes, le cas échéant.
Considérez un motif de code risqué comme un indice, et non comme la preuve d’une vulnérabilité. Vérifiez que le constat établit un chemin exploitable depuis une entrée contrôlée par un attaquant, tient compte des contrôles de validation et d’autorisation, et explique un impact concret sur la sécurité.
### Traiter une constat
Démarre une session Devin pour corriger le problème et ouvrir une pull request. La session et la pull request qui en résulte sont associées à la constat.
Envoie le contexte à une session de retour afin d’affiner le profil de scan pour les prochains scans. Par exemple, expliquez qu’un flux de données signalé est protégé par une passerelle interne afin que les prochains scans puissent tenir compte de ce contrôle.
Ajuste la gravité de la constat, avec un contexte facultatif pour Devin. Par exemple, réduisez la gravité lorsque l’exploitation nécessite un accès interne privilégié, et incluez cette contrainte comme contexte.
Marque la constat comme Open, Reviewed ou Dismissed. Gardez une constat Open tant qu’elle nécessite une action, marquez-la Reviewed après le triage, ou rejetez-la lorsqu’il s’agit d’un faux positif ou d’un doublon.
## Profils d’analyse
Un profil d’analyse définit le périmètre de l’analyse et fournit des indications pour chaque étape. Chaque analyse peut utiliser un seul profil. Pour évaluer un dépôt selon plusieurs profils d’attaquant ou catégories de menaces, exécutez des analyses distinctes avec différents profils.
Un modèle de menace spécifique est l’un des moyens les plus efficaces de maintenir une couverture cohérente d’une analyse à l’autre. Définissez l’attaquant, les ressources sensibles, les frontières de confiance, les points d’entrée importants et les exclusions explicites.
Gérez les profils dans l’onglet **Profiles** de la page Security.
### Créer un profil
Vous pouvez créer un profil de deux façons :
* **Générer avec Devin** — décrivez l’application, les menaces, le périmètre, les exclusions et les critères de gravité en langage naturel. Devin prépare une première version du profil pour vous.
* **Créer manuellement** — renseignez vous-même chaque champ du profil.
Générer avec Devin est un bon point de départ, mais vérifiez chaque champ généré avant d’utiliser le profil. Si vous laissez un champ d’instructions facultatif vide, le comportement intégré de Security Swarm s’appliquera à cette étape.
### Informations de base
* **Nom du profil** — nommez la surface de l’application ou la catégorie de menace, plutôt que l’équipe qui effectue l’analyse. Exemple : `Multi-tenant API authorization`.
* **Description** — résumez le périmètre du profil et son objectif de sécurité. Exemple : `Find authentication, authorization, and tenant-isolation vulnerabilities in the public API.`
Les exemples ci-dessous constituent ensemble un profil unique pour une API multi-tenant. Adaptez le périmètre, les commandes et les critères de sévérité à votre application.
### Modèle de menace
Décrivez l'attaquant, les actifs sensibles, les frontières de confiance, les principaux points d'entrée, ainsi que tout ce qui est explicitement hors périmètre. Ces indications orientent les règles que Devin génère avant le début de l'investigation.
```text theme={null}
Supposez un attaquant internet non authentifié ou un utilisateur authentifié dans un seul tenant.
Concentrez-vous sur les gestionnaires HTTP publics, les callbacks OAuth, les tokens d'API, les actions administratives
et les accès aux données appartenant au tenant. Considérez les scripts de développement internes et les outils
locaux uniquement comme hors périmètre. Priorisez les contournements d'authentification, les accès inter-tenants, les fuites de tokens,
les injections et les SSRF.
```
### Consignes d’investigation
Définissez comment Devin doit mener l’investigation d’un problème potentiel et quelles preuves il doit recueillir. Demandez-lui de tenir compte des mesures d’atténuation existantes et de distinguer les vulnérabilités exploitables des risques théoriques.
```text theme={null}
Trace untrusted input from the route through middleware and service layers to the
sensitive operation. Check authentication, authorization, tenant scoping, validation,
and escaping at every boundary. Identify the exact reachable path and cite the relevant
files and lines. Do not report a theoretical issue when an effective mitigation blocks
the path.
```
### Consignes de triage
Définissez comment Devin doit dédupliquer et prioriser les findings. Incluez vos critères de gravité afin que les résultats correspondent aux normes de votre organisation.
```text theme={null}
Regroupez les findings qui partagent la même cause racine. Considérez l'exécution de code à distance non authentifiée et l'accès en écriture cross-tenant comme critiques. Considérez l'accès en lecture cross-tenant et la divulgation de credentials comme élevés. Considérez les problèmes de disponibilité mono-utilisateur comme modérés, sauf s'ils peuvent affecter une infrastructure partagée. Étiquetez les recommandations de défense en profondeur comme faibles.
```
### Validation de l’environnement d’exécution
Activez la validation de l’environnement d’exécution lorsque Devin peut effectuer le build de l’application et la tester en toute sécurité. Expliquez comment démarrer l’application, créer des données de test, vous authentifier et illustrer le périmètre de sécurité attendu.
```text theme={null}
Utilisez la configuration de développement documentée du dépôt. Démarrez l'API et créez deux
tenants hors production avec un utilisateur de test dans chacun. Tentez la requête suspectée en tant qu'
utilisateur de l'autre tenant, puis vérifiez à la fois la réponse HTTP et les données persistées.
N'appelez pas les services de production et ne modifiez pas les données de production.
```
Une validation échouée n’invalide pas toujours un constat. Examinez le résultat de la validation et les artefacts afin de déterminer si une mesure d’atténuation efficace a bloqué l’exploit ou si la configuration de l’environnement a empêché Devin de mener le test à bien.
La validation d’exécution lance une session Devin distincte pour chaque constat. Consultez [Configurer la validation d’exécution](#configure-runtime-validation) pour obtenir des indications sur l’environnement.
### Rapport
Activez la génération de rapports lorsque vous avez besoin d'un artefact de synthèse après l'analyse. Précisez le public visé et les informations que le rapport doit mettre en avant.
```text theme={null}
Rédigez une synthèse exécutive à l'intention des responsables sécurité et ingénierie. Listez d'abord les constats critiques et élevés confirmés, suivis des constats non validés. Incluez les composants affectés, le statut de validation, le statut des pull requests et un plan de remédiation hiérarchisé par priorité.
```
### Consignes de remédiation
Précisez les contraintes que Devin doit respecter lorsque vous lui assignez un constat à corriger. Incluez les attentes en matière de tests, les exigences de compatibilité et les pratiques à éviter.
```text theme={null}
Privilégier la modification minimale sûre et préserver le comportement existant de l'API publique. Ajouter un
test de régression qui échoue avant le correctif et réussit après. Exécuter les commandes lint et test du package concerné.
Éviter les mises à niveau majeures de dépendances, sauf si la vulnérabilité ne peut pas être corrigée de manière sécurisée sans cela.
```
### Paramètres avancés
Ouvrez **Advanced** pour définir le périmètre des fichiers et les lots d'investigation :
* **Include globs** — limitez l'analyse aux fichiers correspondants. Par exemple, `apps/api/**` et `packages/auth/**`.
* **Exclude globs** — retirez les fichiers non pertinents du périmètre sélectionné. Par exemple, `**/generated/**`, `**/vendor/**` et `**/fixtures/**`.
* **Batch size** — définissez combien de fichiers présentant des signaux sont regroupés dans chaque lot d'investigation. Laissez cette valeur par défaut, sauf si vous ajustez délibérément le comportement de l'analyse. La plage acceptée est de 1 à 500 ; la valeur par défaut est 5.
Des exclusions trop larges peuvent masquer du code vulnérable ou supprimer le contexte nécessaire pour comprendre un flux de données. N'excluez que les fichiers dont vous êtes certain qu'ils ne sont pas pertinents pour ce profil.
### Profils d’organisation et d’entreprise
Les nouveaux profils sont limités à l’organisation. Les administrateurs Enterprise peuvent ensuite modifier la visibilité d’un profil en **Enterprise**, ce qui le rend disponible dans toute l’entreprise.
Les profils Enterprise ne peuvent être modifiés ou archivés que par les administrateurs Enterprise. Les autres utilisateurs ayant accès à Security peuvent les consulter et les utiliser, mais pas les modifier.
### Mode interactif
Lorsque **le mode interactif** est activé, Devin propose un modèle de menace, puis s’arrête avant l’investigation. La page d’analyse affiche les règles proposées et vous permet de :
* **Tout semble correct, lancer l’analyse** — acceptez le modèle de menace et lancez l’investigation.
* **Fournir un retour sur le modèle de menace** — indiquez ce qu’il faut ajouter, supprimer ou mettre en avant, puis consultez le modèle révisé.
Utilisez le mode interactif pour la première analyse d’un dépôt et chaque fois que sa surface de risque ou son profil évolue de manière significative. Une fois que le profil intègre les consignes approuvées, les analyses de routine peuvent s’exécuter sans cette pause.
### Configurer la validation de l’environnement d’exécution
La validation de l’environnement d’exécution ne s’exécute que si le profil sélectionné l’active et contient des instructions de validation. Donnez à Devin suffisamment d’informations pour build, exécuter, initialiser les données et authentifier l’application dans son sandbox.
Si le dépôt dispose d’une [configuration déclarative](/fr/onboard-devin/environment/blueprints), Devin peut réutiliser sa configuration de build et d’installation. Sinon, ajoutez les commandes de configuration requises aux instructions de validation du profil.
N’incluez pas directement d’identifiants de production ni de valeurs secrètes dans les instructions du profil. Utilisez des comptes de test hors production et des identifiants déjà fournis via la configuration d’environnement de votre organisation.
## Analyse à grande échelle
### Scanner plusieurs dépôts
Utilisez l’onglet **All repos** dans la boîte de dialogue New Scan pour mettre en file d’attente des scans pour toute une organisation :
1. Saisissez éventuellement un **filtre de nom de dépôt**.
2. Sélectionnez éventuellement un profil d’analyse.
3. Laissez **Skip already-scanned repos** activé pour exclure les dépôts déjà scannés avec le profil sélectionné.
4. Cliquez sur **Preview**.
5. Vérifiez les dépôts correspondants, désélectionnez ceux que vous ne souhaitez pas scanner, puis confirmez.
L’aperçu est une simulation. Si vous modifiez le filtre, le profil ou le paramètre d’exclusion, l’aperçu est invalidé et vous ne pouvez pas confirmer une liste périmée.
### Analyse automatique
L’analyse automatique analyse régulièrement les commits ajoutés depuis la dernière analyse terminée. Vous pouvez la configurer :
* Lors du lancement d’une analyse sur un dépôt unique, en sélectionnant une planification quotidienne, hebdomadaire, mensuelle ou personnalisée.
* À partir d’une analyse existante, en ajoutant, modifiant, désactivant ou lançant immédiatement sa planification.
L’analyse automatique repose sur une [automatisation](/fr/product-guides/automations). Sa configuration nécessite à la fois l’autorisation **Gérer les analyses de code** et l’autorisation de gérer les automatisations. Les heures de planification s’affichent dans votre fuseau horaire local.
### Analyser les nouveaux commits
Cliquez sur **Analyser les nouveaux commits** dans une analyse terminée pour examiner les commits ajoutés depuis le dernier commit déjà analysé. Auto Scan utilise le même fonctionnement incrémentiel, ce qui rend les analyses suivantes moins coûteuses que de réanalyser à chaque fois l’intégralité du périmètre du dépôt.
## Gérer et suivre les analyses
Selon l'analyse et son profil, l'en-tête de l'analyse peut inclure :
* **Rapports** — télécharger les rapports générés pour l'analyse.
* **Utilisation** — consulter les ACUs consommées, le nombre de sessions, la durée de l'analyse et les statistiques des pull requests.
* **Session** — ouvrir la session Devin principale qui a effectué l'analyse.
* **Exporter au format CSV** — exporter les résultats de l'analyse.
* **Archiver** ou **Désarchiver** — masquer l'analyse de la liste par défaut ou l'y rétablir.
* **Analyser les nouveaux commits** — lancer une analyse incrémentielle.
Les analyses s'exécutent sous forme de sessions Devin et consomment des [ACUs](/fr/admin/billing/usage).
### Tableau de bord Security
Une fois que l’organisation a effectué sa première analyse, la page Security affiche un tableau de bord à l’échelle de l’organisation sur les 7, 30 ou 90 derniers jours :
* **Statistiques des pull requests** — pull requests créées, ouvertes, fermées et fusionnées, ainsi que le taux de fusion.
* **Résultats au fil du temps** — constats regroupés par niveau de gravité sur la période sélectionnée.
## Accès et autorisations
L’accès à Security est contrôlé par les autorisations d’analyse de code dans l’éditeur de rôles :
| Autorisation | Ce que cela permet | Rôles par défaut |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| **Voir les analyses de code** | Voir les analyses, les profils, les constats et les sessions d’analyse associées. | Admin |
| **Utiliser les analyses de code** | Démarrer des analyses, créer des profils d’organisation, fournir un retour sur les constats, ajuster les constats, modifier le statut des constats et attribuer des constats à Devin. | Admin |
| **Gérer les analyses de code** | Archiver ou désarchiver des analyses et configurer les planifications d’Auto Scan. | Admin |
| **Gérer les analyses de code du compte** | Étendre des profils d’organisation au périmètre Enterprise et modifier ou archiver des profils Enterprise. | Admin Enterprise |
Démarrer des analyses, fournir un retour et attribuer des constats à Devin nécessitent également l’autorisation d’utiliser les sessions Devin. Auto Scan nécessite en outre l’autorisation de gérer les automatisations.
Par défaut, les membres ne reçoivent pas d’autorisations d’analyse de code. Les propriétaires disposent de toutes les autorisations, et les administrateurs peuvent accorder des autorisations aux membres via les [rôles personnalisés](/fr/enterprise/security-access/custom-roles).
## Comparez Security Swarm à un autre scanner
Pour que la comparaison soit pertinente, donnez aux deux scanners le même périmètre, le même modèle de menace, les mêmes critères de sévérité et les mêmes exigences de validation. Sinon, des différences de configuration risquent de masquer les écarts réels de capacité.
Utilisez des profils pour formaliser les critères de comparaison, le mode interactif pour confirmer le modèle de menace généré, et la validation de l’environnement d’exécution pour appliquer le même niveau de preuve aux résultats signalés.
## FAQ
Security Swarm analyse les vulnérabilités potentielles dans le contexte de votre dépôt, au lieu de signaler des motifs à risque de façon isolée. Devin suit les flux de données pertinents, vérifie les contrôles de validation et d’autorisation, et évalue si le problème a un impact concret sur la sécurité.
Chaque constat inclut un niveau de confiance et des éléments de preuve à l’appui. Examinez ces éléments avant d’agir, en particulier lorsqu’un constat n’a pas été validé en environnement d’exécution.
Vérifiez le code affecté, le point d’entrée, le flux de données, les mesures d’atténuation existantes, l’impact indiqué, le niveau de confiance et l’exploitabilité. Lorsque la validation en environnement d’exécution est activée, examinez également le résultat de la validation et les artefacts qui l’étayent.
Si les éléments de preuve omettent un contrôle ou avancent un impact non étayé, utilisez [Feedback](#act-on-a-finding) pour fournir le contexte manquant lors des prochains scans.
La validation en environnement d’exécution tente de reproduire un constat en effectuant le build puis en exécutant l’application dans un environnement isolé. Une validation réussie fournit des preuves plus solides de l’exploitabilité, tandis qu’une validation infructueuse peut mettre en évidence des hypothèses ou des limites d’environnement qui nécessitent un examen plus approfondi.
La validation en environnement d’exécution est facultative et nécessite des [consignes de validation](#configure-runtime-validation) suffisantes pour que Devin puisse builder, exécuter, initialiser et authentifier l’application en toute sécurité.
Security Swarm analyse différentes parties du dépôt en parallèle et combine les résultats dans une vue d’ensemble du dépôt. Cela lui permet d’identifier les relations entre les composants, par exemple lorsqu’un endpoint expose un identifiant nécessaire pour exploiter un autre endpoint.
Tout constat chaîné qui en découle doit néanmoins identifier les chemins de code pertinents et expliquer comment les différentes conditions se combinent pour produire un impact concret.
Security Swarm utilise une analyse agentique, de sorte que des scans distincts peuvent ne pas produire des constats ou une formulation identiques. Un périmètre ciblé, un modèle de menace explicite, des critères de gravité clairs et des consignes d’investigation spécifiques contribuent à maintenir une couverture cohérente.
Consignez ces exigences dans un [profil de scan](#scan-profiles) réutilisable, utilisez le [mode interactif](#interactive-mode) pour examiner le modèle de menace proposé, et fournissez un retour lorsqu’un résultat omet un contexte important.
Aucun scanner de sécurité ne peut garantir une couverture complète. Les résultats dépendent du périmètre sélectionné, des consignes du profil, du contexte du dépôt disponible et de la possibilité de valider les constats dans l’environnement configuré.
Exécutez des scans distincts pour différents modèles d’attaquant ou catégories de menaces, gardez les profils à jour à mesure que l’application évolue, et utilisez Security Swarm en complément de vos pratiques existantes de revue de sécurité et de testing.