Le projet Cartography, développé par la CNCF, est un outil Python qui ingère les actifs d’infrastructure et leurs relations dans une base de données graphe Neo4j. Il permet de répondre à des questions précises, comme identifier quelles identités accèdent à quels dépôts de données, ou déterminer quelles instances de calcul sont exposées sur Internet. Cet outil connecte des plateformes variées, incluant AWS, GCP, Azure, Kubernetes, Okta et CrowdStrike.

Une fois que Cartography a rempli le graphe Neo4j, il est possible d’exécuter des règles de sécurité. Par exemple, on peut interroger pour trouver les instances RDS dont le stockage n’est pas chiffré ou les instances EC2 exposées à l’Internet.

Quand l’intention de configuration ne suffit pas

Shopify a développé Overexposed, un scanner interne qui aborde le problème de l’exposition avec une méthode plus active. Son rôle est de localiser les Ingresses Kubernetes sur GKE et les services Cloud Run accessibles sans authentification. Initialement, le scanner se basait sur l’analyse des fichiers de configuration des dépôts, ce qui engendrait des faux positifs et des angles morts.

L’équipe de Shopify a tiré une leçon claire : « le dépôt montre l’intention ; le cluster montre ce qui est appliqué. » Cette distinction est cruciale. Une configuration qui semble correcte dans le code peut ne pas être celle qui est réellement appliquée sur le cluster.

La version actuelle d’Overexposed utilise l’Inventaire des actifs cloud de GCP et intègre un sondage HTTP anonyme. Au lieu de se fier uniquement aux métadonnées, le scanner envoie des requêtes HEAD et GET aux candidats pour vérifier concrètement ce qu’un acteur externe perçoit. Les résultats sont classés en six verdicts, allant de « exposé » à « inconclusif », en étant très strict sur la preuve.

Vers une approche hybride de la sécurité

La comparaison entre Cartography et Overexposed met en lumière la tension actuelle en cybersécurité : faut-il se contenter de lire les intentions ou faut-il interroger le réel ?

Cartography, en s’appuyant sur l’inventaire, est efficace pour couvrir de larges périmètres de services (IAM, S3, Lambda, etc.). Cependant, comme le souligne la comparaison avec Overexposed, il déduit l’exposition à partir des métadonnées de configuration, ce qui ne garantit pas la réalité de l’accès.

C’est là que l’approche active de Shopify intervient. Leur scanner ne se contente pas de lire le manifeste ; il teste l’accès. Il est très prudent sur les codes d’erreur : un statut 404 derrière un Ingress signifie que le proxy a répondu et que le chemin est manquant, tandis qu’un 403 n’est pas considéré comme une preuve de protection absolue.

Les solutions les plus robustes semblent donc combiner ces deux méthodes. Elles commencent par l’inventaire pour avoir une vue exhaustive des ressources, puis elles ajoutent une phase de vérification active, en se basant sur des listes blanches et en traitant les preuves incertaines comme des inconnues, plutôt que de présumer une sécurité par défaut. Pour les équipes développant des outils similaires, la recommandation est claire : utiliser l’inventaire comme référence principale, tout en conservant l’analyse de configuration en amont pour détecter les signaux précoces dans le cycle de développement.

Sources

• GitHub – cartography-cncf/cartography: Cartography is a Python tool that pulls infrastructure assets and their relationships into a Neo4j…, github.com
• Shopify Overexposed Scans GKE Ingresses and Cloud Run for Exposure, InfoQ, 2 novembre 2026

Crédits photo

• Image en une : Network Aisle Rear, par Robert.Harker, CC BY-SA 3.0, via Wikimedia Commons (recadrée)
• Image dans l’article : Network Aisle Front, par Robert.Harker, CC BY-SA 3.0, via Wikimedia Commons (recadrée)