Read More and Code More

又到了几周一度的逼逼时刻，还是那句话，且看且珍惜。但本文只是笔者一家之言，仅仅代表笔者，不代表任何组织观点，有不同看法或者发现错误的朋友欢迎留言交流。

虽然十分不想在公众号上蹭热度，但笔者最近意识到，不管人类愿不愿意接受，大模型正在改变人类的工作方式和生活方式，那索性就敞开聊，放开蹭。周末的时候看到奇安信DataCon的WP出来了，就花了点时间将笔者感兴趣的部分看了下，自己实现了一遍，有了一些新的理解，这里记录和分享下。 这一篇主要聊一聊0817iotg战队的WP，整个WP的解读和分析分为两篇：漏洞情报提取和漏洞挖掘，这篇先简单谈一下漏洞情报提取。

该战队主要是将大模型应用到漏洞情报提取和漏洞挖掘上，详细的内容可以参考：https://mp.weixin.qq.com/s/9zQdXLqdiFdzrcp-8MM-7Q

团队在解决这个问题的时候，花了一定的时间在处理输入上，包括图片，html，上下文过大等问题。这些不是笔者关注的部分，因为这些问题都是共性问题，已经有一些比较好的解决方案了，所以就不展开分析了。在整个方案中，笔者最感兴趣的部分莫过于他们设计的投票系统。他们设计了三种投票模式：

1. "2+1"策略
2. "1否3"策略
3. ">2"策略

这三种策略的解释分别为：

1. 针对较为直观的漏洞信息如 CVE 编号等，首先进行两次提问，如果两次提问不一致，进行第三次提问，并最终选择第三次结果，以此降低不确定性。
2. 关于是否存在 POC 以及对 POC 的解释，由于这一部分大模型的判定显示了更大的随机性，我们进行了四次判定。根据实际尝试经验，大模型倾向于将牵强的 POC 与解释算作存在解释，只有较低概率下能够正常判断出解释牵强不算解释这样的情况，因此，我们这里选取了带优先级的投票模型：进行四次投票，大模型的判定结果只要出现一次有 POC 但无解释，优先输出此结果，如果出现没有POC但有解释的悖论情况，将有解释矫正为无解释。
3. 针对文章是否与漏洞相关，考虑到判断与漏洞无关时全部输出维度都将为 NULL，将会遗漏很多重要信息，我们要求四次投票中至少存在两票时才判断与漏洞无关。

虽然在WP中并未提到这三种策略提出的依据，但根据笔者的经验，这些策略大概率是根据漏洞情报字段来制定的。我们可根据漏洞字段的重要性，将其分为三类：

1. 基础字段：指漏洞基本信息，包括漏洞的CVE编号，漏洞影响的厂商产品等
2. 重要字段：决定了是否需要做进一步处理，如果不与漏洞相关，直接返回即可
3. 关联字段：有依赖关系的字段，例如当is_POC为true的时候，is_explain大概率也为true

基础字段只需要降低其不确定性；关联字段则需要参考字段的相关性；重要字段则需要着重对待，分别对应了上述的三种策略。

设计有趣的地方

1. 维护了简单的厂商产品映射关系，通过该关系表对LLMs进行矫正，解决一些厂商产品的问题
2. 额外处理了易混淆的编程语言：C和C++

2+1策略的合理性和实现问题

笔者简单看了下该战队的实现，发现2+1策略的实现略微有点问题，2+1策略说人话如下所示：

# vendor_list表示厂商白名单先生成两次结果1. 如果两次结果的内容是一样，则使用任一结果即可2. 如果两次结果不一致： 1. 如果结果1在vendor_list中，但结果2不在vendor_list，则使用结果1 2. 如果结果1不在vendor_list中，但结果2在vendor_list，则使用结果2 3. 如果结果1和结果2都不在vendor_list中，生成结果3，  1. 如果结果3在vendor_list中，则使用结果3  2. 如果结果3不在vendor_list中，并且结果1和结果2不相等   1. 如果结果3和结果2一致，则使用结果2   2. 如果结果3和结果1一致，则使用结果1   3. 如果都不一致，则使用结果3

该策略的有效性与LLMs的随机性有关系，通过多次的随机事件，降低生成结果的不确定性，常见的控制大模型随机性的参数就是temperature。所以在实际应用中，一定不能将该值设为0。

局限性

在真正的生产中，这套方案会有一些问题：

1. 厂商产品的处理，在真实的环境中，厂商产品的处理往往就是件很困难的事情
2. 前面提前的LLMs生成结果的随机性
3. 投票机制的设计，可能会有一些更加数学的方法？

笔者为了锻炼自己的代码能力，将这个WP基本上实现了一遍。但由于笔者是个懒狗，所以vote部分并未完全写完，有兴趣的读者可以后台私信笔者，一起把vote部分补全。另外，有没有读者对打DataCon感兴趣，今年可以相约DataCon啊！最后，现在很多人都存在大模型焦虑，觉得自己马上立刻即将原地失业。其实笔者想说：大模型是讲道理的，不要神话它也不要轻视它，多去使用它拥抱它。大模型应用很美，但实现的过程很难，同样的思路可能某一些细节处理不到位，结果也会是千差万别的。