自从Anthropic发布Mythos以来，软件安全一下子成了焦点。多个知名产品遭遇了数量级惊人的新型攻击，这些攻击可能泄露数据、破坏系统，或者干脆让信息安全和SRE团队的日子变得苦不堪言。但一个有意思的发现是，这一切的代价都极其高昂，只有大公司和拿到风投的前沿实验室才烧得起。比如，OpenAI刚刚宣布在Linux内核中发现了1000个漏洞，平均每个漏洞的发现成本是1000美元。其工作方式是，一个前沿LLM模型通读源代码，分析代码的写法、入口点，然后最终开始评估这些代码能否通过一个或多个攻击向量被利用。这种做法虽然可行，但当LLM需要处理摄入源代码中的数百万token、再加上推理环节的数千到数百万token，以及最后的输出时，它既不是确定性的，也不便宜。于是我开始琢磨，能不能反过来做，让它更便宜？思路是，为什么非要让LLM包揽整个发现、枚举、验证和报告的全过程？为什么不把LLM用在它擅长的地方，让其他一切环节都变成确定性的？于是就有了「代码上下文驱动的漏洞扫描器」这个想法。整个项目有5个核心阶段：代码上下文图：把整个源代码映射为一张代码上下文图，其中每一条关系和类型都得到解析。利用这张代码上下文图找出用户数据的入口点（Sources）和最终汇聚点（Sinks，数据库、文件、远程服务器调用等），并追踪从source到sink的路径。流向判定阶段：把整条从source到sink的路径喂给一个LLM，让它能够有把握地对这条路径进行推理。LLM还会获得一个查询预算，用来补齐任何缺失的细节。输出要么是「流向确认」（未净化的用户数据从source到达了sink），要么是「阻断」（数据不可能在未经净化的情况下从source传到sink）。条件阶段：LLM进一步搜索代码上下文图，验证这条流向要成立需要满足哪些条件，或者项目的默认设置是否已经阻止了它。输出与流向阶段类似。对抗性挑战：再由另一类LLM对判定为「流向确认」的案例进行推理。这个阶段经过调校，会尽最大努力去反驳前面阶段得出的结论。如果这个阶段无法反驳该流向，那么这条特定路径就升级为「确认发现/漏洞」。这套东西已经测试了一周，并以CodeQL（Github出品的业界标准静态代码漏洞扫描器）作为参照进行比对。在一天运行中，花费约20美元、覆盖5个开源项目，该项目已提交了10个漏洞，严重程度从MEDIUM到CRITICAL不等。其中4个已获确认，6个正由相应开源项目的安全团队调查中。有意思的是，在提交的10个漏洞中，只有2个被CodeQL现有已发布的规则集检测到，另外8个完全是新颖的。评论URL：https://news.ycombinator.com/item?id=50412336 点数：1

评论数：0