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. 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.
Prérequis
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.
Ouvrez Security dans la barre latérale de gauche et cliquez sur Démarrer l’analyse.
Sous Single repo, choisissez un dépôt à analyser.
Assurez-vous que Interactive mode est activé.
Cliquez sur Lancer l’analyse.
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.
À 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.
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.
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é.
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.
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.
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.
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.
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.
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 administrativeset les accès aux données appartenant au tenant. Considérez les scripts de développement internes et les outilslocaux 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.
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.
Trace untrusted input from the route through middleware and service layers to thesensitive operation. Check authentication, authorization, tenant scoping, validation,and escaping at every boundary. Identify the exact reachable path and cite the relevantfiles and lines. Do not report a theoretical issue when an effective mitigation blocksthe path.
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.
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.
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.
Utilisez la configuration de développement documentée du dépôt. Démarrez l'API et créez deuxtenants 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 pour obtenir des indications sur l’environnement.
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.
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é.
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.
Privilégier la modification minimale sûre et préserver le comportement existant de l'API publique. Ajouter untest 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.
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.
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.
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.
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 :
Saisissez éventuellement un filtre de nom de dépôt.
Sélectionnez éventuellement un profil d’analyse.
Laissez Skip already-scanned repos activé pour exclure les dépôts déjà scannés avec le profil sélectionné.
Cliquez sur Preview.
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.
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. 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.
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.
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.
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.
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.
Comment Security Swarm réduit-il les faux positifs ?
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.
Quels éléments de preuve dois-je examiner dans un constat ?
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.
Qu’apporte la validation en environnement d’exécution ?
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é.
Comment Security Swarm détecte-t-il les vulnérabilités réparties sur plusieurs fichiers ?
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.
Pourquoi les résultats peuvent-ils varier d’un scan à l’autre ?
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.
Un scan terminé signifie-t-il que le dépôt ne présente aucune autre vulnérabilité ?
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.
