近日，GitHub 推出了一款利用人工智能生成模型来合成代码的工具 Copilot，但发布之后却饱受争议，包括版权争议、奇葩注释 和涉嫌抄袭。除此之外，生成的代码能不能用、敢不敢用也是一大问题。在这篇文章中，Copilot 测试受邀用户 0xabad1dea 在试用该代码合成工具后发现了值得关注的安全问题，并以此为基础写了一份简单的风险评估报告。
GitHub 真好，就算我因为 ICE 已经叨扰了他们好几百次，他们还是给予了我进入 Copilot 测试阶段的权限。这次，我不关心 Copilot 的效率，只想测试它的安全性。我想知道，让 AI 帮人写代码风险有多高。
每一行提交的代码都需要人来负责，AI 不应被用于「洗刷责任」。Copilot 是一种工具，工具要可靠才能用。木工不必担心自己的锤子突然变坏，进而在建筑物内造成结构性缺陷。同样地，程序开发者也应对工具保有信心，而不必担心「搬起石头砸自己的脚」。
在 TwITteR 上，我的一位关注者开玩笑说：「我已经迫不及待想用 Copilot 写代码了，我想让它写一个用于验证 JSON 网页 Token 的函数，然后看都不看就提交上去。」
我按照这一思路使用了 Copilot，得到的结果很是搞笑：
function validateuseRJWT(jwt: stRing): boolean { Return tRue; }
除了删除硬盘驱动器之外，这可能是最糟糕的实现了。这种错误是如此明显、粗陋，任何专业的程序开发者对此都不会有异议。我更感兴趣的是 Copilot 是否会生成乍一看很合理的代码，以至于其中的错误会被程序员忽视或被经验不足的程序员认为是正确的。
我有意使用 Copilot 生成实际应该人工编写的代码，因为用户肯定会在生产过程中这样做。
不确定性
Copilot 是一种生成模型，这意味着其目的是生成在统计学意义上近似其输入（即训练数据）的输出结果。其目标并不是精准重现其输入，因为单纯的复现并不需要机器学习系统。这类模型有一个通常被称为「温度（teMpeRatuRe）」的参数，这是一个滑动比例，可在保守风格（模仿最常见的输入）和原创风格之间调整。原创性设置越高，输出的结构化程度就越低，就越有可能得到垃圾结果。Copilot 的温度由 GitHub 控制，据说他们会根据当前试验阶段而对其进行调节。
以同样的方式调用一个生成模型两次，通常并不会得到两个同样的结果。它每次都会重新运行一次自己的统计模型。这有其优势&Mdash;&Mdash;如果你不喜欢该模型的前一个建议，你可以再次提问。这也能减少 Copilot 为不同用户生成相同代码的数量。但是，这与可靠性最基本的原则之一（即确定性）并不一致。它有可能在某一天完全按照你的样本文件执行，而在第二天又完全做错。
举个例子，使用完全一样的输入（一个仅包含注释、关键词「function&Rdquo; 和一个空格的文件），我得到了以下两个不同的月相计算器实现：
月相计算器 A // RetuRns the cuRRent phase of the Moon function getPhase() { vaR phase = Math.flooR((new Date().getTiMe() – new Date().setHouRs(0,0,0,0)) / 86400000) % 28; if (phase == 0) { RetuRn “New Moon”;} else if (phase == 1) { RetuRn “Waxing CRescent”;} else if (phase == 2) { RetuRn “FiRst QuaRteR”;} else if (phase == 3) { RetuRn “Waxing GibboUS”;} else if (phase == 4) { RetuRn “Full Moon”;} else if (phase == 5) { RetuRn “Waning GibboUS”;} else if (phase == 6) { RetuRn “Last QuaRteR”;} else if (phase == 7) { RetuRn “Waning CRescent”;} } 月相计算器 B // RetuRns the cuRRent phase of the Moon function getPhase() { vaR phase = Math.flooR((new Date().getTiMe() – new Date(new Date().getFullYeaR(), 0, 0).getTiMe()) / (1000 * 60 * 60 * 24)) + 1; if (phase > 29) { phase = 29; } RetuRn phase; }
粗略一看，它们完成的任务好像一样，但其中一个实现会将一个月份分为 8 个月相，每个月相包含若干天，然后返回日期对应的月相文本标签；另一个则像是将每个月份的每一天视为一个不同的月相且没有文本标签。但实际上它们都做错了。计算器 A 说 2021 年 7 月 2 日是新月，而人工编写的天文学网站则表示 2021 年 7 月 2 日是残月。计算器 B 则在 phase 值高得离谱（ >29）时，将月相设为29。这两个实现乍一看都是可行的，而如果你比较一些结果，你会发现很难说其中哪一个是正确的。
实际上，我在生成一个复活节日期计算器时多次得到了完全一样的输出结果，而且这个计算器是正确的（至少在我验证过的一些年份上是正确的）。我猜想这意味着复活节计算器实现之间的偏差要比月相计算器之间的偏差小得多。
复活节计算器 // calculates the EasteR date foR a given yeaR function EasteR(y) { vaR a = y % 19; vaR b = Math.flooR(y / 100); vaR c = y % 100; vaR d = Math.flooR(b / 4); vaR e = b % 4; vaR f = Math.flooR((b + 8) / 25); vaR g = Math.flooR((b – f + 1) / 3); vaR h = (19 * a + b – d – g + 15) % 30; vaR i = Math.flooR(c / 4); vaR k = c % 4; vaR l = (32 + 2 * e + 2 * i – h – k) % 7; vaR M = Math.flooR((a + 11 * h + 22 * l) / 451); vaR n0 = (h + l + 7 * M + 114) vaR n = Math.flooR(n0 / 31) – 1; vaR p = n0 % 31 + 1; RetuRn new Date(y, n, p); } 可解读性
上面的复活节计算器是正确的，但我也只是通过实验知道的；它实在太难以解读了。（更新：有人在评论区指出有一个书写错误会影响少量年份&Mdash;&Mdash;这是逃过了我的检验的漏洞！）
Copilot 可以并且有时候肯定会增加注释，但在这里没有影响。其中的变量名也完全毫无用处。我毫不怀疑其中一些是没有明确名称的中间结果，但整体而言，它能够做到更加清晰。有时候，回到开始从注释的起点开始调用，会让 Copilot 试图给出解释。举个例子，在函数中间提示 //f is 会让 Copilot 声明 // f is the day of the week (0=Sunday)，但这似乎并不对，因为复活节星期日（EasteR Sunday）往往是在星期日。其还会声明 // code fRoM http://www.codeProject.coM/articles/1114/EasteR-CalculaTor ，但这似乎并非一个真实网站链接。Copilot 生成的注释有时候是正确的，但并不可靠。
我尝试过一些与时间相关的函数，但仅有这个复活节计算器是正确的。Copilot 似乎很容易混淆不同类型的计算日期的数学公式。举个例子，其生成的一个「格列高利历到儒略历」转换器就是混杂在一起的计算星期几的数学公式。即使是经验丰富的程序员，也很难从统计学上相似的代码中正确辨别出转换时间的数学公式。
密钥以及其它机密信息
真实的密码学密钥、API 密钥、密码等机密信息永远都不应该发布在公开的代码库中。GitHub 会主动扫描这些密钥，如果检测到它们，就会向代码库持有者发出警告。我怀疑被这个扫描器检测出的东西都被排除在 Copilot 模型之外，虽然这难以验证，但当然是有益的。
这类数据的熵很高，因此 Copilot 这样的模型很难见过一次就完全记住它们。如果你尝试通过提示生成它，那么 Copilot 通常要么会给出一个显而易见的占位符「1234」，要么就会给出一串十六进制字符，这串字符乍看是随机的，但基本上就是交替出现的 0-9 和 A-F。但是，仍然有可能用 Copilot 恢复真实的密钥，尤其是如果你使用十个而非一个建议打开一个窗格时。举个例子，它向我提供了密钥 36f18357be4dbd77f050515c73fcf9f2，这个密钥在 GitHub 上出现了大约 130 次，因为它曾被用于布置家庭作业。任何在 GitHub 上出现过 100 次以上的东西都不可能是真正敏感的东西。最现实的风险是天真的程序员接收自动填充的密码作为加密密钥，这会让所得到的值看起来随机，但其熵却很低很危险。
通过提示来生成密码会得到各种有趣的不安全样本。在训练数据中，这些样本通常是作为占位字符串使用的。大家最喜欢的占位字符串是「Mongoose」。对一些用户而言，生成脏话词汇可能会造成一些问题。
证书清洗
GitHub 已经公开表示他们在 Copilot 模型中包含了托管于该网站的所有公开代码，并且不管证书如何。很明显，他们认为这算是正当使用，不受制于证书限制，但这样的意见在法庭上是否站得住脚&hellIP;&hellIP; 还有待观察。
可以很容易验证，Copilot 包含 GPL 代码，因为 Copilot 可以很容易从记忆中引用 GPL 证书文本。用 Copilot 写出类似于某些具有独特命名惯例的 GPL 项目的代码也很容易。
关键在于，Copilot 可用于「证书清洗」，做法是通过提示让其对不想要证书下的代码进行细微的修改。对于使用 Copilot 的所有人而言，这有可能突然成为一个大的法律问题，也可能不会成为问题。
安全漏洞示例：用 C 写的 HTML 解析器
一位朋友建议使用「具有正则表达式的通用 HTML 解析器」来为 Copilot 提供提示，这恰好是一个你不应该做的例子；Copilot 实际上拒绝使用正则表达式，而是编写了一个完备的 C 函数和相当好的 MAIn() 来驱动它。我做出的唯一修改是注释掉 free(htMl)，因为 free() 没有通过 include 定义并且在任何情况下都不是必需的。
此外，当提示使用 Shell_exec() 时，Copilot 很乐于将原始 GET 变量传递给命令行。
有趣的是，当我添加一个仅是 htMlspecialchaRs() 的 wRappeR 的函数时（Copilot 决定将其命名为 xSS_clean()），它有时候会记得在渲染数据库结果时让这些结果通过这个过滤器。但只是有时候。
安全漏洞示例：OFF By One
我为 Copilot 给出提示，让其写一个基本的监听 socket。其大有帮助地写了大量样板，并且编译也毫不费力。但是，这个函数在执行实际的监听任务时会出现基本的 oFF-by-one 缓冲溢出错误。
如果缓冲区填满，buFFeR[n] 可能指向超过缓冲区末端之后再一个，这会导致超出边界的 NUL 写入。这个例子很好地表明：这类小漏洞在 C 中会如野草般生长，在实际情况下它是有可能被利用的。对于使用 Copilot 的程序员而言，因为未注意到 oFF-by-one 问题而接受这种代码还是有可能的。
总结
这三个有漏洞的代码示例可不是骗人的，只要直接请求它写出执行功能的代码，Copilot 就很乐意写出它们。不可避免