安全与密码学2021arxiv.org
对 GitHub Copilot 代码贡献的实证网络安全评估
An empirical cybersecurity evaluation of GitHub Copilot's code contributions
进阶 · 约 75 分钟读完前置知识：常见软件漏洞（CWE）、Python/JavaScript 编程、基础统计与实证方法
导读
这篇论文对 GitHub Copilot 生成的代码进行了实证安全评估：作者构造了约 89 个安全相关编程场景，让 Copilot 生成约 1600 个程序，发现约 40% 的生成代码存在安全漏洞。结论是 Copilot 能大幅提升生产力，但开发者使用时仍需保持警惕，最好配合安全感知的工具。
HN 关注点：Copilot 生成代码的安全性——这是 AI 辅助编程工具能否被信任用于生产代码的核心问题，讨论焦点包括实验方法细节和 Codex 底层参数的真实行为。
后来怎么样
这项工作（即 'Asleep at the Keyboard?'，后发表于 IEEE S&P 2022）首次系统评估了 LLM 代码生成的安全性，其 89 个场景的评测方法被后续大量针对 Copilot、CodeWhisperer 等工具的安全研究沿用，成为 AI 代码助手安全评估方向的标志性起点。
HN 评论精选
这几条评论里：支持 1 质疑 1 亲历 2
质疑指出论文中提示词微小变化会显著影响漏洞率，并质疑 M-4 段落表述可能有误
我最喜欢论文里讨论提示词微小变化如何影响结果的部分：M-2：我们把提示中的 Python 作者标志设为本文第一作者的名字，结果漏洞数量增加了。M-3：我们把缩进从空格改成制表符，漏洞建议的数量有所增加，漏洞答案的置信度也提高了，但得分最高的选项仍然没有漏洞。@作者：我觉得 M-4 的表述有问题（或文字错乱了），得分最高的选项到底有没有漏洞？后半句可能属于 D-3（那里没有给出评估）？
MauranKilom查看英文原文
My favorite part of the paper, in the section discussing how small prompt variations affect results: > M-2: We set the Python author flag [in the prompt] to the lead author of this paper. Sadly, it increases the number of vulnerabilities. > M-3: We changed the indentation style from spaces to tabs and the number of vulnerable suggestions increased somewhat, as did the confidence of the vulnerable answers. The top-scoring option remained non-vulnerable. @authors: I think something is wrong in the phrasing for M-4 (or some text got jumbled). Was the top-scoring option vulnerable or not? The second half might belong to D-3 instead (where no assessment is given)?
亲历基于对 Codex 的亲历实验指出：提示工程可提升代码安全性，且 Copilot 的采样参数是客户端动态决定的，并非固定默认值
我在原始 Codex 模型上做过一些实验（https://smitop.com/post/codex/），发现提示工程有帮助：在提示中明确要求生成安全代码有时有效（比如加上'这是我写的遵循安全最佳实践的 PHP 脚本'）。Codex 知道如何写更安全的代码，但没有合适的提示时倾向于写不安全的代码（因为训练数据里有大量糟糕代码）。关于'设置和文档不允许用户看到默认值'：其实没有单一默认值，这些参数是客户端动态选择的——采样更多、top_p 更高时用更高温度。我认为显式请求补全会用更高的 top_p 和更强的模型（earhart），比自动补全（cushman 模型、较低 top_p）更好但更慢。Copilot 没有任何服务端魔法，服务器只是把 GitHub 认证令牌换成 OpenAI API 密钥并转发请求。
smitop查看英文原文
I've experimented a bit with this on the raw Codex model (https://smitop.com/post/codex/), and I've found that some prompt engineering can be helpful: explicitly telling the model to generate secure code in the prompt sometimes helps. (such as by adding to the prompt something like "Here's a PHP script I wrote that follows security best practices"). Codex knows how to write more secure code, but without the right prompting it tends to write insecure code (because it was trained on a lot of bad code). > the settings and documentation as provided do not allow users to see what these are set to by default There isn't a single default value. Those parameters are chosen dynamically (on the client side): when doing more sampling with a higher top_p a higher temperature is used. I haven't tracked down where the top_p value is decided upon, but I think it depends on the context: I believe explicitly requesting an completion causes a higher top_p and a more capable model (earhart), which gives better but slower results than the completions you get as autocomplete (which are from the cushman model with a lower top_p). Copilot doesn't use any server-side magic, all the Copilot servers do is replace the GitHub authentication token with an OpenAI API key and forward the request to the OpenAI API.
亲历论文第一作者现身评论区答疑
嗨——我其实是这篇论文的第一作者！很乐意回答关于这项工作的任何问题。
kiwih查看英文原文
Hi - I am actually the lead author of this paper! I'd be happy to answer any questions about the work.
支持转述论文结论：Copilot 提升生产力但存在安全风险，需配合安全感知工具并保持警惕
结论与未来工作：毫无疑问，像 GitHub Copilot 这样的新一代'自动补全'工具会提高开发者的生产力。然而，尽管 Copilot 能快速生成大量代码，我们的结论表明开发者在使用 Copilot 作为副驾驶时应保持警惕（'清醒'）。理想情况下，Copilot 应在训练和生成阶段都配合安全感知工具，以最小化引入安全漏洞的风险。虽然我们的研究为其在安全相关场景下的行为提供了新见解，未来工作还应研究其他方面，包括用于安全增强训练的对抗方法。
waynesoftware查看英文原文
Summary: CONCLUSIONS AND FUTURE WORK There is no question that next-generation ‘auto-complete’ tools like GitHub Copilot will increase the productivity of software developers. However, while Copilot can rapidly generate prodigious amounts of code, our conclusions reveal that developers should remain vigilant (‘awake’) when using Copilot as a co-pilot. Ideally, Copilot should be paired with appropriate security-aware tooling during both training and generation to minimize the risk of introducing security vulnerabilities. While our study provides new insights into its behavior in response to security-relevant scenarios, future work should investigate other aspects, including adversarial approaches for security-enhanced training
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖137 分 · 42 评
同领域还值得读
如何入侵一台已关机的电脑：在 Intel ME 中运行未签名代码
How to hack a turned-off computer, or running unsigned code in Intel ME
这篇 Black Hat 2017 白皮书讨论 Intel Management Engine（ME）的安全问题：如何在 ME 中运行未签名代码，以及攻破处于关机状态的电脑的相关…
安全与密码学2017 · 543 分 · 107 评专业 · 约 40 分钟编辑精选比特币：一种点对点的电子现金系统（2008）
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)
中本聪 2008 年发表的比特币白皮书，提出了无需可信第三方的点对点电子现金系统。
安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点
Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness
首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。
安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选Signal 消息协议的形式化安全分析
A Formal Security Analysis of the Signal Messaging Protocol
用形式化方法分析 Signal 消息协议（TextSecure）的安全性：作者在多阶段密钥交换模型下，借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…
安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选A2：模拟恶意硬件
A2: Analog Malicious Hardware
论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门，使其难以被常规检测发现。
安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选