1.通过 Jenkins 构建 CI/CD 实现全链路灰度
2.一篇文章了解CI/CD管道全流程
3.90%的源码开发都没搞懂的CI和CD！
4.cicd与devops区别是安全什么?
5.什么是CI/CD？
6.什么是持续集成（CI）/持续部署（CD）？

通过 Jenkins 构建 CI/CD 实现全链路灰度

       本文介绍通过 Jenkins 构建流水线的方式实现全链路灰度功能。

       在发布过程中，管理为了整体稳定性，源码我们总是安全希望能够用小部分特定流量来验证下新发布应用是否正常。

       即使新版本有问题，管理pdf creator 源码也能及时发现，源码控制影响面，安全保障了整体的管理稳定性。

       整体架构

       我们以如下 Demo 为例：

       为了保证稳定，源码我们约定如下上线流程：

       其中，安全在灰度验证中，管理有几种不同的源码策略

       部署应用&创建泳道

       按照参考文档部署应用后，我们首先要区分线上流量和灰度流量。安全

       创建泳道组，管理将整个链路涉及到的应用全选：

       然后创建泳道组，将符合规则的应用划入 gray 泳道：

       注：没有匹配的流量，会走到基线环境，也就是没有打标的应用节点上。

       配置完成后，访问网关，如果不符合灰度规则，走基线环境：

       如何符合灰度规则，走灰度环境：

       配置 Jenkins 流水线

       本文实践需要将源码打包后执行镜像推送，请确保 Jenkins 有权限推送到镜像仓库中。具体操作，请参见使用 kaniko 构建和推送容器镜像。

       在 Jenkins 命名空间下使用生成的 config.json 文件创建名为 jenkins-docker-cfg 的 Secret。

       在 Jenkins 中创建全链路灰度发布流水线

       基于 Jenkins 实现自动化发布的流水线，通过该流水线可以使应用发布具备可灰度、可观测、可回滚的安全生产三板斧能力。

       1. 在 Jenkins 控制台左侧导航栏单击新建任务。

       2. 输入任务名称，选择流水线，然后单击确定

       3. 在顶部菜单栏单击流水线页签，在流水线区域配置相关参数选择，输入脚本路径，然后单击保存。

       您可以参考以下的文件填写好指定的参数，当然您也可以根据需求编写 Jenkinsfile ，并上传至 Git 的指定路径下（流水线中指定的脚本路径）。

       构建 Jenkins 流水线

       1. 在 Jenkins 控制台单击流水线右侧的图标。

       2. 单击流水线的开始构建。

       说明：第一次构建因为需要从 Git 仓库拉取配置并初始化流水线，所以可能会报错，再次执行 Build with Parameters，生成相关的参数，填写相关的参数，再次执行构建。

       查看部署状态，代码打包，镜像构建及发布，灰度部署阶段都已经完成，结束灰度阶段等待确认。

       结果验证

       1. 登录容器服务控制台，在控制台左侧导航栏中，单击集群。

       2. 在集群列表页面中，单击目标集群名称或者目标集群右侧操作列下的详情。

       3. 在集群管理页面左侧导航栏选择工作负载 > 无状态。

       4. 在无状态应用列表页面，spring-cloud-a-gray应用已经自动创建，并且它的镜像已经替换为spring-cloud-a:gray版本。

       5. 在集群管理页面左侧导航栏选择网络 > 服务，选择设置的命名空间，单击zuul-slb服务的外部端点，查看真实的调用情况。

       6. 登录 MSE 治理中心控制台，在应用详情页面，微信淘宝客小程序源码可以看到灰度流量已经进入到灰度的 Pod 中。

       全量发布应用

       结果验证通过之后，确认全量发布。

       1. 在 Jenkins 控制台中，单击目标流水线名称。

       2. 单击需要全量发布的阶段，在请确认是否全量发布对话框中输入 true，然后单击确认。

       3. 在容器服务控制台，发现 spring-cloud-a-gray 应用已经被删除，并且 spring-cloud-a 应用的镜像已经替换为 spring-cloud-a:gray 版本。

       4. 在 MSE治理中心控制台，发现灰度流量已经消失。

       回滚应用

       如果发现验证结果不符合预期时，则回滚应用。

       1. 在 Jenkins 控制台中，单击目标流水线名称。

       2. 单击需要全量发布的阶段，在请确认是否全量发布对话框中输入 false，然后单击确认。

       3. 在容器服务控制台，发现 spring-cloud-a-gray 应用已经被删除，并且 spring-cloud-a 应用的镜像仍然是老版本。

       4. 在 MSE 治理中心控制台，发现灰度流量已经消失。

       总结

       在微服务治理架构中，全链路灰度功能能提供虚拟泳道，极大的方便了测试、发布时的快速验证，能够帮助 DevOPs 提升线上稳定性。

       阿里云微服务引擎（MSE）能够给您带来全生命周期的、全方位的微服务治理能力，保障您的线上稳定性、提升开发、运维效率。

一篇文章了解CI/CD管道全流程

       从CI/CD过程开始，包含所有阶段并负责创建自动化和无缝的软件交付的一系列步骤称为CI/CD管道工作流。使用CI/CD管道，软件发布工件可以从代码提交阶段到测试、构建、部署和生产阶段在管道中移动和前进。这个概念非常强大，因为一旦指定了一个管道，它的一部分或全部就可以实现自动化，从而加快流程并减少错误。换句话说，CI/CD管道使企业更容易一天自动多次交付软件。

       DevOps工程师经常会因为CI/CD中各个阶段的自动化而与CI/CD管道混淆。虽然不同的工具可以使CI/CD中的各个复杂阶段实现自动化，但由于人工干预，CI/CD的整个软件供应链仍然可能被打破。那么，就首先了解CI/CD过程中的各个阶段，以及CI/CD管道为什么对于组织快速、大规模地交付代码至关重要。

       企业应用程序开发团队通常由开发人员、测试人员/QA工程师、运营工程师和SRE（站点可靠性工程师）或IT运营团队组成。他们紧密合作，将高质量的软件交付给客户。CI/CD是两个独立过程的组合:持续集成和持续部署。下面列出了其中的主要步骤。

       CI持续集成

       CI持续集成(CI)是构建软件并完成初始测试的过程。持续部署(CD)是将代码与基础设施结合起来的过程，确保完成所有测试并遵循策略，然后将代码部署到预期的环境中。当然，许多公司都有自己的流程，但主要步骤如下。unity3d 捕鱼源码下载

       CI：代码提交

       人员：开发人员和工程师、数据库管理员（DBA）、基础架构团队

       技术：GitHub、Gitlab、BitBucket

       过程：代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者讨论和审查变更之后，开发人员将编写代码，并在软件需求、功能增强、bug修复或变更请求完成后提交。管理编辑和提交变更的存储库被称为源代码管理（SCM工具）。在开发人员提交代码（代码推送请求）后，代码更改被合并到存储在中央存储库（如GitHub）中的基本代码分支中。

       CI：静态代码分析

       人员：开发人员和工程师、数据库管理员（DBA）、基础设施团队、测试人员

       技术：GitHub、Gitlab、BitBucket

       过程：一旦开发人员编写了代码并将其推送到存储库，系统就会自动触发，开始下一个代码分析过程。想象一下这样一个步骤：提交的代码直接进行构建，但在构建或部署过程中失败了。就资源利用率而言，无论是机器还是人力，这都是一个缓慢而昂贵的过程。必须检查代码的静态策略。SAST（Static Application Security Test）：SAST是一种白盒测试方法，使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码，以发现软件缺陷、漏洞和弱点（如SQL注入等）。这是一个快速检查过程，检查代码是否有语法错误。虽然此阶段缺少检查运行时错误的功能，但这将在稍后的阶段执行。

       将附加的策略检查放到自动化管道中可以显著减少稍后在该过程中发现的错误数。

       CI：build

       人员：开发人员和工程师

       技术：Jenkins、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps

       过程：持续集成流程的目标是接受常规的代码提交，并持续构建二进制工件。持续集成过程通过检查添加的新模块是否与现有模块配合良好，有助于更快地发现bug。这有助于减少验证新代码更改的时间。构建工具有助于编译和创建可执行文件或包（.exe、.dll，.jar等）取决于用于编写源代码的编程语言。在构建过程中，还会生成SQL脚本，然后与基础设施配置文件一起测试。简而言之，构建阶段是编译应用程序的阶段。构建过程的其他子活动包括工件存储、构建验证和单元测试。

       CI：测试阶段

       人员：测试人员和QA工程师

       技术：Selenium、Appium、Jmeter、SOAP UI、Tarantula

       过程：发布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于防止错误到达产品。根据构建的大小，此检查可以持续数秒到数小时。对于由多个团队提交和构建代码的html个人主页简单源码大型组织，这些检查将在并行环境中运行，以节省宝贵的时间并尽早将Bug通知给开发人员。

       这些自动化测试是由测试人员（或者称为QA工程师）建立的，他们已经根据用户故事建立了测试用例和场景。他们进行回归分析，压力测试，以检查与预期产出的偏差。测试中涉及的活动有健全性测试、集成测试和压力测试。这是一个非常先进的测试水平。在这里会发现开发代码的开发人员可能不知道的问题。

       集成测试：

       集成测试是使用Cucumber、Selenium等工具来执行的，其中各个应用程序模块作为一个组进行组合和测试，同时评估是否符合指定的功能需求。在集成测试之后，需要有人批准将该组中的更新集移动到下一阶段，这通常是性能测试。这个验证过程可能很麻烦，但它是整个过程的重要组成部分。核查过程中出现了一些新的解决办法。

       负载和压力测试：

       负载平衡和压力测试也使用自动化测试工具（如Selenium、JMeter等）来执行，以检查应用程序在高流量环境下是否稳定和性能良好。此测试通常不会在每个更新上运行，因为完整的压力测试是长期运行的。在发布主要的新功能时，将对多个更新进行分组，并完成完整的性能测试。在单个更新被转移到下一个阶段的情况下，管道可能包括金丝雀测试作为替代方案。

       持续部署：bake和部署

       人员：基础设施工程师、现场可靠性工程师（SRE）、运维工程师

       技术：Spinnaker、Argo CD、Tekton CD

       过程：测试阶段完成后，清除了标准的代码就可以部署到服务器中，在那里它们将与主应用程序集成。在部署到生产环境之前，它们将被部署到产品团队内部使用的测试/暂存或beta环境中。在将构建移动到这些环境之前，构建必须经过两个子阶段Bake和Deploy。这两个阶段都是Spinnaker固有的。

       CD：Bake

       Bake是指从源代码中创建一个不可变的映像实例，该实例在生产环境中具有当前配置。这些配置可能是数据库更改和其他基础设施更新之类的内容。Spinnaker可以触发Jenkins来执行这个任务，有些组织更喜欢使用Packer。

       CD：部署

       Spinnaker将自动将烘焙的映像传递到部署阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似，在部署阶段执行功能相同的过程。部署首先转移到测试、阶段，最后转移到生产环境，然后进行批准和检查。整个过程由Spinnaker之类的工具处理。

       CD：验证

       这也是团队优化整个CI/CD流程的关键所在。因为现在已经进行了很多测试，所以失败应该很少。但此时的任何故障都需要尽快解决，以便将对最终客户的影响降到最低。团队也应该考虑自动化这部分流程。

       部署到生产环境是使用部署策略（如蓝绿部署、金丝雀分析、滚动更新等）执行的。在部署阶段，将监视正在运行的应用程序，以验证当前部署是石器时代客户端源码否正确或是否需要回滚。

       CD：监控

       人员：SRE，运维团队

       技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli

       过程：要使一个软件发行版具有故障安全性和健壮性，在生产环境中跟踪发行版的运行状况是至关重要的。应用程序监控工具将跟踪CPU利用率和发布延迟等性能指标。日志分析器将扫描底层中间件和操作系统产生的日志流，以识别行为并跟踪问题的来源。在生产过程中出现任何问题时，都会通知相关人员，以确保生产环境的安全性和可靠性。此外，监视阶段帮助企业收集有关新软件更改如何为收入做出贡献的信息，并帮助基础架构团队跟踪系统行为趋势和进行容量规划。

       持续部署：反馈和协作工具

       人员：SRE、Ops和维护团队

       技术：禅道、ServiceNow、Slack、Email、Hipchat

       DevOps团队的目标是更迅速、持续地发布，然后不断减少错误和性能问题。这是通过slack或电子邮件频繁地向开发人员和项目经理反馈新版本的质量和性能，并在ITSM工具中及时提高票价来实现的。通常，反馈系统是整个软件交付过程的一部分；因此交付过程中的任何更改都会频繁地记录到系统中，以便交付团队可以对其采取行动。

       企业必须评估一个整体的持续交付解决方案，它可以自动化或促进上述阶段的自动化。

%的开发都没搞懂的CI和CD！

       在当今的软件开发环境中，持续集成（CI）与持续交付与部署（CD）成为推动企业加速创新与提升效率的关键要素。根据IDC的统计，年全球DevOps软件市场的规模约为亿美元，预计到年，这一数字将增长至亿美元。这种增长揭示了企业在适应敏捷开发模式以及提高软件交付速度上的迫切需求。

       CI/CD管道的实施旨在实现代码的频繁集成与交付，无论这些更改是主要还是次要，或是新功能添加或Bug修复。这一流程确保代码始终保持可部署状态，并自动发布至预生产环境，通常在一天内发生多次。这种做法鼓励开发者频繁提交小调整，而非一次提交大量代码。

       CI/CD管道是软件交付的自动化途径，包括持续集成、自动测试、交付与部署四个阶段。首先，源代码或提交阶段负责引入新功能或改进现有工作模式以满足客户需求。触发这一阶段的通常是源代码存储库中的代码更改。在构建阶段，源代码被编译，系统执行单元测试，如果通过，则进行集成测试，所有问题需立即解决。Docker工具用于创建服务器并将数据移至注册表，准备下一个测试阶段。自动测试阶段验证软件质量，确保没有Bug，且符合预期功能。如果测试失败，代码需返工，循环继续。一旦软件通过所有测试，可执行程序部署至生产环境。在直接推送到生产环境前，内部测试工具环境作为额外测试和评审环节，确保程序在生产环境中的稳定运行。

       CI/CD管道提供了一系列优势，包括更准确、健壮的软件构建、更快的故障检测与修复、耐用性测试、更频繁的代码集成、更小的代码更改、更快的错误解决速度、提升开发效率、缩短开发周期、增强软件可靠性、降低测试成本等。通过整合DevOps实践与工具，CI/CD管道在实现自动化测试、提高响应速度、优化生产率、缩短开发周期、提升软件质量、确保稳定性、减少测试成本等方面展现出显著效果。

       禅道作为专业的DevOps解决方案提供商，支持Git、Subversion版本系统集成、Jenkins构建任务触发、ZTF自动化测试调度等多个方面，通过自研的ZTF自动化测试工具，集成8种单元测试框架、3种自动化测试框架，将测试结果回传至禅道，实现统一报告展示。禅道ZTF有效连接了项目管理与持续集成工具，贯穿持续集成、持续测试、持续部署等DevOps生命周期的不同阶段，提供从项目规划到持续交付的完整解决方案。

cicd与devops区别是什么?

       CI/CD与DevOps是软件开发和运营领域的两个关键概念，它们各自定义和作用有所不同。下面将详细阐述它们的主要区别。

       定义

       CI/CD（持续集成与持续交付）是一种确保软件更新既快速又可靠的方法。它关注代码集成、测试和最终产品交付的自动化过程，包括持续集成和持续交付两个阶段。其中，持续集成侧重于代码整合和测试，而持续交付则关注软件打包和部署。

       DevOps则是一种综合理念，强调开发和运营团队的合作，旨在简化产品开发流程，提高效率和产品质量。DevOps通过促进团队间沟通、整合工作流程和采用自动化工具，推动软件开发和部署的持续改进。

       范围

       CI/CD聚焦于自动化软件开发过程中的关键环节，如代码集成、测试和部署。它侧重于实现快速、自动化的代码更新和发布流程。

       DevOps则更加广泛，不仅涵盖自动化工具和流程，还涉及文化、策略、工具和实践的全面变革。DevOps关注于整个开发到运营的周期，强调团队协作、流程优化和持续交付。

       目的

       CI/CD的核心目标是快速、可靠地发布软件更新，确保产品质量，并通过自动化减少错误和延误。

       DevOps的目标是打破开发和运营之间的壁垒，实现高效协作，通过持续集成、测试和部署加速软件交付，同时提升产品质量和用户满意度。

       流程

       CI/CD流程通常包括源码、构建、测试和部署四个阶段。每个阶段都需要成功完成才能进入下一个阶段，并通过自动化工具监控和优化流程。

       DevOps流程涵盖持续开发、集成、测试、监控、反馈和部署等阶段，强调从规划到运营的全面自动化和协作。

       实施

       CI/CD的实施通常依赖于自动化工具，如Jenkins、Git等，来实现持续集成和交付的自动化。

       DevOps的实施则需要一个全面的策略，包括文化变革、流程优化、工具集成和跨团队协作，以实现持续改进和高效运营。

       阶段

       CI/CD阶段包括源码、构建、测试和部署。每个阶段通过自动化工具确保流程高效、可靠。

       DevOps阶段包括持续开发、集成、测试、监控、反馈和部署，强调从开发到运营的全面自动化和协作。

       好处

       CI/CD的好处包括提高开发效率、减少错误、加快发布速度以及提升软件质量。

       DevOps的好处涉及提高团队协作、加速产品交付、提升产品质量和用户满意度，以及推动组织文化的转变。

       综上所述，尽管CI/CD和DevOps都追求快速、高效和可靠的软件开发，但它们在范围、目的、流程、实现、阶段和优势上存在差异，各自强调的方面和实施策略也有所不同。正确理解并结合使用这两个概念，可以显著提升软件开发和运营效率。

什么是CI/CD？

       CI（Continuous Integration，持续集成）/CD（Continuous Delivery/Continuous Deployment，持续交付/持续部署）是DevOps的核心概念，旨在将软件开发过程中的代码构建、测试、部署以及基础设施配置等流程从人工操作转变为自动化。CI/CD管道有助于加速代码发布，同时减少人工错误。

       持续集成要求开发团队定期共享代码更改，并在每次更改后自动检查代码质量。通过自动化构建和测试流程，持续集成缩短了反馈周期，促进了团队间的协作。每次提交都会触发构建和测试，尽早发现并解决代码问题。

       持续集成与敏捷开发密切相关。敏捷开发通过更短的周期快速完成开发和交付，持续集成则提供了技术手段，让开发人员能够实现更短的反馈循环。CI/CD流程能够应对开发团队在长期编码后整合多个独立模块的挑战，避免了大规模集成时的返工和延误。

       持续集成的关键要素包括源代码或版本控制系统的统一存储库、自动构建脚本、自动化测试、以及运行构建和测试的基础设施。实践过程中，开发人员需要定期提交代码到主干，构建解决方案并通过自动化测试，将自动化测试集成到新功能中，持续监视构建和测试结果，并与质量保证团队合作，优化工作流程。

       持续交付与持续部署的区别在于持续交付允许在部署到生产环境时手动确认，而持续部署实现了从构建、测试到部署的自动化流程。持续部署可以实现快速发布，让开发人员在不影响质量的情况下，为用户提供新功能。主流的持续部署模式包括金丝雀部署、蓝绿部署和暗启动部署，每种模式都有其适用场景和特点。

       实施持续部署时，企业需注意文化适应、团队协作、功能开关管理和避免手动测试复现等问题。建立持续部署文化，明确需求、时间点，以及使用功能标志控制代码可见性，对于确保部署成功至关重要。

       

参考资料：

JetBrains TeamCity, GitLab, Microsoft Docs,知乎专栏, 微信公众号：迪捷软件, 联系信息与公司简介。

什么是持续集成（CI）/持续部署（CD）？

       在软件开发中，持续集成（CI）和持续交付（CD）是两个常用的术语。它们究竟代表了什么含义呢？本文将为您详细解释这些概念以及与之相关的持续测试（CT）和持续部署（CD）。

       想象一下工厂的装配线，它以快速、自动化、可重复的方式生产出消费品。在软件开发领域，持续交付（CD）就是以类似的方式，从源代码生成发布版本。而启动这一过程的是持续集成（CI），它确保代码的质量，并将最终产品提供给用户。推动这一切高效运行的，正是运维开发（DevOps）践行者。

       “持续”一词在这里指的是一种随时可运行的状态，而非持续不断地运行。在软件开发中，它涵盖了多个核心概念和最佳实践。其中，将源代码转换为可发布产品的多个任务和作业串联而成的软件“管道”，就是持续交付管道。

       持续交付管道的工作流程通常包括源代码跟踪、构建、测试、指标采集和版本管理等方面。这些作业是自动化的、高效的，并且可重复的。如果作业成功，工作流管理器将触发管道中的下一个作业；如果作业失败，则会发出警报，以便尽快纠正问题。

       在持续交付管道中，快速失败（fail fast）是一种重要的概念。它指的是在管道流程中尽快发现问题并快速通知用户的方式，以便及时修正问题并重新提交代码。

       持续集成（CI）是在源代码变更后自动检测、拉取、构建和进行单元测试的过程。其目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。

       持续测试（CT）是指在代码通过持续交付管道时运行扩展范围的自动化测试的实践。它包括单元测试、集成测试、系统测试等多种形式，以确保代码质量。

       持续交付（CD）通常是指整个流程链，包括持续集成、持续测试和可选的持续部署。其目标是自动化、效率、可靠性、可重复性和质量保障。

       持续部署（CD）是指能够自动提供持续交付管道中发布版本给最终用户使用的想法。这可以通过蓝/绿测试/部署、金丝雀测试/部署、功能开关、暗箱发布等多种方法实现。

       运维开发（DevOps）是一种关于如何使开发和运维团队更容易合作开发和发布软件的一系列想法和推荐的实践。持续交付管道是DevOps理念的一种实现。

       管道即代码（pipeline-as-code）是将管道实现表示为代码，以便它可以与代码一起存储、评审、跟踪和重建的通用术语。

       DevOps如何影响生产软件的基础设施？传统的硬件系统需要配套的软件，而DevOps则通过标准化交付、虚拟机和容器等技术，实现了易于重现和可跟踪的环境。

安全风险是指什么

       在上一篇文章十大 CI/CD 安全风险（二），我们了解了依赖链滥用和基于流水线的访问控制不足这两大安全风险，并给出缓解风险的安全建议。本篇文章将着重介绍 PPE 风险，并提供缓解相关风险的安全建议与实践。

       Poisoned Pipeline Execution (PPE) 风险指的是攻击者能够访问源代码控制系统，但无法访问构建环境，通过将恶意代码/命令注入构建流水线配置来操纵构建过程，本质上是“中毒的”流水线和运行恶意代码作为构建过程的一部分。

       PPE 风险通常存在代码仓库中，可控对应的 CI 管道配置文件，通过修改 CI 配置文件达到执行对应命令的目的。有权操作 CI 配置文件或 CI 流水线任务所依赖的其他文件的攻击者，可以将恶意命令置入这些文件，通过执行这些恶意命令，最终“毒化”执行这些命令的 CI 流水线。执行未经审查的代码的流水线，比如一些直接由拉取请求或提交到任意存储库分支触发的流水线，由于在设计上包含未经任何审查或批准的代码，更容易受到 PPE 风险的影响。一旦能够在 CI 流水线中执行恶意代码，攻击者就可以在流水线身份的上下文中进行各种恶意操作。

       直接 PPE（D-PPE）

       在 D-PPE 场景中，攻击者修改他们有权访问的存储库中的 CI 配置文件，通过直接将更改推送到存储库上未受保护的远程分支，在提交 PR 时随着分叉的更改而变化。由于 CI 流水线执行是由“push”或“PR”事件触发的，并且流水线执行是由修改后的 CI 配置文件中的命令定义的，一旦构建流水线被攻击，攻击者的恶意命令最终会在构建节点中运行触发。

       间接 PPE（I-PPE）

       在以下几种情况下，即便攻击者能够访问 SCM 存储库，也无法使用 D-PPE：

       在这几种情况下，攻击者就会选择向流水线配置文件引用的文件中注入恶意代码来破坏流水线：

       因此，在 I-PPE 中，不同于将恶意命令直接插入流水线定义文件来破坏流水线，攻击者通过将恶意代码注入到配置文件引用的文件中，一旦触发流水线并运行相关文件中声明的命令，恶意代码最终会在流水线节点上执行。

       公共 PPE（3PE）

       执行 PPE 攻击需要访问托管流水线配置文件的存储库或其引用的文件。大多数情况下，只有开发人员拥有此类许可，也就是说攻击者必须要获得开发工程师对存储库的许可和权限才能执行直接或间接 PPE 攻击。

       然而，在一些情况下，互联网上的匿名攻击者可以使用“中毒的” CI 流水线：公共存储库（例如开源项目）通常允许任何用户做出贡献，通过创建拉取请求，建议对代码进行更改。这些项目通常使用 CI 解决方案自动测试和构建，与私有项目类似。如果公共存储库的 CI 流水线运行匿名用户建议的未经审查的代码，它很容易受到公共 PPE 攻击，或者简称为 3PE。如果易受攻击的公共存储库的流水线在与私有存储库相同的 CI 实例上运行，这也会暴露例如私有项目的敏感信息这类的内部资产。

       通过 D-PPE (GitHub Actions) 窃取凭据

       在以下示例中，GitHub 存储库与 GitHub Actions 工作流程连接，该工作流程获取代码、构建代码、运行测试并最终将工件部署到 AWS。当新代码被推送到存储库中的远程分支时，代码（包括流水线配置文件）由运行程序（工作流节点）获取。

       在这种情况下，D-PPE 攻击将按如下方式进行：

       3. 流水线基于被攻击者“毒化”的配置文件运行。根据攻击者的恶意命令，存储为存储库机密的 AWS 凭证被加载到内存中。

       4. 流水线继续执行攻击者的命令，将 AWS 凭证发送到攻击者控制的服务器。

       5. 攻击者随后能够使用窃取的凭证访问 AWS 生产环境。

       通过 Indirect-PPE (Jenkins) 窃取凭证

       这个例子展示的是 Jenkins 流水线从存储库中获取代码、构建、运行测试并最终部署到 AWS。在此流水线中，Jenkinsfile 是受保护的，因为是从存储库中的主分支中获取的。因此，攻击者无法操纵构建定义，也无法获取存储在 Jenkins 凭证存储中的机密或在其他节点上运行任务。

       然而这并不代表流水线没有风险。在流水线的构建阶段，AWS 凭证作为环境变量加载，使其仅可用于在此阶段运行的命令。在下面的示例中，基于 Makefile 的内容（也存储在存储库中）的make命令作为此阶段的一部分运行。

       The Jenkinsfile：

       在这种情况下，I-PPE 攻击将按如下方式进行：

       在成功的 PPE 攻击中，攻击者在 CI 中执行未经审查的恶意代码。这为攻击者提供了与构建任务相同的能力和访问级别，包括：

       预防和缓解 PPE 攻击，涉及跨 SCM 和 CI 系统的多项措施：