关于github:自动化-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 是个好货色，但如果你的写法和用法有问题，仍然会为你的零碎带来平安危险。