Codeql 在对某些语言的规则添加上使用了 Models as Data (MaD)的方式。
这种方式让使用者可以简单的添加 yaml 文件（数据拓展文件），就将想要的代码特征注入到codeql 检查引擎中。看起来非常好用。有点像以前fortify 的方式了，但是比fortify简单多了。
本文目标：
学习Codeql 数据拓展文件 编写，设计一个 简易的添加规则的小脚本。
因为官方的vscode插件虽然提供了写规则的能力，但是我觉得不够简单，我要的是脱离codeql 进行快速的添加规则。
数据拓展文件简单说明
本文关注的编程语言：
java,go。
其他语言在 数据拓展文件的一些数据结构上可能有差异。而且本文撰写过程中还没发现在swift 中有支持这种方式的yaml文件。默认暂时codeql 不支持swift 的 MaD。
数据拓展 yaml 文件字段说明:
extensions:- addsTo:pack: codeql/go-allextensible: packageGroupingdata:- ["gokogiri/xpath", "github.com/moovweb/gokogiri/xpath"]- ["gokogiri/xpath", "github.com/jbowtie/gokogiri/xpath"]- addsTo:pack: codeql/go-allextensible: sinkModeldata:- ["group:gokogiri/xpath", "", True, "Compile", "", "", "Argument[0]", "xpath-injection", "manual"]
数据拓展 yaml文件主要是由多个addsTo开头的节点组合成的。
addsTo:
定义这个拓展，应该注入到那个codeql 包（pack)和那个可拓展谓词(extensible)。
不同的可拓展谓词，对应的data 元素的字段就不一样。我的理解是，data可能是作为参数注入到可拓展谓词的。
Data:
定义一行或多行元组，这些元组作为值注入到可扩展谓词中。列数及其类型必须与可扩展谓词的定义匹配。
可拓展谓词数据字段：
Java 语言
主要认识4个：
sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)
注意这里的第5个函数签名不需要函数名，只需要参数。
第6个字段，ext, 我还没找到使用场景，不知道干啥的。
第7个output，就是目标关键位置。
第八个表示这个数据对应的 是什么类型 source 。
第9个provenance 表示这个数据的来源。一般写手工 "manual"。
sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)
sink和 source 差不多。不重复写。
summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)
这个summary 数据拓展。 是对一些函数行为进行总结。将流经这些函数数据数据流打标，标记输入和输出位置，使得数据流不会中断。
区别在于summary 有输入输出2个位置。代表数据流向。倒数第二个kind 代表是否保留该值？
这是我个人理解。未必完全正确。
neutralModel(package, type, name, signature, kind, provenance)
中性模型neutral 当定义中性模型时会忽略同名的summaryModel
Go 语言：
sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)
sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)
summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)
neutralModel(namespace, type, name, signature, kind, provenance)
和java 基本一致。
脚本开发思路：
思路：启一个http服务。用户可以在前端选择需要添加某个类型的规则，填写参数，发送到后端，后端直接落库保存。
但是codeql 这个 MaD 建模是刚刚开始搞的东西。未来数据结构上估计会有不兼容的情况。脚本虽然好开发，但是感觉未来维护成本不低。
脚本的缺点和改进方向思路：
- 是否和官方开源规则存在重复的，重复检测？
- 整合ql-package的操作到小工具里面。这个其实就略微复杂了。不同的公司应该都有自己的安全平台，这个大家自己按照自己的平台设计去改。