前情回顾·AI安全威胁态势
安全内参7月25日消息，一名黑客成功将破坏性系统命令植入亚马逊VS Code扩展中。随后，这一用于接入AI驱动的编码助手Amazon Q的扩展通过官方更新被推送给用户。
这段未经授权的代码指示AI代理表现为一个具有文件系统和云工具访问权限的“系统清理器”，目标是删除用户数据及其云端资源。
黑客在接受外媒404 Media采访时表示，他们原本可以部署更具破坏性的负载，但选择通过发布这些命令的方式，表达对亚马逊所谓“AI安全作秀”的抗议。
此次攻击锁定了Amazon Q的VS Code扩展作为目标。这一开发工具的安装量已超过95万次。攻击者利用一个未经验证的GitHub账号，于6月底提交了一个拉取请求，据称随后还获得了管理权限。
7月13日，攻击者将恶意代码插入代码库。7月17日，亚马逊发布了被篡改的1.84.0版本，据称当时尚未意识到代码遭到修改。
AWS发言人表示：“我们已迅速采取措施，缓解有人试图利用两个开源代码库中已知问题篡改Amazon Q开发者版VS Code扩展代码的攻击，并确认没有客户资源受到影响。我们已完全修复这两个代码库中的问题。客户无需对AWS SDK for .NET或AWS Toolkit for Visual Studio Code采取进一步行动。作为额外的预防措施，客户可以更新Amazon Q开发者版VS Code扩展至最新版本1.85。”
AI编程工具被利用
此次事件表明，生成式AI工具及其在开发环境中集成使用的安全风险正日益增长
网络安全专家Sunil Varkey指出：“尽管这可能是一种引发风险关注的抗议行为，但它突显了AI生态系统中一个愈发严重的关键威胁：在缺乏稳健的防护机制、持续的监控与有效治理框架的情况下，强大的AI工具极易被恶意行为者利用。一旦如编码助手这类AI系统被攻破，威胁将成倍增加：攻击者不仅可将恶意代码注入软件供应链，用户也可能在毫不知情的情况下继承漏洞或后门。”
IDC亚太区网络安全服务高级研究经理Sakshi Grover表示，该事件还揭示了将开源代码集成进企业级AI开发工具时所固有的风险。如果贡献流程缺乏安全治理，这种风险更高。
Grover指出：“它还暴露出，企业在依赖未经严格审查的开源贡献时，AI开发中的供应链风险会被放大。此次事件中，攻击者利用GitHub的工作流机制注入了一个恶意系统提示，从而在运行时有效地重定义了AI代理的行为。”
DevSecOps面临压力
分析人士指出，该事件反映出软件交付流程中在保障代码安全性方面存在系统性漏洞，尤其是在验证与监管发布至生产环境的代码方面。
对于企业团队而言，该事件凸显了在DevSecOps实践中引入面向AI的威胁建模的必要性，以应对模型漂移、提示注入与语义操控等新兴风险。
Grover表示：“组织应采用不可变的发布流程，并实施基于哈希的代码验证机制，同时在持续集成/持续交付（CI/CD）流程中集成异常检测能力，以便尽早识别未经授权的变更。此外，即使是出于预防目的的移除行为，也应保持透明，并建立及时的事件响应机制。这对于在AI代理逐渐具备系统级自主性的背景下，维系开发者社区的信任至关重要。”
值得注意的是，此次漏洞也说明，即便是在大型云服务提供商内部，DevSecOps在AI开发工具方面的成熟度依然滞后于实际需求。
Confidis创始人兼首席执行官Keith Prabhu指出：“AI在开发环境中的迅猛扩张使DevSecOps捉襟见肘。从亚马逊的官方回应来看，企业安全团队应从中吸取的重要教训是：构建能够快速识别此类安全漏洞的治理与审查机制，并及时与受影响方进行沟通。”
CyberMedia Research产业研究副总裁Prabhu Ram表示，组织应通过严格的代码审查流程、持续监控工具行为、实施最小权限访问控制，并敦促厂商增强透明度，以强化自身防御能力。
Ram强调：“这些举措将有助于应对确保复杂软件供应链安全、并在开发生命周期中嵌入安全机制所面临的持续挑战。归根结底，提升DevSecOps的成熟度并构建分层防御体系，是当今软件生态中应对持续演化威胁的关键所在。”
参考资料：csoonline.com
声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
