在持续集成流水线中应用 Gen AI 识别并修复漏洞

最新推荐文章于 2024-09-27 16:14:00 发布

AI人工智能集结号

最新推荐文章于 2024-09-27 16:14:00 发布

阅读量644

点赞数 16

文章标签： ci/cd 人工智能

本文链接：https://blog.csdn.net/sdfghkhsab/article/details/142577811

版权

概述

现代化应用的高速发展使开发人员能够构建高度解耦的基于微服务的架构。然而，这些架构的分布式特性同时也带来了一系列的运维挑战。开发团队需要一直负责应用环境安全的各个方面，如网络安全、IAM 权限、TLS 证书和代码漏洞扫描。在数十甚至上百个微服务的规模下处理这些安全问题，高度自动化变得尤为重要。

在容器中运行应用程序是构建微服务的常用方法。该方法允许开发人员使用同样的持续集成流水线来构建应用程序，而无需关心是使用 Amazon EKS、Amazon ECS 还是 AWS Lambda 来运行应用程序。同时，无论使用何种编程语言开发应用程序，最终的可部署对象都是一个包含应用程序代码及其依赖项的容器镜像。因此，应用程序开发团队必须扫描这些镜像中的漏洞，以确保它们在部署到云环境之前的安全性。Amazon ECR 是一个支持 OCI 规范的制品库，提供由 Amazon Inspector 支持的两种镜像扫描类型：基本扫描和增强扫描。镜像扫描一般发生在容器镜像被推送到制品库之后。基本扫描会在新镜像推送之后自动触发，而增强扫描则会持续对托管在 Amazon ECR 中的镜像进行扫描。两种类型的扫描都会生成扫描报告，但开发团队仍需要采取一系列的行动，其中包括阅读报告、了解漏洞、修改代码、提交拉取请求、合并代码、并再次运行持续集成流水线。下面将说明如何利用生成式人工智能和事件驱动的无服务器架构组成的解决方案来自动化这一过程。

以下解决方案使用了“上下文学习”的方法，这是一种针对特定场景定制人工智能响应的技术。在此处，该解决方案会根据所涉及的编程语言和预先生成的拉取请求例子来构建提示词。这种方法凸显了一个关键点：对于一些特定的应用场景，使用较小的大语言模型（如 Llama 13B），同时结合辅助性的提示词，所产生的结果可能和单纯使用较大的大语言模型（如 Llama 2 70B）类似。这里建议您评估两种形式并从中找到最适合您的用法，一是使用较小的大语言模型，同时结合少样本提示；二是使用较大的大语言模型，但结合的是零样本提示。您可以在 Amazon Bedrock 的文档中获取更多关于提供提示词和样本的信息。

方案架构

在将应用程序打包为容器镜像之前，开发团队应确保他们的持续集成流水线包含了静态代码扫描和镜像分析等步骤，以尽早发现和修复代码中的潜在漏洞。开发团队可使用诸如 SonarQube 或 Amazon CodeGuru 之类的工具对源代码进行静态扫描，并使用诸如 Trivy 或 Docker Scout 等工具分析容器镜像。在开发的早期阶段检测和解决代码中潜在的安全威胁，体现了”左移” (Shift-Left) 的理念。

将新的应用程序代码打包成镜像并推送到 Amazon ECR 之后，会自动触发 Amazon Inspector 对该容器镜像进行扫描。在镜像扫描运行的过程中，Amazon Inspector 会为检测到的每个漏洞发出 EventBridge Finding 事件。下图展示了整个工作流。

开发人员将新代码推送到共享的代码仓库，触发持续集成流水线。这一步并没有在接下来的示例中实现，不同的开发团队可选用不同的工具来实现这一步。
应用程序的容器镜像被推送到 Amazon ECR 。
Amazon Inspector 会自动触发对该镜像的扫描（需事先在账户中启用增强扫描）。
扫描过程中，Inspector 会将发现的每个漏洞以事件的格式发送到 Amazon EventBridge。每一个漏洞都会生成一个独立的事件。事件样例可参考这里。
针对每个漏洞事件，EventBridge 都会调用一个 AWS Lambda 函数。
该 Lambda 函数会将每个漏洞的信息聚合并更新到 Amazon DynamoDB 数据库表中。
扫描完成后，Inspector 会向 EventBridge 发送一个扫描完成的事件，然后 EventBridge 会调用创建拉取请求的微服务。该服务是以 Amazon ECS Fargate Task 的形式运行，用于启动拉取请求的生成流程。
创建拉取请求的微服务的工作过程包括克隆代码仓库、检查依赖列表、从 DyamoDB 中获取漏洞数据、并结合依赖列表和漏洞数据，以及基于前面扫描所生成的上下文学习示例进行提示词的构建。最后则会调用 Amazon Bedrock 生成一个新的拉取请求。
拉取请求的内容生成后，该微服务会在代码仓库中创建新的拉取请求并推送上游。
开发团队审核并合并该拉取请求。同时，随着对该流程进一步的熟悉与信任，后面也可以考虑将合并的部分也自动化。

实施示例

请使用该示例项目在您的 AWS 账户中部署这一解决方案。按照 README.md 中的说明，使用 HashiCorp Terraform 来配置和测试该项目。

在该项目的 /apps 目录下，您会看到两个应用程序。其中 /apps/my-awesome-application 目录下的应用程序包含了一些存在漏洞的依赖项。这个应用程序是被用来创建拉取请求样例的。我们此前已经使用 Amazon Inspector 和 Amazon Bedrock 对这个应用进行分析，并基于结果生成了一个拉取请求的样例，存储在 in_context_examples.py 文件中。虽然这可能是一次性的手动过程，但我们也可以在后续的演变过程中，周期性地添加更多样例。

/apps/my-amazing-application 则是代表实际的业务应用程序。开发团队每天会多次地将该应用部署到不同环境，因此需要确保它不存在任何漏洞。基于之前创建的上下文样例，开发团队会持续使用 Amazon Inspector 检测新出现的漏洞，并利用 Amazon Bedrock 自动生成修复这些漏洞的拉取请求。

下面的例子展示了当开发团队成员引入了存在漏洞的依赖项时，Gen AI 自动生成的一个拉取请求。该请求包含了检测到的漏洞的详细信息，以及如何修补它们的建议。