开源已成为现代软件开发的基础。如今，几乎所有应用程序都依赖于复杂的第三方库、框架、模型和构建工具网络。仅此一点就足以带来显著的挑战。 software supply chain security 挑战。与此同时，人工智能已经进入了…… 软件开发生命周期 作为一个强大的加速器，它可以生成代码、建议依赖关系、自动修复问题，甚至影响架构设计。cis离子。 开源和人工智能的结合改变了软件的构建方式，也不可避免地改变了软件遭受攻击的方式。人工智能安全、人工智能与软件安全以及人工智能安全之间的交集，都凸显了人工智能安全的重要性。 software supply chain security 这不再是理论上的问题，而是工程组织面临的软件供应链风险的主要来源之一。
我们最近的 SafeDev Talk 演讲正是基于这种现实情况： 开源、人工智能与新的攻击面：武器化代码、更智能的防御本次研讨会汇聚了来自红帽、TikTok 和 Xygeni 的安全专家。讨论的重点是安全和工程团队在生产环境中已经遇到的问题，特别是开源供应链攻击、恶意开源软件包以及人工智能驱动的软件开发中速度与控制之间日益加剧的矛盾。 最终呈现出的图景十分清晰：攻击面扩张的速度超过了传统安全模型的应对速度，而人工智能既是攻击面扩张的倍增器，也是对人工智能安全领域长期假设的压力测试。 software supply chain security.
如果这段描述与贵公司目前的软件开发方式惊人地相似，那并非巧合。许多团队只有在出现故障后才会意识到，他们对自动化的信任度已经达到了何种程度。
人工智能安全与 Software Supply Chain Security 现在还是同样的问题
讨论中反复出现的一个主题是，人工智能安全不能再被视为一个独立于其他学科的领域。 software supply chain security人工智能系统并非孤立运行；它们的构建、训练、部署和集成都通过同一平台完成。 pipelines、依赖项和注册表已经难以应对开源供应链攻击。
在人工智能驱动的软件开发中，模型可以自动建议代码、生成修复程序并选择依赖项。这些功能可以显著提高软件的运行效率。cis离子直接影响 开源依赖管理而且往往并非出于人为的明确意图。因此，依赖风险不再仅仅取决于开发人员的选择；它越来越多地受到人工智能行为的影响。
这种融合意味着人工智能和软件安全方面的故障通常会表现为传统的供应链事件：依赖项受损、构建工件被污染或存在漏洞。 CI/CD 流程方面，虽然工具可能是新的，但软件供应链风险却非常真实，而且越来越难以预测。
如果您的威胁模型仍然将“人工智能风险”与“供应链风险”分开，那么或许值得重新审视一下在您的构建和部署工作流程中，这一界限究竟存在于何处。
开源供应链以机器速度发起攻击
开源供应链攻击并非新鲜事，但人工智能改变了其运作方式。攻击者需要的并非新颖的技术，而是规模。人工智能能够实现快速的生态系统分析、自动发现薄弱的依赖关系，并快速迭代攻击载荷。
从进攻角度来看，侦察的工业化显著提高了利用恶意开源软件包发起攻击的成功率。以前难以察觉的组件现在可以被快速发现、分析和利用，往往在防御者意识到它们正在被使用之前就已完成。
这就是为什么 software supply chain security 不能仅仅依赖延迟信号。注册表、安全公告和事后披露都需要人为的时间才能完成，而攻击者的行动速度却越来越快，几乎是机器级别的。由此产生的暴露窗口直接加剧了软件供应链的风险。
如果你的主要检测信号是“注册表删除了软件包”，那么你已经处于攻击者时间线的下游。
人工智能驱动软件开发中的依赖风险
SafeDev Talk 上讨论的最明确的风险之一是依赖性风险，尤其是在严重依赖人工智能驱动的软件开发的环境中。人工智能编码助手的优化目标是便捷性和速度，而不是最大限度地减少攻击面。
实际上，这会导致过度依赖。人们会添加新的库，而不是重用现有功能。 传递依赖 悄无声息地发展，并且开源 依赖管理 不再是主动思考，而是被动应对。久而久之，团队会丧失思考自身实际运作方式的能力。
这不仅仅是卫生问题。每增加一个依赖项，都会引入额外的软件供应链风险、新的信任假设，以及开源供应链攻击的新机会。当依赖项……cis离子被自动化处理并进行表面审查，依赖风险变成了系统性的，而不是偶然的。
如果你的依赖关系图增长速度超过了团队的解释能力，这不是工具问题，而是信任问题。
人工智能编码助手、安全性和审查制度的崩溃
另一个被讨论的失效模式是，在人工智能生成代码的背景下，同行评审机制的削弱。对于人工智能编码助手而言，安全不仅仅关乎快速注入或模型滥用，更关乎有多少未经审查的逻辑进入生产系统。
人工智能生成的变更通常规模庞大、逻辑严密，且难以在时间压力下进行审查。因此，同行评审变得肤浅或流于形式。这种悄无声息的崩溃削弱了最有效的控制手段之一。 software supply chain security.
问题不在于开发人员的疏忽，而在于工作流程的错位。当速度至上而阻碍却受到惩罚时，依赖人工干预的人工智能和软件安全控制必然会削弱。如果审查不再起到屏障作用，攻击者就无需绕过审查。
许多团队认为，只要流程还在，评审就仍然有效。很少有人会去质疑它是否还能起到有效的控制作用。
恶意开源软件包与流行神话
开源依赖管理领域普遍认为，热门项目更安全。但实际上，热门项目往往更容易受到攻击。广泛使用的库是高价值的攻击目标。 开源供应链攻击，前cis之所以妥协，是因为妥协会产生广泛的后续影响。
许多热门项目由小型团队或个人维护。即使检测到问题，恶意开源软件包也往往会在被移除前存活数小时甚至数天。在此期间，组织机构仍会通过自动化构建继续使用这些软件包。
这一延误凸显了采取积极主动措施的必要性。 software supply chain security 管控措施。面对现代软件供应链风险，仅仅依靠受欢迎程度、声誉或注册机构的行动是不够的。
“广泛使用”并不等同于“积极防御”，将其视为后者是供应链中最根深蒂固的误解之一。
软件供应链和人工智能安全中的溯源
在整个讨论过程中，软件供应链中溯源的重要性被反复提及。在人工智能辅助的环境中，归属关系变得模糊不清。代码可能由模型生成，经人工修改，由自动化系统合并，最终部署，但缺乏明确的责任归属。
如果没有可验证的来源信息，组织就只能被动地信任工件。人工智能安全要求从信任转向验证：签名工件， build attestations以及可追溯的来源。虽然溯源信息并不能完全阻止恶意行为，但它能显著降低歧义性并限制攻击者的可操作性。
这同样适用于模型、数据和代码。在人工智能驱动的软件开发中，溯源是人工智能和软件安全的基础要求。
SBOM 现代人工智能安全 Pipelines
的作用 SBOM 人工智能安全是另一个隐含的主题。 SBOM提供依赖关系图的可见性但仅仅提高可见性是不够的。在人工智能高度发达的环境中， SBOM必须不断发展，不仅要捕获库，还要捕获模型、构建步骤和自动化设计。cis离子。
当与 行为分析和溯源, SBOM 人工智能安全已成为降低软件供应链风险的强大工具。它们使组织能够检测到意外变化、分析其影响，并更有效地应对开源供应链攻击。
CI/CD Pipeline Security 在自动化压力下
最后， CI/CD pipeline security 成为关键控制平面。 Pipeline越来越多地，人们会执行由人工智能系统建议或触发的操作。如果这些 pipeline由于缺乏强大的身份控制、工件验证和策略执行，它们就成了攻击者的理想入口点。
不足 CI/CD pipeline security 这使得恶意开源软件包不仅会影响生产系统，还会影响开发人员环境和构建基础设施。随着自动化程度的提高， pipeline必须将 s 视为高价值资产。 software supply chain security 程式。
观看 SafeDev 演讲
想直接聆听来自该领域实践者的更多真知灼见，请观看完整视频。 SafeDev 演讲： 开源、人工智能与新的攻击面：武器化代码、更智能的防御汇聚了 罗曼·茹科夫（红帽公司）, 莱昂·约翰逊（TikTok）和 路易斯·罗德里格斯·贝尔佐萨 (Xygeni).
对人工智能安全的实际影响 Software Supply Chain Security
这些转变的实际影响远不止于工具层面。各组织必须认识到，人工智能安全、人工智能和软件安全以及 software supply chain security 现在它们已经紧密交织在一起。cis曾经被认为风险较低的依赖项更新、代码生成和自动化，如今却带来了显著的软件供应链风险，尤其是在这些依赖项更新、代码生成和自动化过程中。cis离子是由工具隐式产生的，而不是由人显式产生的。
在 SafeDev Talk 上，这一点得到了简洁的总结。正如一位发言者所说： 当人工智能系统参与软件开发时，安全团队不再仅仅是保护代码，而是要保护数据。cis自动化并不会免除责任，而是重新分配责任。
在实践中，这意味着在便利性占据主导地位的地方，要恢复人为因素。开源依赖管理必须考虑人工智能驱动的行为，而不是假设是人类的深思熟虑。依赖风险不能再被视为偶尔的审查工作。cise. CI/CD pipeline security 必须强制执行验证，不能想当然地认为输入是无害的。软件供应链中的溯源必须从愿景变为现实。
讨论中得出的另一个重要结论是，速度本身不再是中性的。大多数供应链故障并非源于单一的灾难性事件。cis离子，但来自许多未经任何人明确批准的小型自动化选择。这是预先的。cis解释为什么传统的信任模型在人工智能驱动的软件开发中失效。
这并非意味着要放弃开源或人工智能。恰恰相反，它承认了它们在现代工程中的核心作用。但如果不不断改进安全假设，组织就有可能让自动化默认定义信任。
结束......
理解这种转变的一个有用方法是： software supply chain security 不再仅仅是保护文物，而是保护 decis离子路径在人工智能辅助的世界里，最重要的安全问题不仅是“这个组件是否存在漏洞？”，而是“为什么会引入这个组件？是谁或什么引入的？又是在哪些限制条件下引入的？” 适应这种思维框架的组织虽然无法完全消除风险，但至少能更好地应对风险带来的意外。
