把内核里发生的事，翻译成 MITRE ATT&CK 上的技术编号，能不能自动做？
简单说，这周有篇论文把整条流水线跑通了，全程本地推理。
流水线叫 Trace2ATT&CK。eBPF 收内核事件，把攻击者的命令串成溯源图，图压成紧凑表示，再让 LLM 挑技术编号。输出不是一个答案，是排好序的候选，每条附一段理由。
论文 9 月 11 号挂上 arXiv，编号 2609.12841，归 cs.CR，cs.AI 也挂在下面。四位作者，名字不列了，想看的直接搜编号。
为什么以前难
论文里有一句我认同：现有的自动映射方法大多靠 CTI 报告喂。
报告是回溯性的。攻击打完，有人写下来，你才拿去映射。事后复盘够用，往前拦就晚了。
内核层的系统调用不一样。它是现场证据，机器自己一直在产生。
麻烦在量和杂。原生 syscall 流直接丢给模型，等于把几百页没标点的流水账塞给一个人看。
三个动作
一是把攻击者的命令串成溯源图。谁调用了谁，谁改了哪个文件，这类关系连起来，就是一张有结构的图。
我理解这一步做的是降噪加保结构。信息量没减多少，可读性完全是另一回事。
二是用图表示，不用原始遥测。这一条在评测里被单独对照过。
三是映射本身。论文试了两种：纯 prompt，和在 ATT&CK 知识库上做检索增强的 RAG。
评测怎么算分
347 个 Linux Atomic Red Team 用例，模型是本地部署的开源权重。
Atomic Red Team 那批东西本质是一堆能复现的小型攻击剧本。有剧本就有标准答案，才谈得上算准不准。
所以 347 这个数本身不说明准确率高。它只说明一件事：作者愿意被算分。这跟在一两个案例上做个 demo，差别挺大。
两个结果。RAG 稳定好过纯 prompt。图表示明显好过原始遥测。
后面那句还带了作者的结论：本地推理加上基于图的行为描述，能让内核遥测的自动映射在运营上站得住，同时不用牺牲数据保密性。
我会记住哪一条
图那条。
原始日志不是给模型看的好输入，中间那层压缩才是关键。这话听着像常识，可真去翻工具链，多数做法还是把原始文本往里塞，然后指望模型自己扛住噪音。
Trace2ATT&CK 是先做结构，再交给模型。跟"把窗口开大点"是两条路。我更信前面那条。
第二件是本地跑。安全团队不肯把内核遥测传到云端，这不是技术问题，是合规和常识。一个必须在云端才成立的方案，在这类场景里基本等于没方案。
还有个小设计我挺喜欢：输出带理由，不只是编号。理由这东西，分析的人能质疑，能快速排除，比一个光秃秃的结论有用得多。
我没吃透的地方
ATT&CK 那套编号我只懂个轮廓。论文挑的是哪些技术、粒度合不合适、347 个用例覆盖得全不全，这些我判断不了。
还有 RAG 在这儿为什么有用。我有个粗糙的解释：ATT&CK 知识库本身就是一本对照手册，检索等于先把手册翻到相关那几页再让模型读，而不是指望它把整本背下来。
听着合理。但论文里那个对照实验具体怎么控制变量，我没细看。先放在这里，等我搞明白再补一句。
这对普通人意味着什么
大概率什么也不意味着。这是安全运营的活，离日常很远。
但那个思路可以抄。不管你手里在做哪个 agent，先把原始输入压成有结构的一层，再喂给模型，通常比反复调 prompt 管用。
我上期说上下文窗口开大能解决不少问题，这话得往回收一点。窗口解决的是容量，解决不了噪音。这两件事我以前有点混着讲。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。