Falco pour les MSP : détection runtime, des pipelines CI aux flottes Kubernetes

Les flottes Kubernetes managées et les pipelines CI qui y déploient du code constituent deux surfaces d'attaque distinctes, et les MSP ont de plus en plus besoin d'un outil pour chacune. Ce guide couvre Falco, un moteur runtime gradué par la CNCF qui transforme un comportement suspect de conteneur en une pipeline d'alertes calibrée, et zizmor, un analyseur statique qui repère les configurations GitHub Actions risquées avant même qu'un workflow ne s'exécute.

Ce qu'est Falco, et ce qu'il détecte

Falco a été créé par Sysdig et est aujourd'hui un projet gradué de la Cloud Native Computing Foundation. Il observe les appels système via une surveillance basée sur eBPF et signale toute activité de processus, de fichier ou de réseau qui paraît anormale à l'intérieur d'un conteneur en cours d'exécution. Cela en fait un moyen de repérer une intrusion en cours, plutôt que de la découvrir seulement lors d'une analyse post-incident.

Sur quoi alerter en priorité

Tous les signaux que Falco peut générer ne méritent pas de réveiller l'astreinte. Pour les MSP qui gèrent de nombreux tenants, les règles les plus importantes combinent un faible taux de faux positifs à un coût élevé en cas d'oubli : un shell interactif ouvert dans un conteneur applicatif qui ne devrait jamais en avoir besoin, un processus qui lit depuis un chemin de montage sensible comme le système de fichiers de l'hôte, et des changements de privilèges ou de capabilities Linux dans un pod en cours d'exécution. Ces trois cas couvrent la plupart des situations où quelque chose d'actif est réellement en train de se produire.

Router les alertes pour qu'elles soient traitées

Un outil de détection n'aide que si l'alerte atteint quelqu'un capable d'agir. Les événements Falco devraient porter assez de contexte — cluster, namespace, tenant et identité du pod — pour être routés directement vers l'outil d'astreinte ou d'ITSM du MSP, avec une étape de confinement documentée avant la fermeture de toute alerte. Calibrer les règles selon la ligne de base de chaque client évite la lassitude face aux alertes : un shell normal dans un namespace de runner CI ne l'est pas dans un pod web exposé aux clients.

Où s'arrête Falco

Falco est une couche de détection, pas un système de réponse. Il n'isole pas une charge de travail, ne revient pas en arrière sur un déploiement et ne fait pas tourner les identifiants tout seul ; ces étapes nécessitent toujours un playbook et un répondant humain ou automatisé derrière l'alerte. Considérez-le comme le capteur, pas comme l'ensemble du programme de sécurité.

Si vous avez besoin d'une aide extérieure pour construire ce playbook, ou d'une preuve d'un processus de détection et réponse testé pour les audits NIS2, DORA ou GDPR, vous pouvez vous tourner vers les services de cybersécurité d'Altovar, qui couvrent les tests d'intrusion, l'évaluation des vulnérabilités et la réponse aux incidents.

Un complément côté CI : zizmor pour GitHub Actions

Falco ne voit une charge de travail qu'une fois qu'elle est déjà en cours d'exécution. zizmor, un analyseur statique écrit en Rust, lit les fichiers YAML de GitHub Actions sans les exécuter, à la recherche de problèmes comme des actions tierces non épinglées, des permissions trop larges et des schémas pouvant mener à un empoisonnement de cache. Il peut produire des résultats au format SARIF, ce qui fait apparaître les constats directement dans l'onglet code scanning de GitHub plutôt que dans un tableau de bord séparé.

La version actuelle de zizmor, v1.30.1, fait suite aux corrections de v1.30.0 pour la correspondance des pins d'actions et un plantage du parseur sur des expressions de workflow profondément imbriquées. Côté runtime, Falco 0.45.0 a atteint sa version stable finale le 21 septembre 2026 après un cycle de release candidate ; les équipes encore sur la précédente candidate 0.45.0-rc4 devraient passer à la version stable plutôt que de rester sur une release candidate en production.

Que faire

• Activez d'abord les règles par défaut de Falco pour les shells interactifs, les lectures de montages sensibles et les changements de privilèges : ce sont les signaux les plus clairs.
• Associez à chaque alerte le cluster, le namespace, le tenant et l'identité du pod, et routez-la vers l'outil d'astreinte ou d'ITSM déjà utilisé par l'équipe.
• Exécutez zizmor sur chaque pull request qui touche un fichier de workflow, et faites échouer le contrôle en cas de nouveau constat de gravité élevée.
• Épinglez les actions tierces à un hash SHA et limitez permissions: à ce dont chaque job a réellement besoin.
• Déployez Falco sur les clusters de production d'abord avec des règles d'alerte seule, puis resserrez vers un comportement de blocage une fois la ligne de base comprise.
• Envoyez la sortie des deux outils vers la même pipeline d'alertes que celle utilisée pour les autres signaux de sécurité, afin que rien ne se perde dans un tableau de bord séparé.

Sources : Falco sur GitHub, documentation de Falco, notes de version de Falco 0.45.0, documentation de zizmor.