Passer au contenu principal
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. 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 à 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 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 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 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.

​
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.

​
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.

​
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.

​
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.
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 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.

​
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.

​
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, 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.

​
Auto Scan

Auto Scan 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.
Les heures de planification s’affichent dans votre fuseau horaire local.
Auto Scan est disponible uniquement lorsque les automatisations sont activées pour votre organisation. Sa configuration nécessite à la fois l’autorisation Gérer les analyses de code et l’autorisation de gérer les automatisations.
Les Auto Scans sont incrémentielles : chaque exécution examine uniquement les commits ajoutés depuis la dernière analyse terminée. En cliquant sur Start scan, une analyse complète du périmètre du dépôt est lancée par défaut.

​
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.

​
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 : 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.

​
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 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 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 réutilisable, utilisez le mode interactif 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.