Falco : Detection Runtime Cloud-Native (CNCF) 2026

Falco est le moteur de detection runtime cloud-native de reference, projet CNCF graduated (graduation prononcee en fevrier 2024) qui observe en temps reel les syscalls Linux via une sonde eBPF moderne ou un module noyau, ainsi que les audit logs Kubernetes, pour declencher des alertes lorsqu'un comportement suspect correspond a une regle declarative en YAML. Cree initialement par Sysdig Inc. en 2016 puis donne a la Cloud Native Computing Foundation en octobre 2018, Falco est devenu en huit ans la brique standard de runtime threat detection deployee dans les architectures Kubernetes de production : il instrumente plus de 120 syscalls sensibles, embarque un langage de regles compose de conditions booleennes sur des champs typees (proc.name, fd.name, k8s.pod.label, container.image) et expose les alertes via stdout, syslog, fichier, gRPC ou les 30+ destinations de Falcosidekick (Slack, PagerDuty, Elastic, Loki, OpenSearch, AWS Lambda, Pub/Sub). La version stable courante est Falco 0.41.0 (avril 2026), distribuee sous licence Apache 2.0, avec un driver eBPF moderne (CO-RE) qui supprime la dependance aux headers noyau et permet le deploiement immutable sur les distributions minimales (Bottlerocket, Talos Linux, Flatcar). Falco occupe une niche distincte de Wazuh ou Sentinel : ce n'est ni un SIEM, ni un EDR, mais un detecteur runtime pur dont la valeur reside dans la finesse d'observation kernel et la capacite a couvrir des scenarios container escape, cryptomining, reverse shell ou exec dans un pod sensible que les outils superieurs (CSPM, KSPM, SIEM) ne voient pas.

Definition technique de Falco

Falco est defini officiellement par la CNCF comme le moteur de detection des menaces runtime cloud-native. Il observe les evenements de bas niveau du noyau Linux (syscalls), les enrichit avec le contexte container et Kubernetes (label de pod, namespace, image, sa-token), puis les evalue contre un ensemble de regles declaratives YAML pour generer des alertes. La version stable est Falco 0.41.0 publiee en avril 2026 ; le code source est heberge sur github.com/falcosecurity/falco et la documentation officielle reside sur falco.org. Falco se distingue d'un EDR par son perimetre exclusivement Linux runtime (pas de Windows, pas de macOS) et d'un SIEM par l'absence de stockage long terme ou d'interface d'investigation : il agit comme un capteur temps reel dont la sortie est consommee par un SIEM tiers (Wazuh, Microsoft Sentinel, Splunk, Elastic Security, Sumo Logic) ou par une plateforme XDR. Le projet repose sur trois sous-projets ecosysteme : libs (libsinsp et libscap, le moteur de capture), falcoctl (gestion des plugins et rulesets) et falcosidekick (routeur d'alertes multi-destinations).

Histoire et trajectoire CNCF de Falco

Falco a ete ecrit en 2016 par Loris Degioanni, fondateur et CTO de Sysdig Inc., comme excroissance open source de la suite commerciale Sysdig Secure. La premiere release publique 0.1.0 date d'octobre 2016. En octobre 2018, Sysdig a donne le projet a la Cloud Native Computing Foundation au niveau Sandbox lors de la KubeCon Seattle. La promotion au niveau Incubating est intervenue en janvier 2020 apres audit du Technical Oversight Committee et des contributions externes significatives (Apple, GitHub, Frame.io, Booz Allen Hamilton). La graduation CNCF a ete prononcee le 29 fevrier 2024, faisant de Falco le 27e projet gradue, aux cotes de Kubernetes, Prometheus, Envoy, Istio, Argo, Cilium et Helm. La graduation suppose un audit de securite externe (realise par Trail of Bits, rapport publie en 2021), une diversite de mainteneurs (au moins trois entreprises), une trajectoire de production pluriannuelle et une CI/CD complete. Au 1er trimestre 2026, le projet compte plus de 7 800 etoiles GitHub, 280 contributeurs actifs et un cycle de release majeur trimestriel. Sysdig reste le plus gros contributeur mais ne controle pas la roadmap, partagee avec IBM, Red Hat (OpenShift), AWS, Microsoft (AKS), Apple et Booking.com.

Architecture technique de Falco

L'architecture Falco se compose de quatre couches : driver de capture, moteur libsinsp, engine de regles et outputs. Le schema ci-dessous illustre le flux d'evenements depuis le kernel jusqu'au routeur Falcosidekick.

+----------------------+      +-----------------------+      +-----------------------+
|   Linux Kernel       |      |   Falco Userspace     |      |   Falco Engine        |
|   syscalls           |─►►►─|   libsinsp / libscap  |─►►►─|   YAML rule eval      |
|   modern eBPF        |      |   parsing + enrich    |      |   alert generation    |
+----------------------+      +-----------------------+      +-----------------------+
                                                                       |
              +----------------------+      +-----------------------+  |
              |   Kubernetes API     |─►►►─|   K8s audit plugin    |◄──+
              |   audit log webhook  |      |   (audit-events.yaml) |
              +----------------------+      +-----------------------+
                                                                       |
                                                                       v
                                                          +-----------------------+
                                                          |   Outputs             |
                                                          |   stdout / syslog     |
                                                          |   gRPC / file / http  |
                                                          +-----------------------+
                                                                       |
                                                                       v
                                                          +-----------------------+
                                                          |   Falcosidekick       |
                                                          |   30+ destinations    |
                                                          +-----------------------+

Le driver de capture est le composant kernel-side qui intercepte les syscalls et les copie dans un ring buffer mmap. Trois implementations coexistent : module noyau classique (falco.ko, charge via insmod), eBPF probe legacy (compilation BCC requise sur la cible) et eBPF moderne CO-RE (Compile Once, Run Everywhere) qui exploite BTF et le verifier kernel 5.8+ pour s'executer sur n'importe quelle distribution sans dependance aux headers. Le driver moderne eBPF est le mode recommande depuis Falco 0.36 et le seul supporte sur les distributions immutables.

Le moteur libsinsp est ecrit en C++17. Il deserialise les events bruts du ring buffer, normalise les champs (PID, comm, exe, container ID, K8s pod, namespace), corrole avec les metadonnees CRI (containerd, CRI-O), et expose une API filtrable proche de tcpdump (proc.name=cat and fd.name startswith /etc/shadow). Cette filtrabilite est la fondation du langage de regles.

L'engine compile les regles YAML en arbres de syntaxe abstraite, optimise les conditions communes via macros et lists, puis evalue chaque event avec une logique de short-circuit. Sur du materiel x86_64 moderne, l'overhead se mesure en 1 a 4% de CPU sur un node Kubernetes charge.

Falco Rules Language : syntaxe et semantique

Le langage de regles Falco est un DSL declaratif YAML conçu pour exprimer des invariants comportementaux. Une regle se compose de cinq champs principaux : rule (nom unique), desc (description humaine), condition (expression booleenne sur les champs sinsp), output (template Go-style avec interpolation) et priority (Emergency a Debug). Les regles sont organisees en fichiers (falco_rules.yaml, k8s_audit_rules.yaml, application_rules.yaml) et reutilisent des macros et lists definies en debut de fichier.

- list: shell_binaries
  items: [bash, sh, ksh, zsh, dash, csh, tcsh, fish]

- macro: container
  condition: container.id != host

- rule: Terminal shell in container
  desc: Detecte un shell interactif lance dans un container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and not container_entrypoint
  output: >
    Shell interactif dans container
    (user=%user.name container=%container.id image=%container.image.repository
    cmd=%proc.cmdline pid=%proc.pid)
  priority: NOTICE
  tags: [container, shell, mitre_execution, T1059]

Les champs disponibles couvrent les processus (proc.*), les fichiers (fd.*), les utilisateurs (user.*), les containers (container.*), les pods Kubernetes (k8s.pod.*, k8s.ns.*), les events kernel (evt.*) et les requetes K8s audit (ka.*). La liste exhaustive depasse 250 champs documentes.

Engine et cycle d'evaluation des evenements

Le cycle d'evaluation Falco suit cinq etapes deterministes : capture (driver kernel ecrit dans ring buffer), parse (libsinsp deserialize et enrichit avec metadata container/K8s), filter (event triees par type pertinent), evaluate (regles testees sequentiellement avec court-circuit), emit (alerte envoyee aux outputs). Chaque event syscall passe par les regles dont la condition mentionne le type d'event correspondant ; les regles sont compilees une fois au demarrage et reutilisent une cache d'AST. Sur un node 32 vCPU avec 5 000 syscalls/s par container et 25 containers, Falco evalue typiquement 120 000 events/s avec une latence p99 sub-milliseconde et une RSS de 200-300 MB.

Falco supporte aussi un mode K8s audit qui consomme directement les audit logs Kubernetes via webhook ou via le plugin k8saudit (lit un fichier d'audit ou s'abonne en streaming). Dans ce mode, les regles utilisent les champs ka.verb, ka.target.resource, ka.req.* pour detecter des actions API comme la creation d'un pod privilegie, l'exec dans un pod kube-system ou la modification d'un ClusterRoleBinding sensible.

Sources de donnees : kernel, K8s audit, plugins

Falco consomme trois grandes familles de sources de donnees grace a son architecture de plugins introduite en version 0.31 (decembre 2021).

Source 1 : kernel events Linux. C'est la source historique. Elle couvre les syscalls open/openat, execve, connect, accept, mount, unmount, chmod, chown, ptrace, kill, et les events kernel synthetiques (process tree, file descriptor lifecycle). Cette source necessite un driver (kernel module ou eBPF) et fonctionne uniquement sur Linux.

Source 2 : Kubernetes audit logs. Consommee via le plugin k8saudit, cette source ingere les events JSON de l'API server selon la policy d'audit configuree. Elle ne necessite aucun driver kernel et peut tourner en pod isole. Combinee avec la source 1, elle offre une couverture defense-en-profondeur : kernel pour ce qui se passe DANS un container, audit pour ce qui est demande A l'API Kubernetes.

Source 3 : plugins externes. Le framework de plugins permet d'ingerer n'importe quelle source structuree : AWS CloudTrail, Okta system log, GitHub audit log, Docker daemon events, JSON arbitraire. Chaque plugin expose un schema de champs reutilisable dans les conditions de regles.

Plugins Falco : ecosysteme d'extensions

L'ecosysteme de plugins Falco compte une vingtaine d'extensions officielles ou communautaires distribuees via github.com/falcosecurity/plugins et installables via falcoctl. Les plugins suivent une architecture C ABI ou Go via cgo.

Le binaire falcoctl gere le cycle de vie : installation, mise a jour automatique des regles communautaires, signature et verification cosign des artefacts OCI publies sur ghcr.io.

Outputs : stdout, syslog, fichier, gRPC, HTTP

Falco expose nativement six canaux de sortie pour les alertes generees. Chaque canal est independant et peut etre active ou desactive dans falco.yaml.

• stdout_output : sortie standard, format JSON ou texte ; consomme par les operators Kubernetes via stdout du pod.
• syslog_output : envoi vers syslog local (RFC 5424), facility security par defaut.
• file_output : ecriture dans un fichier, utile pour offline forensics.
• program_output : exec d'un programme arbitraire avec l'alerte en stdin (legacy, deprecie au profit de Falcosidekick).
• http_output : POST JSON vers un endpoint HTTP/HTTPS, format webhook standard.
• grpc_output : streaming gRPC TLS pour consommation par des operators ou un agent externe ; protocole defini dans le proto falco.proto.

L'output natif vers Slack, PagerDuty, Elastic ou les CSPM cloud passe traditionnellement par Falcosidekick, qui consomme la sortie HTTP de Falco et la route vers les destinations metiers.

Falcosidekick : routeur d'alertes multi-destinations

Falcosidekick est le sous-projet officiel qui transforme Falco en hub d'alertes : ecrit en Go, distribue comme conteneur OCI, il expose un endpoint HTTP qui ingere les alertes Falco et les diffuse vers plus de 30 destinations classifiees en cinq familles : chat (Slack, Teams, Discord, Mattermost, Rocket.chat, Google Chat), SIEM/observabilite (Elastic, Loki, Datadog, Splunk, OpenSearch, Sumo Logic, Wavefront, Dynatrace, Grafana OnCall), incident response (PagerDuty, OpsGenie, Zenduty, AlertManager, Webex), serverless (AWS Lambda, GCP Cloud Run, Azure Functions, Kubeless, OpenFaas, Knative), et message bus (Kafka, RabbitMQ, NATS, AWS SQS/SNS, GCP Pub/Sub, Azure Event Hubs).

Falcosidekick embarque aussi Falcosidekick UI, une interface web React + Redis qui fournit la dashboard d'alertes manquante du package Falco core : timeline, filtrage par priorite, recherche full-text, statistiques par regle. Cette UI est le moyen le plus rapide d'obtenir une experience operationnelle complete avec un Falco vanilla. La pile typique en production Kubernetes deploie Falco en DaemonSet, Falcosidekick en Deployment 2 replicas et Falcosidekick UI en Deployment 1 replica avec Redis StatefulSet.

Regles communes : exec shell, escape, mining, reverse shell

Le ruleset par defaut falco_rules.yaml embarque environ 80 regles classees en categories MITRE ATT&CK Cloud. Les regles les plus declenchees en production couvrent quatre familles operationnelles.

Suspicious file access. Lecture de /etc/shadow, /etc/sudoers, /var/run/secrets/kubernetes.io/serviceaccount/token, modification de ~/.ssh/authorized_keys, ou ecriture sous /usr/bin par un container non privilege. Ces regles produisent peu de faux positifs et signent souvent une exfiltration ou une persistance.

Container escape. Utilisation de syscalls mount avec namespace host, ecriture sur /proc/sys/kernel/core_pattern, acces a /var/run/docker.sock ou /run/containerd/containerd.sock depuis l'interieur d'un pod, exploitation de capabilities CAP_SYS_ADMIN, CAP_SYS_PTRACE. Couverture des CVE runc et des techniques DirtyPipe / DirtyCred.

Cryptomining. Detection des binaires xmrig, kdevtmpfsi, kinsing, des connexions vers les pools *.minexmr.com, *.nanopool.org, des forks intensifs avec usage CPU 100% pendant 10+ minutes. Les regles Outbound Connection to Crypto Mining Pool et Mining Tool Spawned sont parmi les plus utilisees en cloud public.

Reverse shell. Pattern bash -i >& /dev/tcp/..., nc -e, python -c "import pty", perl -e "use Socket", redirection de FD vers une socket TCP. Les regles Reverse shell et Netcat Remote Code Execution in Container declenchent sur l'execve avec arguments suspicieux.

Detection container escape : CVE-2025-23266, runc CVEs

Falco est particulierement efficace pour detecter les tentatives d'evasion de container, scenario critique en environnement multi-tenant Kubernetes. La regle Container Drift Detected (open+create) declenche sur la creation d'un binaire executable dans un container apres son demarrage, signature classique d'une escalade. La regle Sensitive Mount by Container alerte sur le mount de /proc/1/root, /var/lib/docker ou /host par un pod non explicitement autorise.

Lors de la divulgation de la CVE-2025-23266 (faille NVIDIA Container Toolkit, juin 2025) qui permettait l'evasion via le hook nvidia-container-runtime, Falco a permis aux operateurs GPU de detecter les exploits en moins de 24h grace a une regle communautaire poussee via falcoctl. La meme reactivite avait ete observee sur les CVE runc 2024 (CVE-2024-21626 dite leaky vessels) et CVE-2019-5736.

Pour un cluster Kubernetes 1.35 avec user namespaces, Falco se combine bien avec les UIDs unmappes : les events kernel restent visibles avec leur UID host reel, ce qui evite les angles morts induits par la namespace user.

Performance et impact systeme

Le choix du driver determine l'overhead Falco. Les mesures suivantes ont ete realisees sur un cluster GKE n2-standard-8 (8 vCPU, 32 GB RAM) avec 25 pods/node et un trafic syscalls realiste de 80 000 evt/s.

Le mode modern eBPF est le compromis recommande : portabilite (CO-RE), pas d'insmod, performance proche du module noyau, securite renforcee (sandbox verifier kernel). En cluster managed (EKS, AKS, GKE), c'est souvent le seul mode disponible car les modules noyau custom sont interdits par les politiques cloud provider.

Comparatif Falco vs Tetragon vs KubeArmor vs Wazuh

Falco partage le segment de la runtime security cloud-native avec plusieurs concurrents open source. Le tableau ci-dessous compare les quatre solutions les plus deployees en 2026.

La regle pratique : Falco est optimal pour la detection multi-source (kernel + audit + plugins cloud) sans contrainte de prevention ; Tetragon apporte la prevention native dans une stack Cilium ; KubeArmor brille pour l'enforcement par policy LSM. Les trois sont souvent deployes complementairement, avec Wazuh ou Sentinel comme aval SIEM.

Use cases de production de Falco

Les deploiements Falco couvrent six scenarios principaux observes dans les missions audit Kubernetes et pentest Kubernetes.

Cluster Kubernetes multi-tenant. DaemonSet Falco sur tous les nodes worker, regles strictes sur exec dans pods, mount sensitifs, container drift. Combine avec RBAC durci et PodSecurity Standards.

Workloads conteneurises hors Kubernetes. Docker Swarm, Nomad, ECS sur EC2 : Falco en binaire systemd avec le plugin Docker pour enrichissement.

Hosts Linux bare-metal et VM. Detection equivalent EDR Linux : audit shell, persistance, escalade locale, exfiltration. Falco se positionne comme alternative cloud-native a auditd.

File Integrity Monitoring. Surveillance des binaires /usr/bin, configurations /etc, cles SSH avec regles type Tripwire mais en streaming temps reel.

Conformite reglementaire. Generation des trails d'evenements pour audits PCI DSS, ISO 27001, SOC 2, NIS2 (acces aux donnees sensibles, modifications privilegiees).

Threat hunting offline. Falco peut rejouer des fichiers de capture .scap generes par sysdig, utile pour analyser un incident a posteriori sur un dataset preserve. Voir datasets cybersecurite pour des corpus partages.

Conformite : CIS, PCI-DSS, GDPR, NIS2, MITRE ATT&CK

Falco contribue a plusieurs cadres de conformite reglementaires sans en couvrir l'integralite (il faut le combiner avec un SIEM pour le stockage, et un GRC pour la documentation).

• CIS Kubernetes Benchmark v1.10 : Falco verifie en runtime les controles 5.x (Policies) souvent statiques, notamment sur l'exec dans pods kube-system, l'usage de hostPath, l'absence de PodSecurity admission.
• PCI DSS 4.0 Requirement 10 (logging) et 11.5 (file integrity monitoring) : Falco fournit les evenements bruts ; le SIEM aval assure la retention 12 mois.
• GDPR Article 32 (mesures techniques) : Falco trace les acces aux donnees personnelles si les volumes contenant sont identifiables par chemin ou pod label.
• NIS2 Article 21.2.b (gestion des incidents) : Falco fournit la couche detection runtime indispensable au pilier "detection" du dispositif.
• MITRE ATT&CK Cloud Matrix : les regles Falco sont taggees avec les techniques (T1059 Execution, T1611 Escape to Host, T1496 Resource Hijacking, T1078 Valid Accounts), permettant un alignement direct avec la matrice.

Le mapping MITRE est exploite par les SIEM aval (Sentinel, Elastic Security) pour produire les dashboards de couverture et identifier les zones aveugles.

Limites et angles morts de Falco

Falco presente des limites assumees qu'il faut comprendre avant de standardiser sa stack runtime security autour du projet.

Linux uniquement. Pas de support Windows ni macOS, ni en endpoint ni en server. Les workloads Windows dans Kubernetes (nodes Windows Server) ne sont pas couverts.

Pas de remediation native. Falco detecte mais ne prevent ni ne tue. Pour la prevention, il faut coupler avec Tetragon, KubeArmor, ou un workflow Falcosidekick -> AWS Lambda -> kubectl delete pod.

Pas d'UI dans le core. Le binaire Falco genere des alertes JSON ; il faut Falcosidekick UI ou un SIEM aval pour visualiser.

Tuning anti-faux-positifs obligatoire. Le ruleset par defaut est volontairement bruyant pour ne rien rater. Une production sereine necessite 2-4 semaines de tuning : exclusions par image, pod label, namespace, command pattern.

Couverture syscalls limitee a 120. Certains scenarios avances necessitent d'instrumenter d'autres syscalls (rare en pratique mais possible : iouring, certains syscalls 64-bit specifiques arch).

Pas de threat intelligence native. Pas d'enrichissement automatique avec MISP, OTX, CrowdSec ; il faut le coder cote SIEM ou via un plugin custom.

FAQ Falco

Falco ou Wazuh, lequel choisir ?

Les deux outils ne couvrent pas le meme perimetre. Wazuh est une plateforme XDR/SIEM complete avec stockage, dashboard, agents multi-OS. Falco est un capteur runtime Linux pur sans stockage. La combinaison ideale est Falco comme detecteur runtime fin sur Kubernetes/Linux, et Wazuh comme SIEM aval consommant les alertes Falco via Falcosidekick. Si vous n'avez besoin que de la detection runtime container et que vous avez deja un SIEM, choisissez Falco. Si vous demarrez sans SIEM, Wazuh est un meilleur point d'entree, quitte a ajouter Falco plus tard pour la finesse kernel.

Falco fonctionne-t-il sur Windows ?

Non. Falco est exclusivement Linux. Les drivers (kernel module, eBPF) reposent sur l'API kernel Linux. Pour les workloads Windows containerises (nodes Windows Server dans Kubernetes), il faut utiliser Microsoft Defender for Endpoint, Sysmon for Windows, ou un EDR tiers comme Microsoft Defender XDR integre a Sentinel.

Quelle est la performance reelle du driver eBPF ?

Le mode modern eBPF CO-RE consomme typiquement 2,5 a 3% de CPU par node Kubernetes avec 25 pods et 80 000 syscalls/s, pour une RSS de 200-280 MB. Le drop rate (events perdus si le ring buffer sature) reste sous 0,1% en charge nominale. La consommation est inferieure au module noyau classique sur les kernels recents (5.15+) grace au verifier eBPF qui optimise les instructions JIT.

Comment integrer Falco a Microsoft Sentinel ?

L'integration s'effectue via Falcosidekick avec le module HTTP output configure pour envoyer les alertes JSON vers un Log Analytics Data Collector API ou Azure Event Hubs. Cote Sentinel, un parser KQL (Custom Logs) normalise les champs Falco (priority, rule, output_fields) et les regles analytiques peuvent ensuite correler avec d'autres sources. Le mapping MITRE des regles Falco est preserve via le champ tags. Voir Microsoft Sentinel pour les details architecture.

Falco est-il vraiment gratuit en production ?

Oui, integralement. Falco est distribue sous licence Apache 2.0 sans aucune restriction d'usage commercial, de nombre de nodes, ou de volume d'alertes. Sysdig commercialise une suite proprietaire Sysdig Secure qui s'appuie sur Falco mais ajoute UI, retention, threat intelligence, vulnerability management, CSPM. La version open source est suffisante pour la plupart des usages production ; Sysdig Secure devient pertinent au-dela de 500 nodes ou pour les exigences SaaS managed.

Falco peut-il bloquer une menace en temps reel ?

Non, pas en mode standalone. Falco est un detecteur (alertes seules). Pour la prevention temps reel, il existe trois patterns : 1) Falcosidekick + AWS Lambda/Cloud Function qui execute kubectl delete pod ou cordon node ; 2) couplage avec Tetragon ou KubeArmor qui embarquent le kill via eBPF/LSM ; 3) integration avec un admission controller Kyverno/OPA pour bloquer les recidives. Le projet falco-talon (sub-project incubating) tente d'unifier ce pattern de remediation.

Liens approfondis

• Documentation officielle : falco.org
• Code source et releases : github.com/falcosecurity/falco
• Page projet CNCF : cncf.io/projects/falco
• Plugins officiels : github.com/falcosecurity/plugins
• Falcosidekick : github.com/falcosecurity/falcosidekick
• Securisation Kubernetes RBAC : guide RBAC
• Durcissement cluster Kubernetes : durcissement cluster
• User namespaces Kubernetes 1.35 : user namespaces
• Wazuh XDR/SIEM : plateforme Wazuh
• Microsoft Sentinel : Sentinel SIEM
• Glossaire Kubernetes : definition Kubernetes
• Audit Kubernetes : prestation audit
• Pentest Kubernetes : prestation pentest
• Datasets cybersecurite : corpus de recherche