把安全日志交给本地AI分析师：一个SOC工程师的Gemma 4实验

安全运营中心（SOC）的分析师每天被警报淹没。一个IP扫描了端口，一条恶意签名被触发，某个进程行为异常——这些事件单独看都是噪音，但连在一起可能就是一次完整的入侵链条。问题在于，人类分析师需要时间把它们串起来，而时间往往是安全响应里最稀缺的资源。

一位开发者最近开源了一个实验性项目：NetGuard Gemma 4 Local SOC Analyst。核心思路很直接——让Gemma 4在本地扮演分析师角色，读取一批经过脱敏处理的安全日志，输出结构化的入侵事件报告。不是摘要，不是聊天，而是真正的关联分析。

这个项目针对的是一个小而具体的痛点。主流安全仪表板告诉你"什么触发了警报"，但不总是告诉你"发生了什么"。当你面对Suricata或Wazuh风格的日志流时，单条警报只是碎片。Gemma 4在这里的任务是读取一个事件窗口，把相关活动连成叙事：攻击阶段、受影响资产、建议的缓解措施，以及置信度评分。

技术实现上，项目选择了本地优先的架构。Gemma 4 E4B Q8_0通过Ollama在本地运行，推理端点是POST /analyze-logs。输入端有严格的预处理：日志先经过脱敏器，把内部IP、用户名、主机名等敏感值替换掉，但保留事件结构。 oversized的日志窗口会被直接拒绝，防止本地推理过载。

开发者提供了一组多阶段攻击的样本日志作为测试用例。典型的场景包括：初始侦察（端口扫描）、漏洞利用尝试、可疑进程执行、以及后续的横向移动迹象。Gemma 4需要识别的不只是单点异常，而是"这个扫描之后跟着那个利用，然后出现了命令执行"的时序关系。

输出格式被强制约束为结构化JSON，包含四个字段：攻击阶段分类、受影响资产清单、具体缓解建议、以及整体置信度。这种设计是为了让下游的SOC工作流能直接消费——人可读，机器也可解析。

选择E4B而非更大的模型版本，是出于实用性的权衡。项目目标是在本地硬件上跑通，而不是依赖托管的大模型。安全日志的敏感性决定了"数据不出本地"是硬需求，而Gemma 4的E4B版本在参数量和推理成本之间提供了可行的平衡点。

项目的GitHub仓库显示，最终本地审计通过了11项测试。代码层面包含了基础的安全防护：输入大小限制、脱敏流程、以及本地推理的隔离。演示视频展示了完整的流程：从原始日志到脱敏窗口，再到Gemma 4生成的结构化报告。

开发者明确区分了这个项目的定位。它不是单条警报的摘要工具，而是"log-window autopsy"——日志窗口解剖。单条警报告诉你"有可疑行为"，事件序列告诉你"入侵的故事"。Gemma 4的价值在于连接多点证据，生成分析师风格的报告。

下一步的规划指向更完整的SOC集成：实时日志流接入、可定制的分析策略、以及历史事件关联。目前的版本是一个概念验证，证明本地运行的开源模型可以承担需要上下文理解的安全分析任务，而不必把敏感遥测数据发送到外部API。

这个实验的意义或许在于验证了一种可能性：当模型足够小、足够快、足够本地化时，它可以嵌入到对延迟和隐私极度敏感的工作流中。对于预算有限或合规要求严格的中小团队，这可能是一种现实的替代方案——不是取代人类分析师，而是把他们的注意力从日志关联的机械劳动中释放出来。