O blog da AWS
Aplicação da IA generativa para remediação de CVE — correção precoce de vulnerabilidades em pipelines de integração contínua
Por Lucas Soriano Alves Duarte, Anton Aleksandrov, Rodrigo Bersa e Ravi Yadav
As tecnologias de nuvem são um cenário em rápida evolução. Proteger aplicativos em nuvem é responsabilidade de todos, o que significa que as equipes de desenvolvimento de aplicativos precisam seguir diretrizes rígidas de segurança desde os estágios iniciais de desenvolvimento e garantir verificações de segurança contínuas durante todo o ciclo de vida do aplicativo. O surgimento da IA generativa permite novas abordagens inovadoras para enfrentar desafios de longa data com menos esforço.
Esta postagem mostra como as equipes de engenharia podem automatizar a remediação eficiente de CVEs de contêineres (vulnerabilidades e exposições comuns) no início de seu pipeline de integração contínua (CI). Usando serviços em nuvem como Amazon Bedrock, Amazon Inspector, AWS Lambda e Amazon EventBridge, você pode arquitetar uma solução sem servidor baseada em eventos para tratar automaticamente a detecção e a correção de vulnerabilidades de contêineres. Usar o poder da IA generativa e das tecnologias sem servidor pode ajudar a simplificar o que costumava ser um desafio complexo.
Visão geral
O crescimento exponencial dos aplicativos modernos permitiu que os desenvolvedores criassem arquiteturas baseadas em microsserviços altamente dissociadas. No entanto, a natureza distribuída dessas arquiteturas vem com um conjunto de desafios operacionais. As equipes de engenharia sempre foram responsáveis por vários aspectos de segurança de seus ambientes de aplicativos, como segurança de rede, permissões de IAM, certificados TLS e verificação de vulnerabilidades de código. Abordar esses aspectos na escala de dezenas e centenas de microsserviços requer um alto grau de automação. A automação é fundamental para um dimensionamento eficiente, bem como para manter o controle e a governança.
A execução de aplicativos em contêineres é uma abordagem comum para criar microsserviços. Ele permite que os desenvolvedores tenham o mesmo pipeline de CI para seus aplicativos, independentemente de usarem o Amazon Elastic Kubernetes Service (Amazon EKS), o Amazon Elastic Container Service (Amazon ECS) ou o AWS Lambda para executá-los. Não importa qual linguagem de programação você usa para seu aplicativo, o artefato implantável é uma imagem de contêiner que geralmente inclui o código do aplicativo e suas dependências. É fundamental que as equipes de desenvolvimento de aplicativos examinem essas imagens em busca de vulnerabilidades para garantir sua segurança antes de implantá-las em ambientes de nuvem. O Amazon Elastic Container Registry (Amazon ECR) é um artefato de OCI que fornece dois tipos de escaneamento, básico e avançado, desenvolvido pelo Amazon Inspector. A análise da imagem ocorre depois que a imagem do contêiner é enviada para o registro. A análise básica é acionada automaticamente quando uma nova imagem é enviada, enquanto a analise avançada é executada continuamente para imagens hospedadas no Amazon ECR. Ambos os tipos de escaneamento geram relatórios de escaneamento, mas ainda é responsabilidade da equipe de desenvolvimento agir de acordo com isso: ler o relatório, entender as vulnerabilidades, corrigir o código, abrir um pull request(PR), mesclar e executar o CI novamente. As etapas a seguir ilustram como você pode criar uma solução automatizada que usa o poder da IA generativa e das arquiteturas sem servidor orientadas por eventos para automatizar esse processo.
O exemplo de solução a seguir usa a abordagem de “aprendizado em contexto”, uma técnica que adapta as respostas de IA a cenários restritos. Usada para patches de CVE, a solução cria solicitações de IA com base na linguagem de programação em questão e em um exemplo gerado anteriormente da aparência de um pull request(PR). Essa abordagem ressalta um ponto crucial: para alguns casos de uso restritos, usar um modelo de linguagem grande (LLM) menor, como o Llama 13B, com aviso assistido, pode produzir resultados igualmente eficazes quanto um LLM maior, como o Llama 2 70B. Recomendamos que você avalie os prompts de poucos disparos com LLMs menores(few-shot prompts with smaller LLMs) e solicitações de disparo zero com LLMs maiores(zero-shot prompts with larger LLMs) para encontrar o modelo que funciona com mais eficiência para você. Leia mais sobre como fornecer instruções e exemplos na documentação do Amazon Bedrock.
Arquitetura da solução
Antes de empacotar o aplicativo como um contêiner, as equipes de engenharia devem garantir que seu pipeline de CI inclua etapas como análise estática de código com ferramentas como SonarQube ou Amazon CodeGuru e ferramentas de análise de imagem, como Trivy ou Docker Scout. A validação de seu código em busca de vulnerabilidades nesse estágio está alinhada à mentalidade shift-left, e os engenheiros devem ser capazes de detectar e abordar possíveis ameaças em seu código nos estágios iniciais do desenvolvimento.
Depois de empacotar o novo código do aplicativo e enviá-lo para o Amazon ECR, o escaneamento da imagem com o Amazon Inspector é acionada. Os engenheiros podem usar linguagens suportadas pelo Amazon Inspector. À medida que o escaneamento da imagem é executada, o Amazon Inspector emite eventos do EventBridge Finding para cada vulnerabilidade detectada.
- A CI é acionada por um desenvolvedor que envia um novo código para o repositório de código compartilhado. Essa etapa não foi implementada no exemplo fornecido, e diferentes equipes de engenharia podem usar ferramentas diferentes para seu pipeline de CI.
- A imagem do contêiner do aplicativo é criada e enviada para o Amazon ECR.
- O Amazon Inspector é acionado automaticamente. Observe que você deve primeiro ativar o escaneamento avançado do Amazon Inspector ECR em sua conta.
- Conforme o Amazon Inspector escanea a imagem, ele emite descobertas em um formato de eventos para o EventBridge. Cada descoberta gera um evento separado. Veja o exemplo de carga útil
JSONde um evento de busca na documentação do Inspector. - O EventBridge está configurado para invocar uma função Lambda para cada evento de descoberta.
- O Lambda é invocado para cada descoberta. A função agrega e atualiza a tabela do banco de dados do Amazon DynamoDB com cada informação encontrada.
- Depois que o Amazon Inspector conclui a verificação, ele emite o evento de conclusão da verificação para o EventBridge, que chama o microsserviço de criação de Pull request(PR) hospedado como uma Amazon ECS Fargate Task para iniciar o processo de geração de pull request(PR).
- O microsserviço de criação de pull request(PR) clona o repositório de código para ver a lista de dependências atual. Em seguida, ele recupera os dados agregados das descobertas do DynamoDB e cria um prompt usando a lista de dependências, os dados das descobertas e o exemplo de aprendizado contextual com base em escaneamentos anteriores. O microsserviço invoca o Amazon Bedrock para gerar um novo conteúdo de pull request(PR).
- Depois que o conteúdo de pull request(PR) é gerado, o microsserviço abre um novo pull request(PR) e impulsiona as alterações.
- As equipes de engenharia validam o pull request(PR) e o mesclam com o repositório de código. Com o tempo, à medida que as equipes de engenharia ganham confiança no processo, elas também podem considerar automatizar a parte da fusão.
Exemplo de implementação
Use o projeto de exemplo para replicar essa solução em sua conta da AWS. Siga as instruções em README.md para provisionar e testar o projeto de amostra usando o Hashicorp Terraform.
No diretório /apps do projeto de amostra, você deve ver dois aplicativos. O /apps/my-awesome-application contém intencionalmente um conjunto de dependências vulneráveis. Esse aplicativo foi usado para criar exemplos de como deve ser um pull request(PR). Depois que a equipe de engenharia levou esse aplicativo ao Amazon Inspector e ao Amazon Bedrock manualmente, um arquivo contendo esse exemplo foi gerado. Consulte in_context_examples.py. Embora possa ser um processo manual único, as equipes de engenharia também podem adicionar mais exemplos periodicamente à medida que evoluem e melhoram a resposta generativa do modelo de IA.
O /apps/my-amazing-application é o aplicativo real no qual a equipe de engenharia trabalha para gerar valor comercial. Eles implantam esse aplicativo várias vezes ao dia em vários ambientes e querem garantir que ele não tenha vulnerabilidades. Com base no exemplo contextual criado anteriormente, eles usam continuamente o Amazon Inspector para detectar novas vulnerabilidades, bem como o Amazon Bedrock para gerar automaticamente pull request(PR) que corrigem essas vulnerabilidades.
O exemplo a seguir mostra uma pull request(PR) gerada quando um membro da equipe de desenvolvimento introduziu dependências vulneráveis. O pull request(PR) contém detalhes sobre os pacotes com vulnerabilidades detectadas e CVEs, bem como recomendações sobre como corrigi-los.
Além disso, o pull request(PR) já contém uma versão atualizada do arquivo requirements.txt com as alterações em vigor. A única coisa que resta para a equipe de engenharia fazer é revisar e mesclar o pull request(PR).
Conclusão
Esta postagem ilustra uma solução simples para lidar com vulnerabilidades de imagem de contêiner (OCI) usando serviços da AWS, como Amazon Inspector, Amazon ECR, Amazon Bedrock, Amazon EventBridge, AWS Lambda e Amazon Fargate. A natureza sem servidor e orientada por eventos dessa solução ajuda a garantir a eficiência de custos e a sobrecarga operacional mínima. As equipes de engenharia não precisam executar uma infraestrutura adicional para implementar essa solução.
Usar IA generativa e tecnologias sem servidor ajuda a simplificar o que costumava ser um processo complexo e trabalhoso. Ter um fluxo de trabalho automatizado permite que as equipes de engenharia se concentrem em fornecer valor comercial, melhorando assim a postura geral de segurança sem sobrecarga operacional adicional.
Referências
Este conteúdo é uma tradução do blog post original em inglês (link aqui).