الدليل الرئيسي: Pipeline SAST DAST SCA 2026: المعماريّة، الأدوات وتكامل CI/CD
هذا الدرس يضع Falco كطبقة دفاع في الإنتاج، تكمّل سلسلة SAST/DAST/SCA.
لماذا runtime security يكمّل pipeline SAST/DAST/SCA
سلسلة SAST/DAST/SCA المُدارة بشكل صحيح تحجب أغلبيّة الثغرات قبل الـ merge، لكنّ فئة من المشاكل تُفلت بنيوياً من ما قبل الإنتاج. Zero-day المكتشفة بعد النشر (XZ-Utils backdoor في 2024، Log4Shell في 2021) ليست بحكم التعريف في قواعد البيانات وقت البناء. اختراقات سلسلة التوريد مثل حادثة Trivy v0.69.4 في مارس 2026 تُؤثّر مباشرة على أدوات الـ pipeline. الإعدادات المُشتقّة (تركيب socket Docker في pod، password افتراضيّ مُتروك) لا تظهر إلّا أثناء التنفيذ. لهذه الفئات من التهديدات، مراقبة سلوكيّة لـ runtime وحدها تستطيع التنبيه في الوقت المناسب.
Falco 0.43.0، الصادرة في يناير 2026، هي أداة open source المرجعيّة لهذه المهمّة. CNCF Graduated منذ فبراير 2024، تُراقب system calls عبر eBPF حديث، تُطبّق محرّك قواعد YAML وتُصدر تنبيهات في ميلّي ثوان نحو Slack أو PagerDuty أو SIEM أو agrégateur OpenTelemetry. هذا الدرس يُفصّل كيفيّة نشر Falco كمكمّل لـ pipeline تطبيقيّ قائم، كتابة قواعد مناسبة لـ stackك وتوصيل المُخرج بنفس منصّة التجميع لـ findings SAST/SCA.
المتطلّبات
- cluster Kubernetes 1.28+ أو host Linux مع kernel ≥ 5.8 (للـ driver eBPF الحديث).
- Helm 3.14+ للتثبيت على cluster.
- قناة إشعار: webhook Slack، endpoint Loki، أو agent OpenTelemetry.
- المستوى المتوقَّع: متوسّط Kubernetes أو Linux sysadmin، مرتاح مع YAML.
- الوقت المُقَدَّر: 75 دقيقة للتثبيت، 30 دقيقة إضافيّة للقاعدة المُخصَّصة الأولى.
الخطوة 1 — اختيار driver المناسب لبيئتك
Falco يمكنه اعتراض system calls عبر ثلاث آليّات. الـ kmod التاريخيّ الأكثر أداءً لكنّه يتطلّب module kernel مُجمَّع لنسخة kernel الدقيقة — مُتعِب الصيانة. الـ legacy eBPF probe portable لكنّه يستهلك CPU أكثر. الـ modern eBPF، المُوزَّع كـ driver رسميّ منذ Falco 0.35 (أغسطس 2023) ثمّ المُتبَنّى كـ driver افتراضيّ في منطق الاختيار الآليّ، يجمع portabilité والأداء بفضل CO-RE (Compile Once, Run Everywhere) في Linux kernel.
لـ cluster Kubernetes 2026 في الإنتاج، الاختيار الموصى به هو modern_ebpf دون شرط. تحقّق أنّ kernel nodes ≥ 5.8 بـ kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.status.nodeInfo.kernelVersion}{"\n"}{end}'. إذا كان node أدنى، إمّا حدّثه، أو حوّل ذلك الـ node إلى driver legacy eBPF الذي ينزل إلى 4.14.
الخطوة 2 — تثبيت Falco عبر Helm مع driver حديث
الـ Helm chart الرسميّ المُدار من falcosecurity يُضمّن كلّ اللبنات (Falco، Falcosidekick للمخارج، Falcoctl لإدارة artefacts). التثبيت النموذجيّ في cluster يأخذ أمرين.
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"الخيار driver.kind=modern_ebpf يُفعّل driver CO-RE. falcosidekick.enabled=true ينشر event router الذي يحوّل مخارج Falco إلى إشعارات مُهيكَلة نحو أكثر من 50 destination (Slack، MS Teams، PagerDuty، Webhook عامّ، Loki، Elastic، AWS SQS، GCP Pub/Sub، Kafka). الـ Slack webhook مُعَدّ inline للمثال؛ في الإنتاج، مرّره عبر Kubernetes Secret مُركَّب كمتغيّر بيئة. تحقّق بعد ثوان قليلة أنّ pods Falco تعمل: kubectl get pods -n falco يجب أن يعرض pod واحد لكلّ node من الـ cluster.
الخطوة 3 — تفعيل القواعد المجتمعيّة الأساسيّة
Falco يأتي بمجموعة قواعد مُدارة من المجتمع (rules/falco_rules.yaml). هذه القواعد تُغطّي اكتشافات عامّة: فتح shell في container، قراءة /etc/shadow، تعديل binary نظام، اتّصال صادر نحو IP غير مُدرَجة. الـ Helm chart يُفعّلها افتراضياً. اختبر السلسلة فوراً بإثارة تنبيه إراديّ.
kubectl run -it --rm test-falco --image=alpine --restart=Never -- sh
# في shell الـ pod، إثارة قاعدة
cat /etc/shadowبعد ميلّي ثوان قليلة من تنفيذ cat /etc/shadow، إشعار يجب أن يظهر على Slack: Read sensitive file untrusted (user=root file=/etc/shadow container=…). حلقة التحقّق هذه حاسمة؛ بدونها، فريق قد يقضي أسابيع يعتقد أنّ Falco يعمل بينما الـ pods تدور بصمت. إذا لم يصل التنبيه، تحقّق من logs الـ pod falcosidekick بـ kubectl logs -n falco -l app.kubernetes.io/name=falcosidekick.
الخطوة 4 — كتابة قاعدة مُخصَّصة لـ stackك
القواعد المجتمعيّة عامّة بحكم البناء. لاصطياد السلوكيّات الخاصّة بتطبيقك، اكتب قواعد محلّيّة. تخيّل أنّ خدمتك يجب ألّا تُطلق عمليّة Python من مجلّد /tmp — حالة نموذجيّة لتنفيذ post-exploitation. القاعدة تُكتَب في 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]الـ conditions تجمع حقول الحدث مع macros مُعرَّفة مسبقاً (spawned_process، container_started، open_write). الـ filter container.image.repository يُحَدِّد القاعدة في صورتك، متجنّباً غمر التنبيهات في ضوضاء workloads أخرى للـ cluster. الـ tags تتبع matrice MITRE ATT&CK لتسهيل الترابط من جانب SIEM. حمّل القاعدة عبر ConfigMap أو عبر الآليّة الأصيلة customRules في الـ Helm chart.
helm upgrade falco falcosecurity/falco \
--namespace falco \
--reuse-values \
--set-file customRules.rules-votreorg\\.yaml=./votreorg-rules.yamlالخطوة 5 — توجيه التنبيهات نحو Loki و OpenTelemetry
Slack مناسب للتنبيهات الحرجة لكن ليس للتحليل. لاصطياد الأنماط على المدى، وجّه مخارج Falco نحو Loki (logs) أو OpenTelemetry (traces و métriques). Falcosidekick يدعم الاثنين أصليّاً.
# values.yaml جزئيّ
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"الخيار minimumpriority لكلّ destination يُنشئ سياسة توجيه: Slack يستقبل فقط التنبيهات الحرجة (page-on-call)، Loki يلتقط كلّ شيء للتحليل forensique، OpenTelemetry يُغذّي dashboard الأمن في الـ SOC. هذه التجزئة تتجنّب alert fatigue مع الاحتفاظ بالتاريخ للتحقيق.
الخطوة 6 — ضبط الاستثناءات لتخفيض الضوضاء
Falco يُنتج طبيعياً كثيراً من التنبيهات في الأسابيع الأولى، أغلبيّتها false positives مرتبطة بسلوكيّات شرعيّة لكن غير مألوفة. الضبط يمرّ عبر macros override و list override. لاستثناء صورة admin شرعيّة من إثارة 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الآليّة override: condition: append تُضيف بند not container_admin_image إلى القاعدة المجتمعيّة دون إعادة كتابتها كاملاً، ما يُبسّط الصيانة عند تحديثات pack القواعد. تثبيت ملفّ overrides في Git ونشره عبر Helm يضمن reproducibilité.
الخطوة 7 — ربط Falco بـ DefectDojo
لجمع findings runtime مع findings الـ pipeline التطبيقيّ، صدّر تنبيهات Falco نحو DefectDojo. Falcosidekick لا يدعم DefectDojo أصليّاً، لكنّ مُخرَج webhook يسمح بالإشارة إلى ترحيل صغير يحوّل الأحداث إلى payload DefectDojo.
الخطوة 8 — قياس فعّاليّة Falco
# Metrics Falco
kubectl port-forward -n falco svc/falco 8765
curl http://localhost:8765/metrics
# المقاييس الأهمّ:
# - falco_n_evts: عدد system calls المُحلَّلة
# - falco_n_drops: system calls مفقودة (يجب البقاء قريب 0)
# - falco_rules_matches_total: تنبيهات حسب القاعدة
إذا ارتفع n_drops، زِد syscall_event_drops.threshold أو فعّل modern_bpf driver (أسرع من eBPF التقليديّ في Falco 0.40+).
الأخطاء المتكرّرة
| الخطأ | الحلّ |
|---|---|
| Falco pod يصرّ في CrashLoopBackOff | kernel غير متوافق، حوّل إلى legacy eBPF |
| لا تنبيهات في Slack | تحقّق webhook URL، logs falcosidekick |
| كثير من false positives | أَضِف list/macro overrides لـ workloads شرعيّة |
| n_drops > 0 | node CPU saturated، augment threshold أو نشر node إضافيّ |
| القاعدة المُخصَّصة لا تحفّز | تحقّق syntax YAML، charge via Helm، redémarrer pods |
أسئلة شائعة
هل Falco يُبطئ الـ nodes؟ أثر CPU عادة < 2% لـ eBPF driver. modern_bpf أسرع (< 1%). raw kernel module غير موصى به للإنتاج.
هل يعمل على managed Kubernetes (EKS/GKE/AKS)؟ نعم — eBPF يعمل دون متطلّبات خاصّة. تأكّد فقط من kernel ≥ 4.14.
الفرق بين Falco و Tetragon؟ الاثنان runtime security. Tetragon (من Isovalent) يستعمل eBPF أكثر تطوّراً ويسمح بـ blocking. Falco أكثر نضجاً ولديه قواعد جاهزة كثيرة.
للاستزادة
الكلمات المفتاحيّة: Falco runtime security، eBPF modern driver، Helm Falco، Falcosidekick، Slack webhook، Loki OpenTelemetry، DefectDojo، CNCF Graduated.