Sécurité → Surface d'attaque liste toutes les voies d'accès au code de chaque projet : les routes HTTP, les webhooks, les consommateurs de files d'attente et les commandes en ligne de commande. L'équipe rouge les trouve en lisant le code (voir Équipe bleue et équipe rouge). L'audit de sécurité le lit en premier.
Comment la carte est créée
CoRoid cartographie chaque projet connecté en lisant sa branche par défaut, sans modèle AI. La cartographie se fait une fois par semaine et sur demande : Cartographier maintenant dans l'onglet, ou Cartographier la surface d'attaque dans le menu « Analyser maintenant » d'un projet sous l'onglet Aperçu. La cartographie est toujours activée. Le temps d'exécution compte comme des heures d'agent, comme tout autre travail.
La même lecture rédige le modèle de menace du projet de menace.
Exposition
Chaque point d'entrée a une exposition : les personnes pouvant y accéder.
| Exposition | Signifie |
|---|---|
| Internet | Toute personne peut y accéder |
| Utilisateurs connectés | Depuis l'extérieur, après connexion |
| Interne | Uniquement vos autres services |
| Administrateur uniquement | Uniquement les administrateurs |
| Non déployé | Dans le code, mais non exécuté |
| Non défini | Personne n'a encore indiqué de valeur. Traité comme accessible depuis Internet |
Le tableau indique également la vérification de connexion de chaque point d'entrée telle que présentée dans le code (connexion, clé API, jeton de service, signature de webhook, ou aucune détectée), ses résultats et la date de la dernière lecture lors de l'audit. Les filtres permettent de sélectionner, par exemple, les points d'entrée qui écrivent sans connexion ou ceux ajoutés cette semaine.
Les propriétaires et administrateurs définissent l'exposition, un point d'entrée à la fois ou plusieurs simultanément.
Suggestions issues de votre configuration de déploiement
Lorsque le dépôt d'un projet contient sa configuration de déploiement (Kubernetes Ingress, routes de passerelle API ou valeurs Helm dans leurs formats habituels), CoRoid détermine quels hôtes sont routés vers quel service. À partir de là, il suggère une exposition pour chaque point d'entrée non encore défini : Internet pour un service routé ne nécessitant pas de connexion (ou seulement une clé API ou une signature de webhook), Utilisateurs connectés pour un service nécessitant une connexion, et Interne pour un service sans route associée. Il lit les fichiers en tant que texte ; rien n'est rendu ni exécuté. Un propriétaire ou administrateur applique ou rejette la suggestion, et peut annuler ce qu'il a appliqué. Une suggestion ne modifie jamais une exposition définie par une personne, et une suggestion rejetée n'est pas proposée à nouveau.
Hôtes liste les emplacements où le projet s'exécute, selon la configuration, avec le fichier dans lequel chaque route a été trouvée.
Orienter l'audit
L'audit lit en premier les points d'entrée accessibles depuis Internet et non définis. Vous pouvez l'orienter davantage pour chaque point d'entrée :
- Auditer en premier: lire avant tout le reste ;
- Normal;
- Hors périmètre: non lu, avec une raison que vous indiquez.
Modifications de la surface liste les points d'entrée ajoutés ou supprimés lors de chaque cartographie. Les décisions concernant un point d'entrée ayant disparu du code sont conservées, au cas où il reviendrait.
La protection sur les nouveaux points d'entrée
La protection de l'équipe bleue vérifie chaque ajout de point d'entrée par pull request sans vérification de connexion. Réglez chaque cas dans l'onglet : indiquez qui peut y accéder, ou placez-le hors périmètre en donnant une raison.
Son réglage se trouve dans Nouveaux points d'entrée sous Sécurité → Paramètres, pour l'organisation ou chaque projet :
| Mode | Un pull request ajoute un point d'entrée non résolu |
|---|---|
| Désactivé | N'est pas vérifié |
| Signaler | Est signalé ; la vérification CoRoid Security reste neutre |
| Bloquer | Fait échouer la vérification CoRoid Security jusqu'à ce que chaque cas soit résolu |
La fonctionnalité Bloquer est disponible une fois que CoRoid l'aura activée après sa vérification de prêt ; jusqu'alors, le réglage indique Bloquer, non disponible ici, et la protection le signale.
Ses règles :
- Un pull request ajoute un point d'entrée sans vérification de connexion;
- Traiter « Non défini » comme accessible depuis Internet;
- Suggérer l'exposition à partir de la configuration de déploiement.
Les demandes de fusion Sur l'onglet, chaque pull request vérifié est listé : validé, signalé, bloqué en attente de résolution ou non vérifié. Un pull request trop volumineux pour être vérifié dans le délai imparti affiche Non vérifié : trop volumineux, jamais comme validé. Un fichier modifié que l'analyse ne peut pas lire est considéré comme neutre dans la catégorie Signaler et échoue dans la catégorie Bloquer. Les Propriétaires et les administrateurs peuvent relancer la vérification d'un pull request depuis cet endroit (Relancer la vérification), par exemple après avoir défini ses points d'entrée, plutôt que de le relancer dans GitHub.