一次拉取，全部清除
内容提要
2025年7月，亚马逊Q Developer编码助手遭恶意代码注入攻击，攻击者通过GitHub拉取请求植入破坏性指令，但因格式错误未执行。文章指出AI代理无法区分合法与恶意指令，缺乏人类谨慎，强调需通过外部策略门控、短期凭证和严格构建流程防范此类供应链攻击。
延伸解读
供应链攻击的隐蔽性
此次攻击通过一个看似普通的GitHub拉取请求，将恶意指令注入到构建脚本中，最终随扩展发布到近百万开发者。攻击者利用的是构建流程中的信任链，而非直接攻击终端用户。这提醒我们，开源软件的供应链环节，尤其是自动化构建和发布流程，可能成为攻击的切入点，且难以被常规审查发现。
AI代理与人类判断的差异
文章指出，AI代理无法区分合法指令与恶意注入，且缺乏人类因后果担忧而产生的犹豫。这种差异意味着，依赖AI代理自主执行操作时，必须设置外部控制机制，如策略门控和人工确认，而不能仅依赖代理自身的判断。否则，一旦指令被篡改，代理可能毫无保留地执行破坏性操作。
凭证管理的关键性
攻击的根源在于一个权限过大的GitHub访问令牌，它被用于构建服务，使攻击者能直接提交恶意代码。这凸显了凭证管理的重要性：应使用短期、最小权限的凭证，并定期轮换，以降低被滥用的风险。同时，构建管道应被视为攻击面，需要加强分支保护、强制审查和签名发布等措施。
Q&A
2025年7月亚马逊Q Developer遭遇了什么攻击？
2025年7月，攻击者通过GitHub拉取请求向亚马逊的aws-toolkit-vscode仓库植入恶意代码，该代码在构建时下载外部文件并注入指令，试图让Q Developer删除文件系统和云资源。由于指令格式错误，攻击未成功执行。
为什么Q Developer无法识别恶意指令？
因为AI代理无法区分指令是来自合法渠道还是被注入的，它缺乏人类基于直觉和情感产生的怀疑和谨慎，因此无法识别恶意指令。
这次攻击为什么没有造成实际破坏？
因为注入的指令包含一个格式错误，导致代码未能执行。攻击者声称这是故意的，目的是引起对安全问题的关注。
Q Developer还存在哪些其他安全漏洞？
独立研究员发现Q Developer会在未经许可的情况下运行bash命令（如find），可能被利用泄露文件或触发远程代码执行。该漏洞在2025年7月被报告后迅速修复，但未发布CVE。
如何防范类似的AI代理供应链攻击？
防范措施包括：使用外部策略门控（如Open Policy Agent）对代理的操作进行审批，采用短期凭证和最小权限原则，以及加强构建管道的安全，如分支保护、强制人工审查、签名发布等。
为什么说AI代理不能完全替代人类？
因为AI代理缺乏人类对后果的担忧和道德约束，无法像人类一样被追责或惩罚，因此不能完全替代人类。
这次事件暴露了构建管道的哪些问题？
事件暴露了构建管道中自动化身份（如访问令牌）权限过大，且没有机制检测异常行为，导致恶意代码被直接打包进正式发布。
