CI/CD 管道内部发生的具体情况是出了名的不透明。尽管已经编写了 YAML 配置文件（即管道指令列表），但您如何确定一切都按照描述的那样准确发生？更糟糕的是，大多数管道都是完全瞬态的，因此即使发生故障，除了记录的内容之外，几乎没有证据表明可能包含也可能不包含问题的详细信息。
通过使用自动化的持续集成/持续交付 (CI/CD) 管道来实现快速开发。拥有触发器或调度来自动编译、构建、测试和发布代码真是太棒了。然而，大多数管道在设计时并没有考虑到安全性，而是为了速度和使用方便而设计。由于管道通常需要访问互联网来下载依赖项和文件，因此一旦管道遭到破坏，攻击者就有多种选择来破坏您的操作或窃取信息或秘密。
在本文中，我将介绍一些可以用来保护 CI/CD 管道的最佳实践。就我们的目的而言，无论您使用哪种自动化工具或系统，安全原则仍然有效。您只需要找到合适的工具来保护管道的该部分。
什么是 CI/CD（持续集成/持续交付）管道？
CI/CD 管道是用于构建、测试和发布软件、应用程序或工件的自动化流程。这些管道变得越来越普遍和复杂。管道是提高团队生产力和更一致、更可预测地生成软件工件的出色工具。当您考虑到较大的企业可能拥有数百条相互关联、精心设计的管道，而所有这些管道都相互依赖才能正常运行时，自动化这些过程的重要性就变得更加明显。
自动、定期地构建和测试新的最终产品的代码更改称为持续集成（CI）。编码更改作为称为持续交付和/或部署（CD）的两步过程的一部分进行交付、测试和集成。持续部署会自动将更新交付到生产环境中，而持续交付会在自动生产部署之前停止。您的管道是否使用其中一种完全取决于您以及您的环境和可交付成果的设置方式。
CI/CD 安全对软件供应链的重要性
大多数公司依赖 CI / CD工具 用于自动化他们的管道。这意味着，像许多其他 软件供应链攻击，坏人所需要的只是突破单个目标以获得巨大的爆炸半径。主要弱点之一是需要管道下载依赖项并将其集成到最终产品或工件中。即使一个不良的依赖关系也足以让不需要的元素在管道中立足。由于管道可以访问源代码和基础设施的各种其他元素（根据需要），因此权限升级可以访问并稍后更改或渗透在该特定管道中创建的产品的几乎任何部分。
一个简单的例子可以在我们的解释中找到 缓存或依赖中毒.
在过去的几年中，多家大公司遭受了以 CI/CD 管道为起点的软件供应链攻击。例如，您可以查看 CircleCI 的违规行为 2023 年 XNUMX 月， Argo CD的妥协 2022 年 XNUMX 月，以及 Codecove 漏洞 四月2021。
此类攻击的潜在后果是严重的，因此尽一切努力确保管道尽可能安全是有意义的。
CI/CD 安全最佳实践
无论您使用什么 CI/CD 平台或工具，您都可以采取一些措施来增强安全性，并减少万一敌对行为者设法访问您的管道或网络时造成的潜在损害。
监控和警报 – 即使您已经培训工程师警惕网络钓鱼和其他社会工程欺诈，也可能会发生违规行为。由于大多数管道环境都是暂时的，因此一旦工作完成，就不会留下太多痕迹，除非您主动记录它们。当您处理每个 PR、合并、构建和测试时，请确保记录对环境或配置文件所做的任何修改。用户数据还应与所有其他数据一起记录，以便在出现问题时进行检查。能够重建漏洞并确定出了什么问题以及如何出错是这里的目标。选择应提前触发警报的事件，并确保通知适当的各方。注意不要用毫无意义或过于敏感的警报来压垮个人；这可能会导致警报疲劳，这只会让他们忽视警报或比谨慎的反应晚得多。
使用RBAC原则结合最小权限 – 根据用户在组织内指定的角色或工作职能提供对系统资源的访问是基于角色的访问控制或 RBAC 的基础。用户在 RBAC 中被赋予角色，指定他们对不同系统资源（如文件、文件夹和程序）的访问权限和权限。另一方面，最小权限的概念是指为用户提供履行其工作职责所需的最小访问权限和权限的做法。这意味着用户只能使用完成分配的工作所需的资源，仅此而已。最小权限和 RBAC 经常作为互补的安全概念一起应用。最小权限原则确保用户只能访问执行其特定职责所需的最少量资源，并且 RBAC 分配的角色为用户提供对执行其工作职能所需的资源的适当访问权限，仅此而已。结合起来，这些准则有助于维护一个维护良好、相对安全的系统。您可以将其配置为需要多个用户授权才能执行基本系统操作，作为额外的安全层。应谨慎使用此策略，因为它可能会导致开发过程明显滞后。
将管道来源保留为不可变日志 – 关于软件工件的可验证信息，描述了某物在何处、何时以及如何创建的，称为出处。准确了解输入了哪些文件以及它们在管道中发生了什么，可以生成来源文件，以形成该管道的不可伪造的日志。为了安全起见，来源必须独立于任何用户创建，因为用户可以破坏或修改的任何内容都不完全值得信赖。 抄写员的瓦林特 使你能够 确定出处 在您的各种 SCM 系统的管道中。每个来源文件 (JSON) 稍后都可以访问，因此您可以查看它以确定是否发生了任何意外或不良情况。顺便说一句，从整个管道生成和管理来源文件是该项目的核心。 SLSA框架.
充分利用您的 SBOM – 以防万一您错过了一些潜在用途，在管道末尾制作的 SBOM 可以帮助列出所有使用的开源包。将该列表与已知的 CVE 进行比较可以告诉您最终产品中存在哪些潜在漏洞。您还可以使用该列表来检查您是否仍在使用过时版本的开源软件包，甚至可以使用类似 OpenSSF 记分卡 检查您正在使用的软件包的“健康状况”。由于新的 CVE 不断被发现，因此您应该拥有一项与一次性 SAST 不同的服务，它可以让您知道现有软件包中是否发现了新的 CVE。 Scribe 的服务可以帮助您自动完成所有这些工作。
验证是否符合您的政策 – 每家公司，有时甚至每条管道，都有需要制定的政策以确保一切顺利。有些策略是通用的（例如确保有两人验证过程），而其他策略则是独特的（例如确保 Mike 在我们将其交付生产之前签署最新的更改）。利用加密签名验证机制和独特的策略文件，您现在可以在每个管道中包含所需的策略，并验证（向您自己和其他人）它们是否已发生。这是人性的弱点，当受到压力时，可能会导致某些要求被跳过，某些规则会为了按时完成而被扭曲。采取这一措施后，人们将无法再违反规则，这将有助于维护管道的安全，使其免受内部和外部威胁。 Scribe 开发了一种新颖的方法来执行此类策略，甚至允许您编写自己的策略。一探究竟 点击这里.
保护管道的指令文件 – 威胁参与者可能会使用一种称为中毒管道执行 (PPE) 的技术来“毒害”CI 管道，该技术实质上会修改管道指令文件中最初指定的管道阶段或其顺序。该方法通过滥用源代码管理 (SCM) 存储库中的权限来操纵构建过程。通过将恶意代码或命令插入到构建管道设置中，可能会毒害管道并导致恶意代码在构建完成时执行。除非您检查管道指令文件，否则您将无法判断您的构建没有按照您预期的方式运行。为了确保您的管道按预期运行，您应该在每次运行之前验证指令文件。从加密角度来说，对文件进行签名并添加签名验证作为管道的第一步是实现该安全性的一种方法。抄写员的瓦林特 签名并验证 函数是在启动任何新的管道运行之前验证指令文件是否保持不变的一种方法。
确保您的最终结果 – 为什么攻击者应该努力破坏您的管道，因为用欺诈版本替换您的最终产品要容易得多？由于生成公司似乎是此类攻击中图像的来源，因此该公司不足以拥有有效的证书来保护它。简单地说，这会增加假货的可信度。解决方案是对管道生成的最终工件进行加密签名，并允许最终用户验证该签名。 Scribe 的 Valint 可用于 签名并验证 各种各样的工件为您提供了额外的安全性，使您的用户得到的正是您想要他们得到的东西。
展望未来
没有人会放弃使用 CI/CD 等自动化技术来加快工作速度。恰恰相反，在我们生活的世界中，我们总是在推动更快的软件更新迭代。我们至少应该确保谨慎处理任务，注意不要在此过程中危及我们的生产环境或源代码。
至关重要的是要考虑有人非法访问您的管道、环境或源代码的潜在后果。我相信，一旦您意识到潜在泄漏的危险性以及您的管道和网络最容易受到影响的地方，您就能够采取适当的措施来阻止或减轻潜在的泄漏。
由于互连管道的复杂性只会增加，因此维护整体环境安全（分段网络、RBAC、零信任等）至关重要，这是帮助保护管道的第一步。之后，寻求创建可靠的、不可伪造的证据，并采用加密签名和数据验证来尝试尽可能减轻可能毒害管道或管道缓存的软件供应链攻击的可能性。保持警惕和怀疑可以为您的公司避免无数的麻烦。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
