2026 年容器安全防禦：Trivy 與 Falco 執行階段漏洞與異常行為監控
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path",
"impact_statement": "受影響的函式僅在測試路徑中使用，正式建置已透過 tree-shaking 移除。"
VulnerabilityReport
工作負載的弱點清單
kubectl get vulnreports -A
ConfigAuditReport
組態與最佳實務稽核
kubectl get configauditreport -A
ExposedSecretReport
暴露的敏感資訊
kubectl get exposedsecretreports -A
SBOMReport
映像的 SBOM 資訊
kubectl get sbomreports -A
ClusterComplianceReport
對照 NSA、CIS 等基準的合規報告
kubectl get clustercompliancereports -A安裝方式（透過 Helm）：
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
namespace trivy-system \
create-namespace \
set="trivy.ignoreUnfixed=true" \
set="operator.scanJobCompressLogs=true"
一個實用的做法是：把 Trivy Operator 產出的報告接進 Grafana，做成「組織內高危 CVE 數量趨勢圖」。當這條線往上飆的時候，通常代表某個基礎映像需要更新，或是有新的嚴重漏洞正在大規模影響你的環境。這種可視化遠比每天收幾十封掃描郵件要有用得多。
三、Falco 執行階段監控：用 eBPF 捕捉容器內的異常行為
如果說 Trivy 是「靜態的體檢報告」，那 Falco 就是「24 小時的心電圖監測」。它關注的不是「你的映像有沒有已知漏洞」，而是「你的容器現在正在做什麼，而這件事是否合理」。
3.1 Falco 的運作原理：核心驅動與 eBPF 探針
Falco 的核心原理其實很直觀：它必須取得 Linux 核心層級的系統呼叫（syscall）資訊，才能判斷一個容器內的程序到底做了什麼。歷史上它透過核心模組（Kernel Module）達成這個目的，但核心模組在現代環境中越來越不受歡迎——需要編譯、需要符合節點的 kernel headers、在某些雲端環境甚至不被允許載入。
因此，現代 eBPF 探針（modern eBPF probe）成為 2026 年的主流選擇。它不需要核心模組、不需要編譯，只要 Linux 核心版本在 5.8 以上並支援 BTF（BPF Type Format）即可運作。這大幅降低了部署門檻，也讓 Falco 能在多數受管 Kubernetes 服務上順利運行。
Falco 的整體架構可以拆成三層：
驅動層（Driver）：擷取系統呼叫與核心事件，可能是核心模組、傳統 eBPF 探針或現代 eBPF 探針。
規則引擎層（Rule Engine）：把原始事件流與 YAML 規則進行比對。Falco 使用類似過濾表達式的語法來描述「什麼樣的條件組合代表可疑行為」。
輸出層（Outputs）：符合規則的事件會以告警形式輸出到 stdout、檔案、gRPC、HTTP webhook、Syslog 等，或透過 Falcosidekick 轉送到 Slack、Teams、Elasticsearch、PagerDuty 等。
值得一提的是，Falco 的規則庫不只涵蓋系統呼叫層面，也包含 Kubernetes 稽核事件（Audit Events）。這代表你可以寫出「有人在 production namespace 裡執行了 kubectl exec 進入容器」或是「有人建立了具有 cluster-admin 權限的 RoleBinding」這類規則——這些都是純系統呼叫看不到的行為。
3.2 規則語言、巨集與清單
Falco 規則的基本結構如下：
- rule: 規則名稱
desc: 規則說明
condition: 觸發條件（過濾表達式）
output: 告警輸出格式
priority: 嚴重等級（EMERGENCY / ALERT / CRITICAL / ERROR / WARNING / NOTICE / INFORMATIONAL / DEBUG）
tags: [標籤清單]
其中 condition 是最核心的部分，它由「欄位（Field）」、「運算子」與「巨集／清單」組成。幾個常用欄位：
proc.name：程序名稱（如 bash、curl、nc）
proc.cmdline：完整命令列
proc.pname：父程序名稱
container.id / container.image.repository：容器識別資訊k8s.ns.name / k8s.pod.name：Kubernetes 中繼資料fd.name：檔案或 socket 路徑
user.uid / user.name：使用者資訊evt.type：事件類型（如 open、connect、execve）
巨集（Macro）是可重用的條件片段，清單（List）則用來集中管理一組值。以下是一個簡化的自訂規則檔範例：
- list: allowed_shell_images
items: [alpine-debug, netshoot]
- macro: container_shell_started
condition: (spawned_process and container and proc.name in (bash, sh, zsh, ash, dash))
- rule: 容器內啟動互動式 Shell
desc: 偵測容器內出現互動式 Shell，可能代表有人正在手動操作或攻擊者已取得執行權
condition: >
container_shell_started
and proc.tty != 0
and not container.image.repository in (allowed_shell_images)
output: >
容器內啟動互動式 Shell
(user=%user.name container=%container.name image=%container.image.repository
command=%proc.cmdline parent=%proc.pname tty=%proc.tty
namespace=%k8s.ns.name pod=%k8s.pod.name)
priority: NOTICE
tags: [container, shell, mitre_execution]
- rule: 容器內出現反向 Shell 工具
desc: 偵測常見的反向 Shell 工具被執行
condition: >
spawned_process and container
and proc.name in (nc, ncat, netcat, socat, telnet)
and (proc.cmdline contains "-e" or proc.cmdline contains "/bin/sh")
output: >
疑似反向 Shell 執行
(user=%user.name container=%container.name image=%container.image.repository
command=%proc.cmdline parent=%proc.pname namespace=%k8s.ns.name)
priority: CRITICAL
tags: [container, reverse_shell, mitre_command_and_control]
- rule: 容器內寫入敏感路徑
desc: 容器內程序嘗試寫入 /etc、/root 等敏感目錄
condition: >
open_write and container
and (fd.name startswith /etc/ or fd.name startswith /root/)
output: >
容器內寫入敏感路徑
(user=%user.name container=%container.name file=%fd.name
command=%proc.cmdline namespace=%k8s.ns.name)
priority: WARNING
tags: [container, filesystem, mitre_persistence]
3.3 實戰：從「過度告警」到「精準告警」
Falco 最常被抱怨的問題是「告警太多」。但這個問題通常不是 Falco 的錯，而是規則沒有針對環境調整。以下是我在實際調校時覺得最有用的幾個技巧：
技巧一：用例外清單而不是修改核心規則。如果你的 platform 團隊需要合法地在容器內執行 shell 進行除錯，不要直接註解掉規則，而是用 not 加上具體條件：
- rule: 容器內啟動互動式 Shell
desc: 排除具備除錯標籤的命名空間
condition: >
container_shell_started
and proc.tty != 0
and not k8s.ns.name startswith debug-
and not k8s.ns.name = "platform-tools"
output: >
容器內啟動互動式 Shell (%container.name / %proc.cmdline / %k8s.ns.name)
priority: NOTICE
技巧二：善用 k8s.pod.label 進行範圍控制。對於一些確定會執行特定行為的工作負載（例如備份 Job 會執行 tar、監控 Agent 會執行 ps），可以透過標籤來豁免，而不是用映像名稱硬編碼。
技巧三：分層設定優先級。把真正需要立即處理的行為設為 CRITICAL（反向 shell、加密挖礦、敏感檔案寫入），把僅供參考的行為設為 NOTICE（非預期的 shell、不常見的網路連線）。這樣才能讓值班人員在半夜被叫醒時，知道這封告警是真的要處理。
技巧四：先跑「僅記錄」模式。Falco 的告警本質上只是輸出，不會主動阻擋。因此建議新環境先跑一到兩週，把告警量與分布看清楚，再逐條調整規則，最後才考慮接上自動化回應（如 Falco Talon）。
3.4 告警輸出與事件分流
Falco 原生支援多種輸出通道。最常見的架構是搭配 Falcosidekick，把告警轉送到各種目的地：
# falco.yaml 中的輸出設定片段
json_output: true
json_include_output_property: true
outputs:
rate: 1
max_burst: 1000
program_output:
enabled: false
http_output:
enabled: true
url: "http://falcosidekick.falco.svc.cluster.local:2801/"
Falcosidekick 支援的目的地非常多，實務上常見的組合是：
Slack / Teams：給即時值班人員看的高優先級告警
Elasticsearch / OpenSearch：全量事件存放，供事後調查與關聯分析
PagerDuty / Opsgenie：CRITICAL 等級的即時呼叫
SOAR 平台：觸發自動化處置流程（隔離 Pod、撤銷 Token）
這裡有一個容易被忽略的重點：告警必須有「上下文」，否則就只是噪音。如果你的告警只寫「容器內啟動了 shell」，收到的人還得自己去查是哪個 namespace、哪個 pod、哪個映像。但如果告警本身就帶上了 k8s.ns.name、k8s.pod.name、container.image.repository 與完整的 proc.cmdline，那處理速度會快上一個量級。這也是為什麼上面範例中的 output 欄位我都盡量把關鍵欄位帶齊。
四、Trivy × Falco 聯防架構：打造閉環的容器安全防禦
單獨使用 Trivy 或 Falco 都有價值，但真正的效益來自於把它們串成一個閉環。以下是我認為在 2026 年最務實的架構設計。
4.1 偵測—評估—回應的閉環設計
整個流程可以拆成三個階段：
[建置階段]
程式碼提交 → CI 建置映像 → Trivy 掃描（vuln / secret / misconfig）
產生 SBOM + VEX
簽章（cosign）→ 推送映像倉庫
[部署階段]
Admission Controller 驗證簽章與掃描結果
↓（通過）
部署至 Kubernetes
Trivy Operator 持續掃描，產出 VulnerabilityReport
[執行階段]
Falco 監控系統呼叫與 K8s 稽核事件
↓（偵測到異常）
Falcosidekick → SIEM / SOAR / Slack
自動化回應：隔離 Pod、撤銷 Token、封鎖 IP
回饋至 Trivy：若涉及特定 CVE，標記該映像為高風險
這個架構的關鍵在於最後那條「回饋線」：執行階段發現的異常行為，應該要能回饋到靜態掃描的評估邏輯中。例如：如果 Falco 偵測到某個容器正在嘗試利用某個已知 CVE，那 Trivy 對這個映像的風險評分就應該提高，未來的部署就應該被更嚴格地審查。
4.2 與 Kubernetes Admission Controller 整合
要做真正的「預防」，Admission Controller 是關鍵一環。常見做法是搭配 Kyverno 或 OPA Gatekeeper，在 Pod 被建立之前進行檢查：
簽章驗證：只允許通過 cosign 驗證的映像進入叢集。
掃描結果查詢：查詢 Trivy Operator 產出的 VulnerabilityReport，若存在 CRITICAL 且未修補的弱點則拒絕。
安全上下文檢查：強制 runAsNonRoot、readOnlyRootFilesystem、禁止 privileged: true。
以下是一個 Kyverno 策略的簡化範例：
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-image-signature
spec:
validationFailureAction: Enforce
rules:
- name: verify-signature
match:
any:
- resources:
kinds: [Pod]
verifyImages:
- imageReferences:
- "registry.example.com/*"
attestors:
- entries:
- keyless:
subject: "https://github.com/your-org/*"
issuer: "https://token.actions.githubusercontent.com"
需要注意的是，這類策略在初期一定要用 Audit 模式跑一段時間，觀察會有多少既有工作負載被擋下。直接上 Enforce 的結果，往往是整個團隊的部署全數失敗。
4.3 與 SIEM／SOAR 的整合
當告警量成長到一定程度，就必須進入 SIEM 做關聯分析。一個實用的關聯邏輯是：
Falco 告警：某個 Pod 出現異常的對外連線。
關聯 Trivy 報告：該 Pod 使用的映像含有某個已知的 RCE 漏洞。
關聯 K8s 稽核日誌：該 Pod 的 ServiceAccount 在過去十分鐘內呼叫了 API。
綜合判斷：高度可能的實際入侵，觸發最高等級回應。
這種關聯在純告警層面是看不出來的，必須依靠 SIEM 把不同來源的事件整合起來。而 Falco 的 JSON 輸出格式與 Trivy 的 SARIF／JSON 格式都相當標準化，整合起來並不困難。
五、效能調校與營運實務：別讓安全成為維運災難
工具再好，如果拖垮了系統效能、或讓維運團隊疲於奔命，最終還是會被關掉。以下是幾個實務上必須考慮的點。
5.1 掃描頻率與快取策略
Trivy 需要下載弱點資料庫（Vulnerability DB），這在大型組織中如果每個 CI job 都重新下載一次，會造成相當可觀的頻寬與時間成本。建議做法：
在 CI runner 層級設定共用快取目錄，並定期更新。
使用自架（或企業版）的弱點資料庫鏡像，避免對外網路的依賴。
Trivy Operator 在叢集內使用 PersistentVolume 快取資料庫，避免每個節點重複下載。
設定範例：
# trivy.yaml
db:
repository: registry.example.com/trivy-db
skip-update: false
cache:
dir: /var/cache/trivy
scan:
severity:
- HIGH
- CRITICAL
ignore-unfixed: true
5.2 降低 Falco 誤報的實務技巧
前面提過要調整規則，這裡再補充幾個具體的營運經驗：
為每個命名空間設定不同的規則集。Falco 支援載入多個規則檔，可以用 --rules 參數指定。生產環境與沙箱環境的規則應該不同。
定期檢視 Top 10 告警來源。如果某條規則貢獻了 80% 的告警，而其中多數是誤報，就應該針對它調校，而不是其他 20 條。
把「已知會告警」的行為文件化。當新人問「為什麼這個告警一直跳」，如果沒有文件，他可能就直接把規則關掉了。用註解或內部 Wiki 記錄每一條例外條件的理由。
考慮使用 Falco Talon 做自動化處置。對於確定是惡意行為的規則（如反向 shell），可以直接觸發隔離 Pod 的動作，而不只是發告警。
5.3 資源配置建議
Falco 的資源消耗取決於節點上的系統呼叫量。以現代 eBPF 探針來說，在一般負載的節點上，CPU 使用率通常在個位數百分比之內。以下是一個保守的起始配置：
元件
CPU Request
CPU Limit
Memory Request
Memory Limit
Falco（DaemonSet，每節點）
100m
1000m
256Mi
512Mi
Falcosidekick
50m
200m
64Mi
128Mi
Trivy Operator
100m
500m
128Mi
512Mi
Trivy 掃描 Job（每個掃描）
100m
500m
256Mi
1Gi
另外提醒：不要對 Falco 設定過低的 CPU limit。因為它需要即時處理系統呼叫，一旦被 CPU throttling 卡住，可能會導致事件遺失（drop）。在 Falco 的指標中，falco_n_drops_total 是必須監控的關鍵指標——這個數字只要不是零，就代表你正在漏掉事件。
六、2026 年之後的展望：AI 輔助與合規壓力
6.1 AI 驅動的異常行為基線
規則式偵測的先天限制在於：它只能偵測「你已經知道要偵測的東西」。對於未知的攻擊手法，傳統規則往往無能為力。這正是 AI 輔助異常偵測開始被廣泛採用的原因。
目前觀察到的實務做法有兩大類：
行為基線建模：先觀察每個工作負載在一段時間內的「正常行為輪廓」（會執行哪些程序、讀寫哪些檔案、連線哪些位址），之後把偏離基線的行為標記為可疑。這種做法可以有效捕捉到規則未涵蓋的新型攻擊。
告警降噪與關聯：用模型分析歷史告警與回應結果，自動判斷哪些告警是誤報、哪些應該被升級。這對於解決「告警疲勞」問題特別有幫助。
不過要提醒的是，AI 模型本身也需要治理。如果模型是黑盒子，它產出的告警就難以解釋，反而不利於調查。因此建議的做法是：用 AI 來排序與關聯，用規則來解釋與舉證。兩者互補，而不是取代。
6.2 法規與合規要求
從 2024 年開始，各國對軟體供應鏈安全的要求持續升溫。到了 2026 年，幾個關鍵的合規面向已經相當明確：
SBOM 的可取得性：採購方要求供應商提供 SBOM 已成為常態，格式以 SPDX 與 CycloneDX 為主。
弱點揭露與回應時限：針對重大漏洞，要求在特定期限內完成評估與回應，並保留紀錄。
執行階段監控的證據留存：不只是「有做」，而是要能提出「做了什麼、發現什麼、怎麼處理」的完整紀錄。
這對 Trivy 與 Falco 的使用方式有直接影響：
Trivy 的 VEX 文件不再只是「減少誤報的工具」，而是「證明你已評估過該漏洞」的正式文件，必須被保存與版本控管。
Falco 的告警不能只送到 Slack 就結束，必須進入具備留存與稽核能力的 SIEM 或日誌系統。
兩者產出的報告都應該有明確的時間戳、映像 digest 與環境標識，才能在稽核時對應到具體的部署版本。
七、結語：讓安全成為可觀測性的一部分
回顧這整篇文章，我想傳達的核心觀念其實只有一個：容器安全不是一道關卡，而是一條持續運作的迴路。
Trivy 讓你知道「你運行的東西有什麼問題」，Falco 讓你知道「你運行的東西正在做什麼」。前者是靜態的、可預測的、適合自動化的；後者是動態的、充滿雜訊的、需要持續調校的。但只有在這兩者同時到位、並且把資訊串起來的時候，你才能真正回答那個最重要的問題：「我現在安全嗎？如果不安，我該做什麼？」
實作上，我會建議這樣安排優先順序：
第一個月：在 CI 中加入 Trivy 掃描，先從「只記錄不中斷」開始，建立弱點基線。
第二到第三個月：部署 Trivy Operator，開始持續掃描執行中的工作負載，並把報告可視化。
第三到第四個月：部署 Falco，用官方規則集跑一段時間，觀察告警分布。
第五到第六個月：開始調校 Falco 規則，建立例外清單與自動化回應，並把告警導入 SIEM。
第六個月之後：導入 Admission Controller 的簽章驗證與掃描結果檢查，形成完整的閉環。
這個節奏看起來慢，但實際上比「一次全部上線然後被告警淹沒」要快得多。容器安全是一場馬拉松，不是短跑。工具會持續演進，攻擊手法也會持續變化，但只要你有穩定的觀測能力與可回應的流程，你就能在每一次變化中站穩腳步。
常見問題（FAQ）
Q1：Trivy 和 Falco 可以互相取代嗎？
不行，兩者解決的是不同問題。Trivy 是靜態掃描工具，處理「映像／程式碼／設定本身有沒有已知問題」；Falco 是執行階段監控工具，處理「執行中的容器有沒有異常行為」。一個是體檢報告，一個是即時心電圖，缺一不可。
Q2：Falco 一定要用 eBPF 嗎？核心模組不行嗎？
核心模組仍然可用，但在現代環境中限制較多（需要 kernel headers、需要特權、部分受管服務不允許載入）。現代 eBPF 探針需要 Linux 核心 5.8 以上並支援 BTF，但部署上單純許多，是 2026 年的推薦選項。若你的節點核心較舊，傳統 eBPF 探針仍是可行的折衷方案。
Q3：Trivy 掃到的 CVE 太多了，該怎麼辦？
建議三個步驟：第一，開啟 --ignore-unfixed，過濾掉上游尚未修補的項目；第二，用 --severity 聚焦在 CRITICAL 與 HIGH；第三，針對確認不受影響的項目，用 VEX 文件正式聲明，而不是簡單地忽略。這樣既減少噪音，又保留稽核軌跡。
Q4：Falco 的告警量太大，該如何處理？
先檢視告警分布，找出貢獻最多的幾條規則。對這些規則進行精準調校（加上命名空間、標籤或映像的例外條件），而不是直接停用。同時把優先級分層，讓真正需要立即處理的告警能脫穎而出。最後，把告警導入 SIEM 做關聯與降噪。
Q5：這套架構對小型團隊來說會不會太重？
不會。Trivy 是單一執行檔，Falco 是 DaemonSet，兩者都不需要龐大的基礎設施。小型團隊可以從 Trivy 的 CI 掃描與 Falco 的官方規則集開始，先建立基本的可觀測性，再隨時間逐步調校。重點是「開始做」，而不是「一次做完美」。
本文為技術實務分享，內容基於公開文件與實際操作經驗整理。實際部署前請務必在測試環境驗證，並依組織的合規要求調整設定。若你也在 2026 年導入了 Trivy 與 Falco，歡迎在「雅寶社區 · 頂客論壇」分享你的踩坑經驗與調校心得。
```