Déployer Falco en complément du pipeline applicatif sans saturer le SOC

📍 Guide principal du sujet : Pipeline SAST DAST SCA 2026 : architecture, outils et intégration CI/CD
Ce tutoriel positionne Falco comme couche de défense en production, en complément de la chaîne SAST/DAST/SCA. Pour la version centrée Kubernetes/CKS, voir aussi Falco runtime security et audit Kubernetes.

Pourquoi un runtime security en complément du pipeline SAST/DAST/SCA

Une chaîne SAST/DAST/SCA correctement opérée bloque la majorité des vulnérabilités avant le merge, mais une catégorie de problèmes échappe structurellement au pre-production. Les zero-day révélés après le déploiement (XZ-Utils backdoor en 2024, Log4Shell en 2021) ne sont par définition pas dans les bases de données au moment du build. Les compromissions de chaîne d’approvisionnement comme l’incident Trivy v0.69.4 de mars 2026 affectent directement les outils du pipeline. Les configurations dérivées (montage de socket Docker dans un pod, mot de passe par défaut laissé en place) ne se voient qu’à l’exécution. Pour ces classes de menaces, seule l’observation comportementale du runtime peut alerter à temps.

Falco 0.43.0, publiée en janvier 2026, est l’outil open source de référence pour cette mission. CNCF Graduated depuis février 2024, il observe les appels système via eBPF moderne, applique un moteur de règles YAML et émet des alertes en quelques millisecondes vers Slack, PagerDuty, un SIEM ou un agrégateur OpenTelemetry. Ce tutoriel détaille comment déployer Falco en complément d’un pipeline applicatif existant, écrire des règles adaptées à votre stack et brancher la sortie sur la même plateforme d’agrégation que vos findings SAST/SCA.

Prérequis

• Un cluster Kubernetes 1.28+ ou un hôte Linux avec noyau ≥ 5.8 (pour le driver eBPF moderne).
• Helm 3.14+ pour l’installation cluster.
• Un canal de notification : webhook Slack, endpoint Loki, ou agent OpenTelemetry.
• Niveau attendu : intermédiaire Kubernetes ou Linux sysadmin, à l’aise avec YAML.
• Temps estimé : 75 minutes pour l’installation, 30 minutes supplémentaires pour la première règle custom.

Étape 1 — Choisir le bon driver pour votre environnement

Falco peut intercepter les appels système par trois mécanismes. Le kmod historique est le plus performant mais demande un module noyau compilé pour la version exacte du kernel — fastidieux à maintenir. Le legacy eBPF probe est portable mais consomme plus de CPU. Le modern eBPF, distribué comme driver officiel à partir de Falco 0.35 (août 2023) puis adopté ensuite comme driver par défaut dans la logique de sélection automatique, combine portabilité et performance grâce aux CO-RE (Compile Once, Run Everywhere) du noyau Linux.

Pour un cluster Kubernetes 2026 en production, le choix recommandé est modern_ebpf sans condition. Vérifier que le noyau des nœuds est ≥ 5.8 avec kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.status.nodeInfo.kernelVersion}{"\n"}{end}'. Si un nœud est en deçà, soit le mettre à jour, soit basculer ce nœud sur le driver legacy eBPF qui descend à 4.14.

Étape 2 — Installer Falco via Helm avec le driver moderne

Le chart Helm officiel maintenu par falcosecurity embarque toutes les briques (Falco, Falcosidekick pour les sorties, Falcoctl pour le management des artefacts). L’installation typique en cluster prend deux commandes.

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf \
  --set tty=true \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="$SLACK_WEBHOOK"

L’option driver.kind=modern_ebpf active le driver CO-RE. falcosidekick.enabled=true déploie le routeur d’événements qui transforme les sorties Falco en notifications structurées vers plus de 50 destinations (Slack, MS Teams, PagerDuty, Webhook générique, Loki, Elastic, AWS SQS, GCP Pub/Sub, Kafka). Le webhook Slack est configuré inline pour l’exemple ; en production, le passer via un Secret Kubernetes monté en variable d’environnement. Vérifier après quelques secondes que les pods Falco tournent : kubectl get pods -n falco doit afficher un pod par nœud du cluster.

Étape 3 — Activer les règles communautaires de base

Falco vient livré avec un jeu de règles maintenu par la communauté (rules/falco_rules.yaml). Ces règles couvrent les détections génériques : ouverture d’un shell dans un conteneur, lecture de /etc/shadow, modification d’un binaire système, connexion sortante vers une IP non listée. Le chart Helm les active par défaut. Tester immédiatement la chaîne en provoquant une alerte volontaire.

kubectl run -it --rm test-falco --image=alpine --restart=Never -- sh
# Dans le shell du pod, déclencher une règle
cat /etc/shadow

Quelques millisecondes après l’exécution de cat /etc/shadow, une notification doit apparaître sur Slack : Read sensitive file untrusted (user=root file=/etc/shadow container=…). Cette boucle de validation est cruciale ; sans elle, une équipe peut passer des semaines à croire que Falco fonctionne alors que les pods tournent silencieusement. Si l’alerte n’arrive pas, vérifier les logs du pod falcosidekick avec kubectl logs -n falco -l app.kubernetes.io/name=falcosidekick.

Étape 4 — Écrire une règle custom adaptée à votre stack

Les règles communautaires sont génériques par construction. Pour traquer les comportements spécifiques à votre application, écrire des règles maison. Imaginons que votre service ne devrait jamais lancer de processus Python depuis un répertoire /tmp — un cas typique d’exécution post-exploitation. La règle s’écrit en YAML.

- rule: Python execution from /tmp
  desc: |
    A python process started from /tmp suggests post-exploitation activity:
    a downloaded payload was executed.
  condition: >
    spawned_process and
    proc.name in (python, python3, python3.11, python3.12) and
    proc.cwd startswith "/tmp" and
    container.image.repository = "ghcr.io/votreorg/votreapp"
  output: >
    Suspicious python execution from /tmp
    (user=%user.name pid=%proc.pid cmdline=%proc.cmdline
    container=%container.name image=%container.image.repository:%container.image.tag)
  priority: CRITICAL
  tags: [process, mitre_execution, votreorg]

Les conditions combinent des champs de l’événement avec des macros prédéfinies (spawned_process, container_started, open_write). Le filtre container.image.repository circonscrit la règle à votre image, évitant de noyer les alertes dans le bruit des autres workloads du cluster. Les tags suivent la matrice MITRE ATT&CK pour faciliter la corrélation côté SIEM. Charger la règle via une ConfigMap ou via le mécanisme natif customRules du chart Helm.

helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --reuse-values \
  --set-file customRules.rules-votreorg\\.yaml=./votreorg-rules.yaml

Étape 5 — Router les alertes vers Loki et OpenTelemetry

Slack convient pour les alertes critiques mais pas pour l’analyse. Pour traquer les patterns sur la durée, router les sorties Falco vers Loki (logs) ou OpenTelemetry (traces et métriques). Falcosidekick supporte les deux nativement.

# values.yaml partiel
falcosidekick:
  enabled: true
  config:
    loki:
      hostport: "https://loki.example.com"
      tenant: "falco"
      minimumpriority: "warning"
    otlp:
      traces:
        endpoint: "http://otel-collector.observability:4317"
        insecure: true
      logs:
        endpoint: "http://otel-collector.observability:4317"
        insecure: true
    slack:
      webhookurl: "${SLACK_WEBHOOK}"
      minimumpriority: "critical"

L’option minimumpriority par destination crée une politique de routage : Slack reçoit uniquement les alertes critiques (page-on-call), Loki capte tout pour l’analyse forensique, OpenTelemetry alimente le dashboard sécurité du SOC. Cette segmentation évite la fatigue d’alerte tout en conservant l’historique pour l’investigation.

Étape 6 — Tuner les exclusions pour réduire le bruit

Falco produit naturellement beaucoup d’alertes les premières semaines, dont une majorité de false positives liés à des comportements légitimes mais inhabituels. Le tuning passe par les macros override et les list override. Pour exclure votre image admin légitime du déclenchement shell in container :

- list: known_admin_images
  items: ["ghcr.io/votreorg/admin-toolkit", "ghcr.io/votreorg/incident-response"]

- macro: container_admin_image
  condition: container.image.repository in (known_admin_images)

- rule: Terminal shell in container
  condition: >
    spawned_process and container and shell_procs and
    proc.tty != 0 and not container_admin_image
  override:
    condition: append

Le mécanisme override: condition: append ajoute la clause not container_admin_image à la règle communautaire sans la réécrire entièrement, ce qui simplifie la maintenance lors des mises à jour du pack de règles. Versionner le fichier d’overrides dans Git et le déployer via Helm garantit la reproductibilité.

Étape 7 — Brancher Falco sur DefectDojo

Pour réunir les findings runtime avec ceux du pipeline applicatif, exporter les alertes Falco vers DefectDojo. Falcosidekick ne supporte pas DefectDojo nativement, mais la sortie webhook permet de pointer vers un petit relais qui traduit les événements en payload DefectDojo.

from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)
DOJO_URL = os.environ["DOJO_URL"]
DOJO_TOKEN = os.environ["DOJO_TOKEN"]
ENGAGEMENT_ID = os.environ["DOJO_ENGAGEMENT_ID"]

SEVERITY_MAP = {"emergency": "Critical", "alert": "Critical",
                "critical": "Critical", "error": "High",
                "warning": "Medium", "notice": "Low", "informational": "Low",
                "debug": "Info"}

@app.post("/falco")
def relay():
    e = request.json
    finding = {
        "title": f"Falco runtime alert: {e['rule']}",
        "description": e["output"],
        "severity": SEVERITY_MAP.get(e["priority"].lower(), "Medium"),
        "active": True,
        "verified": False,
        "engagement": int(ENGAGEMENT_ID),
        "static_finding": False,
        "dynamic_finding": True,
        "tags": e.get("tags", []) + ["falco", "runtime"]
    }
    r = requests.post(f"{DOJO_URL}/api/v2/findings/",
        headers={"Authorization": f"Token {DOJO_TOKEN}"},
        json=finding, timeout=5)
    return jsonify({"status": "ok", "dojo": r.status_code})

Déployer ce relais en sidecar à côté de Falcosidekick et configurer la sortie webhook : --set falcosidekick.config.webhook.address="http://falco-dojo-relay:5000/falco". Les alertes Falco rejoignent ainsi le même backlog que les findings SAST/SCA, ce qui matérialise la promesse d’un programme DevSecOps unifié.

Étape 8 — Mesurer la santé de la couche runtime

Trois indicateurs valent d’être suivis pour mesurer l’efficacité du déploiement. Le volume d’alertes par jour sur les sept derniers jours indique si le tuning est mature (cible : 5 à 50 par jour pour un cluster moyen, 100+ trahit un défaut de tuning). Le temps médian de réponse aux alertes critiques (cible : sous 15 minutes en heures ouvrées). Enfin la couverture des nœuds : un pod Falco par nœud, vérifié via kubectl get ds falco -n falco -o jsonpath='{.status.numberReady}/{.status.desiredNumberScheduled}'.

Un dashboard Grafana branché sur les logs Loki Falco apporte la vision longitudinale. La requête LogQL sum by (rule) (rate({app="falco"} |= "priority" [1h])) trace l’évolution du volume par règle et révèle immédiatement quelle règle s’emballe ou s’éteint suite à un changement de configuration.

Approche complémentaire : webhook + relais custom pour intégration sur mesure

Au-delà des destinations standard de Falcosidekick, on peut router les événements vers un consommateur HTTP custom (orchestrateur de réponse propriétaire, moteur de corrélation maison, agent de quarantaine automatique) via la sortie webhook de Falcosidekick. Cette approche remplace l’ancienne API gRPC intégrée, dépréciée depuis Falco 0.43.0 et à supprimer dans une release future ; les déploiements neufs en 2026 doivent privilégier le webhook ou directement Falcosidekick.

helm upgrade falco falcosecurity/falco \
  --namespace falco --reuse-values \
  --set falcosidekick.config.webhook.address="https://votre-relais.example.com/falco" \
  --set falcosidekick.config.webhook.method="POST"

Une fois activée, le relais HTTP reçoit chaque alerte en JSON structuré et peut déclencher l’action appropriée. Pour un environnement multi-cluster, exposer un agrégateur central derrière mTLS et y router chaque Falcosidekick pose les bases d’un SOC unifié sans dépendre d’un éditeur tiers.

Erreurs fréquentes

FAQ

Falco peut-il remplacer un EDR commercial ? Pas exactement. Falco couvre la couche syscall en temps réel et excelle pour la détection comportementale. Un EDR (CrowdStrike, SentinelOne) couvre en plus la corrélation d’attaque, la chasse aux menaces (threat hunting), l’analyse mémoire et la réponse automatisée (isolation de l’hôte). Les deux se complètent : Falco pour le temps réel haute-valeur sur Kubernetes, EDR pour la profondeur d’analyse organisationnelle.

Quel impact CPU et mémoire en production ? Avec le driver moderne eBPF, comptez 100 à 300 mCPU et 200 à 500 Mo de RAM par nœud, soit 1 à 3 % de la capacité d’un nœud standard. Sur des nœuds très petits (Edge IoT), basculer sur le driver legacy eBPF avec un buffer plus petit pour réduire la mémoire.

Les règles Falco peuvent-elles bloquer une action plutôt que seulement alerter ? Pas directement. Falco détecte et alerte, le blocage est délégué à des composants en aval. Le pattern habituel : Falco déclenche une alerte vers une plateforme de réponse (Falcoctl, OPA Gatekeeper, ou un opérateur custom) qui prend l’action — kill du pod, snapshot, isolation réseau via une NetworkPolicy de quarantaine.

Comment écrire une règle pour détecter un crypto-mineur ? Les patterns classiques : connexion sortante vers les pools (stratum+tcp://), processus xmrig/minerd, utilisation CPU sustainée à 100 % sans corrélation avec le trafic entrant. Le pack communautaire falco-cryptomining sur Artifact Hub fournit un point de départ.

Falco fonctionne-t-il sur AWS Fargate ou GCP Cloud Run ? Non. Ces plateformes serverless n’exposent pas l’accès aux syscalls de l’hôte requis par Falco. Pour ces environnements, utiliser les capacités runtime du fournisseur (GuardDuty Runtime Monitoring sur AWS, Container Threat Detection sur GCP).

Tutoriels associés

• Falco runtime security et audit Kubernetes — détecter les attaques CKS — focus certification CKS, audit Kubernetes et règles avancées.
• Intégration Falco + OpenTelemetry : corrélation runtime security et observabilité — pour pousser plus loin la corrélation traces ↔ alertes.
• 🔝 Retour au guide principal : Pipeline SAST DAST SCA 2026 : architecture, outils et intégration CI/CD

Lectures recommandées

• Documentation officielle Falco
• Chart Helm officiel
• Releases Falco sur GitHub
• Falcosidekick — routeur d’événements
• Page projet CNCF (Graduated)
• Annonce de la graduation CNCF
• MITRE ATT&CK pour catégoriser les règles