~10 minutes
En mai 2026, Falco s’impose plus que jamais comme la brique runtime qu’aucun scanner statique ne peut remplacer. Avec Falco 0.43.1, le Falco Operator 0.2.0 désormais production-ready et le tournant modern eBPF, le projet CNCF franchit un palier. Reste à savoir comment on l’intègre, proprement, dans une chaîne DevSecOps déjà chargée
Pourquoi parler runtime, et pourquoi maintenant
On a vu dans le post sur Trivy cette question : « si je scanne mes images, mes IaC et mes dépendances, qu’est-ce qui me manque encore ? ». La réponse tient en un mot : le runtime.
Un scanner , comme Trivy, Grype, Snyk , s’arrête au moment où le pod démarre. Tout ce qui se passe ensuite (exploitation d’une CVE découverte la veille, escalade via un binaire setuid, exfiltration via curl, container escape, cryptominage discret) est invisible pour lui. C’est le dernier kilomètre de la défense en profondeur, et c’est précisément le terrain de Falco.
Un scanner vous dit ce que votre image contient. Falco vous dit ce qu’elle fait. Les deux sont nécessaires, aucun ne remplace l’autre.
L’incident Aqua / Trivy de mars 2026, que j’ai détaillé dans l’article Trivy compromis : quand le scanner de vulnérabilités devient la vulnérabilité, illustre bien le sujet : un workflow GitHub Actions vulnérable a été détourné par un bot autonome. Aucun scanner statique ne pouvait voir l’attaque pendant qu’elle se déroulait. Un capteur runtime, oui.
Falco en 2026 : où en est le projet
Falco est en projet gradué CNCF depuis février 2024, maintenu principalement par Sysdig et une communauté très active. La cadence des releases reste soutenue, et les six derniers mois ont apporté plusieurs changements structurants.
Les versions à connaître en mai 2026 :
- Falco 0.43.1 (avril 2026) : version stable courante, consolidation de la 0.43.0.
- Falco 0.43.0 (28 janvier 2026) : release de stabilisation, ruleset par défaut v5.0, nouveau couple libs
0.23.x/ driver9.1.0. - Falco 0.42.0 (octobre 2025) : capacité de capture
.scapnative, support mimalloc, champs statiques configurables. - Falco Operator 0.2.0 (23 mars 2026) : première version production-ready de l’opérateur Kubernetes officiel, après la technical preview livrée avec Falco 0.41.
- Rotation de la clé GPG des packages DEB/RPM en janvier 2026 (nouvelle empreinte 4096 bits) : point d’attention pour les pipelines d’installation automatisés.
Architecture, expliquée sans une ligne de YAML
Plutôt que de vous noyer sous des fichiers de configuration, je préfère décrire ce qui se passe réellement dans un cluster où Falco tourne.
Le flux de bout en bout
flowchart LR
K[Kernel Linux] -->|syscalls via modern eBPF| L[Falco libs]
A[K8s API server] -->|audit events| P[Plugins Falco]
L --> E[Engine de règles]
P --> E
E -->|alertes JSON| O[Outputs Falco]
O --> S[Falcosidekick]
S --> Sl[Slack / Teams]
S --> Pd[PagerDuty / OpsGenie]
S --> Si[SIEM / Elastic / Loki]
S --> Pr[Prometheus / Grafana]
Trois couches, trois rôles distincts :
- Le capteur kernel. Le driver modern eBPF capture les appels système pertinents (exécution de processus, ouvertures de fichiers, connexions réseau, mounts, namespaces). C’est rapide, sans recompilation, et ça consomme typiquement quelques pourcents de CPU sur un nœud chargé.
- Le moteur de règles. Les règles Falco sont écrites en YAML déclaratif, structurées en macros (conditions réutilisables), lists (valeurs nommées) et rules (la détection elle-même, avec un niveau de priorité). Le ruleset officiel v5.0 couvre déjà l’essentiel ; les règles custom viennent ajuster le contexte métier.
- Les outputs. Falco peut écrire en stdout, syslog, fichier ou HTTP. Mais en 2026, personne ne consomme directement ces outputs : tout passe par Falcosidekick, qui agit comme un routeur d’alertes vers une cinquantaine de destinations possibles.
Et le Falco Operator ?
Avant la 0.2.0, déployer Falco proprement supposait de jongler avec un Helm chart, une configuration séparée pour Falcosidekick, un autre pour les rules à charger, et une gestion manuelle des mises à jour. L’opérateur consolide tout cela derrière des Custom Resources (FalcoInstance, FalcoRules…). On déclare l’état souhaité, l’opérateur réconcilie. C’est le mode de déploiement que je recommande aujourd’hui pour tout nouveau cluster.
Ce que Falco détecte vraiment
Je préfère illustrer Falco par les attaques qu’il rend visibles, plutôt que par la liste exhaustive de ses règles.
1. Cryptominage opportuniste
Un attaquant compromet une image vulnérable, déploie un mineur Monero (xmrig et consorts), et fait tourner discrètement vos nœuds pour son profit. Le scanner statique a vu une CVE, mais pas l’exploitation. Falco, lui, voit le binaire suspect démarrer dans un conteneur, la connexion sortante vers un pool stratum+tcp, et lève une alerte critique en quelques secondes.
2. Exfiltration de credentials
Un pod compromis tente de lire /etc/shadow, ou un fichier .kube/config, ou une clé SSH dans /root/.ssh. Aucun scanner ne voit cette lecture. Falco, qui surveille les ouvertures de fichiers sensibles dans les conteneurs, déclenche immédiatement.
3. Évasion de conteneur
Tentative d’accès au socket Docker (/var/run/docker.sock monté par négligence), exécution de nsenter ou chroot /host, accès à /proc/1/root… ces patterns d’évasion sont parfaitement détectables au niveau syscall. Falco les couvre nativement dans le ruleset par défaut.
4. Détection de supply chain à l’exécution
C’est l’usage qui monte fort en 2026, dans le sillage de l’incident Trivy. Falco détecte, à l’exécution, des comportements anormaux d’outils CI/CD : un runner GitHub qui crée soudain un nouveau Personal Access Token, un binaire de release qui contacte une IP inhabituelle, un workflow qui exécute du code venu d’une PR non triée. C’est précisément ce que la communauté Falco a documenté dès mars 2025 sous le nom de Falco Actions, et qui prend tout son sens après ce qu’a vécu Aqua.
Intégrer Falco dans une chaîne DevSecOps cohérente
Falco ne vit pas seul. Voici comment l’articuler avec les autres briques que vous pourrez trouver sur ce blog ou dans votre stack.
Avec un scanner statique (Trivy, Grype)
Le scanner refuse les images vulnérables avant déploiement. Falco surveille ce que les images déployées font réellement. Aucun recouvrement, complémentarité totale. Le Trivy Operator et le Falco Operator peuvent même cohabiter dans le même namespace security-system et alimenter les mêmes dashboards Grafana.
Avec un contrôleur d’admission (Kyverno, Gatekeeper)
Le contrôleur d’admission applique des politiques avant le déploiement (pas de privileged, pas de hostPath, image signée, etc.). Falco prend le relais après le déploiement, sur le comportement réel. Là encore, deux étapes distinctes du cycle.
Avec Falcosidekick et Prometheus
Falcosidekick est, à mes yeux, non-négociable en production. Il transforme le flux d’alertes brut en routage intelligent : Slack pour les équipes ops, PagerDuty pour les critiques hors heures ouvrées, Elasticsearch / Loki pour la corrélation, Prometheus pour les métriques. Sans lui, on bricole. Avec lui, on industrialise.
Côté observabilité, Falco expose nativement des métriques Prometheus (events totaux par règle, par priorité, par namespace, drops syscalls, santé du driver). Un dashboard Grafana standard suffit pour suivre la santé du capteur et la pression d’alertes.
Avec un SIEM ou un SOAR
Pour les organisations matures, Falcosidekick alimente directement Splunk, Sentinel, Chronicle ou Elastic SIEM. Les alertes Falco s’enrichissent alors du contexte business (criticité du namespace, propriétaire du workload, environnement) et deviennent actionnables par une équipe SOC.
Bonnes pratiques 2026
Voici les recommendations que nous pouvons appliquer aujourd’hui, en 2026, pour tirer le meilleur de Falco :
- Partir directement sur modern eBPF. Pas la peine de s’embêter avec le legacy probe ou le module kernel, sauf contrainte forte (kernel < 5.8).
- Déployer via le Falco Operator 0.2.0 plutôt que via un Helm chart manuel, sauf si vous avez déjà une stack GitOps mature autour du chart.
- Activer Falcosidekick dès le jour 1. Même si vous démarrez avec un seul output Slack, l’architecture est saine et évolutive.
- Garder le ruleset officiel v5.0 comme base, et ajouter les règles custom dans un fichier séparé (
rules.d/);surtout, ne pas modifier les règles upstream, vous regretterez à la prochaine mise à jour. - Documenter chaque exception et chaque whitelist, exactement comme pour un
.trivyignore: règle, justification métier, date d’ajout, date de revue. Les exceptions non documentées deviennent toujours des dettes invisibles. - Mesurer le bruit avant de croire en l’outil. Une installation Falco par défaut sur un cluster bavard peut générer des centaines d’événements par heure. Avant de brancher PagerDuty, passer une à deux semaines à calibrer.
- Vérifier la signature des packages depuis la rotation GPG de janvier 2026, et pinner les images Falco par digest SHA256 dans vos manifestes , la même hygiène supply chain que pour Trivy.
- Mettre Falco lui-même sous surveillance. Une métrique Prometheus
up{job="falco"}qui tombe à zéro est une alerte critique : si le capteur runtime est à terre, vous êtes aveugle.
Limites et angles morts à connaître
Savoir ce que Falco ne fait pas, c’est aussi important que savoir ce qu’il fait.
- Falco observe, il ne bloque pas. Pour de l’enforcement runtime, il faut regarder du côté de Tetragon, des LSM (AppArmor, SELinux) ou de Sysdig Secure. Falco déclenche une alerte ; ce sont vos pipelines de réponse qui décident d’agir.
- Le bruit est réel. Les règles par défaut sont volontairement larges. Sans tuning, on noie les vraies alertes. C’est le principal motif d’abandon rencontrer.
- Pas de visibilité Windows ni macOS côté production. Falco est conçu pour Linux. Les workloads Windows sur Kubernetes sont hors périmètre.
- Coût opérationnel non nul. Un opérateur Falco proprement géré demande quelqu’un qui comprend les règles, sait lire un événement et calibrer les exceptions. Ce n’est pas du « install and forget ».
- Comme tout outil tiers, Falco fait partie de votre supply chain. Mêmes précautions que pour Trivy : signature, pinning par digest, miroir interne des plugins si la dépendance au registry public est un risque.