自动化 CI 的安全问题

最近几天在处理 LCTT 的 CI 迁移问题，在处理过程中，我觉得有必要聊一下 CI 的安全问题。

对于现在的开源项目而言，CI 几乎是标配，有了 CI，才可以很好的处理贡献者的贡献，机器完成一些检查，降低人工核验的压力。

但如果你的 CI 没有处理好，就可能为你的项目带来安全隐患。

现行的 CI 大多是基于一个配置文件进行的，比如 TravisCI 的 .travis.yml 、GitHub Action 的 .github/workflows/xxx.yml 等。我们会在其中撰写一些代码，来完成我们的核验功能。

不过，在实际的研发过程中，处于代码格式化、代码工程化等方式，我们可能会考虑将其中的一部分放在项目的一些子目录中来存储。

不过，将脚本放在项目工程中的单独文件也引入了安全问题。

一般来说， CI 在执行命令的时候，会依赖源分支的配置文件进行，因此，我们无需担心相应的配置文件被篡改。

但 CI 在执行本地的脚本的时候，是使用的是当前分支下的文件，这就会为项目的留下安全隐患，比如一些恶意的开发者可以将恶意代码插入相应的脚本中，从而窃取一些重要的信息，比如各种 Secret 之类的。

想要解决有两个思路：

1. 不在项目文件中放置 CI 所需的资料：将脚本中的命令放置在配置文件中存储，就可以避免恶意开发者修改 CI 文件。因此修改的 CI 文件并不会被执行。
2. 将 CI 所需文件放置在另外一个地方：现行的 CI 都提供了常用的命令，你可以将所需的配置文件放置在另外的 repo 下，并在 CI 流程中，加入相应的 clone 或下载，从而确保在 CI 执行的过程中有所需的文件。这样只需要确保另外保存的 repo 中没有相应的恶意文件即可。

总结

CI 是个好东西，但如果你的写法和用法有问题，依然会为你的系统带来安全风险。