Skip to main content

Yak 的前世今生

Yak 语言本身并不是一个凭空出现的项目。

从企业需求中诞生:合理的引擎需求#

早在近两年,我在参与企业安全建设过程中,提出并实现了一套非常棒的企业安全平台架构,用来把所有的扫描能力,HIDS 源数据,数据处理能力,审计能力做了整合; 使得我们在同一个平台中,可以获取并同时以上帝视角分析这类数据,得到综合的安全分析的结论;但是由于数据纬度很多,我们编写一些基本的规则表现力并不够完成我们想要的分析。 所以,我们需要一个嵌入式语言。

甚至我们想把一些分析/规则能力分散到节点中,减轻中心服务器压力。

技术起源:嵌入式语言演变#

如果是 Java 的话,这事儿很好解决,我们甚至有 groovy 等等表达式语言/嵌入式脚本语言去和代码进行无缝对接;但是由于技术栈的关系,我们并不能使用这些技术; Golang 技术下可选的嵌入式语言并不算多。

经过一些技术调研之后,我选择了当时一个 qiniu/qlang 这个项目(原项目已不在维护,变成了 Goplus)。

感谢 @qiniu 的开源协议与精神。

虽然 qiniu/qlang 仍有很多 BUG,但是经过我一段时间耐心的修改和调教,实现了很多 qlang 未实现的功能,同时也解决了很多他作为嵌入式语言的问题, 终于可以初步把他应用在我的安全平台中了。

第一次露脸:xray/rad 参与建设企业安全#

当我们集成进平台中,效果其实非常棒,我们可以用它做太多事情了

  1. 在文章中,我调用了 xray/rad 完成了漏洞扫描的一些能力;
  2. 同时,基础的规则审计,报告生成,动态通知我们都用了这门神奇的嵌入式语言来参与我们的建设;

此时,我们已经完成了初步的:"安全融合" 的概念,我们把能力和规则与平台进行了融合。

当然,虽然我们只融合了当时供职单位中的数据和安全能力,但是不可否认的是,这个"融合行为",和 API 互相调用有着本质区别,在人力/研发资源不够的客观因素下,真的解决了太多的问题了

巅峰:分布式脚本执行引擎#

作为一个勉强能说是 "研发人员" 的我来说,喜欢抽象化/泛化/有梦想做"鸡架"(基础架构)的人来说,其实上面说的很多能力,代码越少越好,嵌入式规则脚本越多越好。 所以,我们又对这门嵌入式语言进行了审计,我们移除掉了他与数据库的强绑定关系,他可以同时运行在分布式的节点中【参考我在这篇文章中提到的架构】

我们的节点更加的泛化了,他能执行我们专属的嵌入式语言。

这取得了令我自己都吃惊的效果:

  1. 几行实现了分布式 xray 调用
  2. 一个脚本实现了分布式端口扫描
  3. 任何复杂的数据分析与审计流程都可以在节点上实现
  4. ...

以前这些超级复杂的能力,现在居然这么简单就能实现?

又造轮子?我们开放这门语言吧!就叫 Yak#

聊到了我做了的这些事情,大家有些人要说:"这不就是造了个轮子吗?"

但是... 我真的是在造轮子吗?当然,我并不觉得我是在造轮子,可能大家会说,你这门语言里的类似的东西,我在 "XXX" 见过;但是,你想把它工程应用需要多久呢?需要付出怎么样的人力物力呢? 解决工程问题,创造更好的生产工具则是非常好的解放生产力的方案,生产力解放了,大家就有更多的时间做安全研究了,从而又可以创造更棒的生产力工具,这本来就是事物良性发展的客观规律。

所以,我们从最初的平台中,把这个语言抽离出来,单独做了一个项目,阉割掉了 "企业需求",留给大家一个 "安全工具大融合" 的新语言 Yak。同时我们努力新加入/新集成了更多的新朋友:

  1. nuclei:不造轮子,MIT协议集成
  2. fuzz:市面唯一 Web Fuzz 全套解决方案
  3. ...

最终,它变成了现在的样子。