Falco 无法检测 Go 程序的 panic、channel 死锁等运行时行为，因其仅监控内核系统调用，不解析 Go 二进制、不 hook runtime 函数、也不理解 goroutine 调度状态；它能捕获 Go 程序发起的 execve、openat、connect 等 syscall 行为，但纯用户态内存操作（如 goroutine 泄漏、map 并发写 panic）完全不可见。
Falco 不支持直接检测 Go 程序的运行时行为，它不解析 Go 二进制、不 hook runtime 函数、也不理解 goroutine 调度状态——它监控的是内核系统调用事件，和语言无关。
为什么 Falco 对 Go 应用“看不见”你的 panic 或 channel 死锁
Falco 工作在 eBPF 或 kernel module 层，只看到 execve、openat、connect 这类系统调用，而 Go 的 panic、http.HandlerFunc 崩溃、sync.Mutex 争用、甚至 os/exec 启动子进程前的参数构造，全发生在用户态 runtime 内部。Falco 没法感知这些。
- Falco 规则匹配对象是 syscall + 进程上下文（如
proc.name、fd.name），不是语言级堆栈或变量值 - Go 编译成静态链接二进制后，
ldd查不到动态依赖，但 Falco 依然能监控它的文件/网络行为——只要它发起系统调用 - 真正“隐身”的是纯内存操作：比如 goroutine 泄漏、map 并发写 panic、unsafe.Pointer 越界——这些根本不触发 syscall
Falco 能抓到哪些 Go 容器的真实威胁
只要你 Go 程序干了系统级的事，Falco 就能捕获。关键是识别哪些行为在容器中属于异常信号。
- Go Web 服务突然尝试写
/etc/passwd（规则：syscall.type = openat and fd.name contains "/etc" and evt.arg.flags contains "O_WRONLY|O_RDWR"） - Go agent 进程（如
my-monitor）悄悄connect到外网 C2 域名（需配合dns.name过滤，注意 DNS 查询本身是 UDP syscall，但连接是connect） - 容器内 Go 程序执行
sh或bash（proc.name in ("sh", "bash", "ash") and proc.pname = "my-go-app"），大概率说明被注入或逃逸 - 注意：
os/exec.Command("ls")会触发clone+execve，Falco 可见；但os.ReadDir是纯 syscallgetdents64，也可见
Go 容器部署时让 Falco 生效的关键配置点
默认的 Falco 镜像或 Helm chart 往往漏掉 Go 容器特有的上下文适配，导致规则失效或误报。
立即学习“go语言免费学习笔记（深入）”；
- 必须挂载
/proc和/dev（尤其是/dev/shm），否则 eBPF 探针无法读取进程 cmdline 和内存映射 —— Go 静态二进制的proc.cmdline就靠这个 - Go 容器若用
scratch基础镜像，要确保 Falco daemonset 的securityContext.privileged: true已启用，否则 eBPF 加载失败，日志里会出现"could not load probe: operation not permitted" - 避免用
CGO_ENABLED=0构建的 Go 二进制做 Falco 测试主体：它不带符号表，proc.exepath可能为空，影响基于路径的规则（如fd.name startswith "/tmp/"） - 在 Kubernetes 中，给 Go Pod 加
app.kubernetes.io/name: my-go-api标签，并在 Falco rule 的container.image.repository或k8s.pod.name条件里引用，比硬编码进程名更可靠
真正难的是把 Go 应用层异常（如 HTTP 500 爆涨、pprof 暴露、/debug/pprof/goroutine?debug=2 返回千行栈）映射成 Falco 能理解的 syscall 模式。这中间没有自动翻译层，得靠你判断哪次 write 是日志刷盘、哪次是恶意数据外泄。
