No início deste ano, nossa equipe foi incumbida de aprimorar nossas ferramentas de segurança e práticas de desenvolvimento e teste de software existentes para garantir a conformidade com PCI-DSS e SOC-2. Uma das principais áreas que precisávamos aprimorar era a varredura de vulnerabilidades em nossos microsserviços baseados em K8s e em alguns serviços monolíticos. Por isso, nossa equipe de DevOps teve que escolher entre algumas ferramentas comerciais e soluções de código aberto para implementar a varredura de vulnerabilidades em nosso software. Todas essas ferramentas fazem coisas muito semelhantes: verificam as dependências (sejam bibliotecas do projeto ou pacotes do sistema operacional) e as comparam com bancos de dados de vulnerabilidades (como o NVD do NIST, entre outros).
Desenvolver ou comprar?
Existem algumas ferramentas de código aberto que podem ser usadas para criar sua própria solução de verificação de vulnerabilidades. Outra opção é usar um produto comercial que ofereça recursos adicionais além da verificação básica e facilite seu trabalho. Alguns exemplos incluem:
- Painéis intuitivos para uma visão geral rápida das vulnerabilidades em seus projetos
- Notificações (e-mail, Slack etc.)
- Integração com repositórios Git (GitHub, GitLab)
- Integração com outros serviços (registro do Docker, Kubernetes)
- Integração com ferramentas de gerenciamento de projetos (por exemplo, Jira)
- Criação automática de solicitações de merge para corrigir dependências vulneráveis
- Suporte a equipes, projetos e RBAC
A maioria das soluções comerciais complementa os bancos de dados públicos de vulnerabilidades com seu próprio banco de dados para eliminar falsos positivos e negativos e fornecer resultados mais relevantes. Dito isso, todas essas ferramentas comerciais ficam muito caras à medida que o número de desenvolvedores aumenta. Portanto, você precisa avaliar se é “melhor” comprar uma solução ou criar a sua própria usando ferramentas de código aberto existentes.
Inicialmente, decidimos que uma ferramenta comercial atenderia melhor às nossas necessidades, considerando a limitação de tempo que tínhamos. No entanto, depois de passarmos três meses implantando e testando um produto comercial líder do setor, enfrentamos muitos desafios — suporte limitado a Golang, identificação de dependências incorretas e encerramento inadequado, problemas com contêineres criados do zero em comparação com aqueles criados a partir de uma imagem base etc. Como resultado, decidimos abandoná-lo e passar a desenvolver nossa própria ferramenta usando as tecnologias de código aberto disponíveis.
Neste post, vou fornecer uma base sólida para você começar caso opte por uma solução de código aberto. Além disso, no final do post, você encontrará o link para o nosso repositório de código aberto para dar os primeiros passos!
O que verificar?
Basicamente, há duas coisas que você deve verificar em busca de vulnerabilidades:
- As dependências de código do seu projeto (yarn.lock, Gopkg.lock etc.)
- Dependências do sistema operacional (pacotes Debian, pacotes Alpine etc.) em uma imagem Docker
No futuro, será possível adicionar mais recursos, como verificação de licenças ou análise estática de código, mas isso está fora do escopo deste artigo.
Quando fazer a verificação?
Antes de tudo, é importante garantir que nenhuma nova vulnerabilidade seja introduzida por alterações no código ou na imagem Docker. Por isso, é recomendável verificar cada solicitação de merge antes que ela seja integrada.
Mas você também precisa realizar verificações periodicamente, pois novas vulnerabilidades podem surgir com o tempo. Além disso, os níveis de gravidade podem mudar — uma vulnerabilidade de baixa gravidade que você inicialmente ignorou pode se tornar crítica com o tempo, à medida que um novo vetor de ataque ou exploit é descoberto. Embora as ferramentas comerciais mantenham um registro da última verificação e notifiquem você caso uma nova vulnerabilidade seja encontrada, em nossa solução de código aberto, simplesmente repetimos a verificação na branch master do projeto.
Escolhendo ferramentas
Há muitas ferramentas de código aberto disponíveis, mas escolhemos o Trivy porque ele é fácil de usar, está em desenvolvimento ativo e consegue verificar vários projetos e tipos de sistemas operacionais.
O Trivy é um scanner de vulnerabilidades simples e abrangente para contêineres e outros artefatos. Uma vulnerabilidade de software é um erro, uma falha ou um ponto fraco presente no software ou em um sistema operacional. O Trivy detecta vulnerabilidades em pacotes de sistemas operacionais (Alpine, RHEL, CentOS etc.) e dependências de aplicações (Bundler, Composer, npm, yarn etc.). O Trivy é fácil de usar — basta instalar o binário e você já pode começar a verificar! Para realizar a verificação, basta especificar um alvo, como o nome da imagem do contêiner.
Ele pode ser facilmente instalado e executado localmente na imagem Docker criada ou na raiz do projeto. Também oferece suporte a vários formatos de saída, incluindo JSON e tabelas:
Infelizmente, há projetos que o Trivy não consegue verificar (por exemplo, em Golang), então tivemos que recorrer ao OWASP Dependency-Check porque grande parte do nosso código é escrita em Golang.
O Dependency-Check é uma ferramenta de Análise de Composição de Software (SCA) que busca detectar vulnerabilidades divulgadas publicamente nas dependências de um projeto. Para isso, ele verifica se existe um identificador de Enumeração de Plataforma Comum (CPE) para determinada dependência. Se encontrado, ele gera um relatório com links para as entradas de CVE associadas.
Ele pode gerar páginas HTML com relatórios, além de saídas nos formatos JUnit e JSON (entre outros).
Relatórios e painéis
Agora estamos chegando a coisas mais interessantes 😊
Como já usamos Elasticsearch + Kibana + Fluentd em nossas equipes de DevOps e SRE, foi natural aproveitar a infraestrutura existente para analisar a saída JSON de nossas verificações de segurança.
Só precisávamos encontrar uma maneira de enviar dados de uma infraestrutura não confiável (runners de CI) para o nosso Elasticsearch seguro. Para isso, decidimos usar uma fila de mensagens como intermediária. O Fluentd tem o plugin in_sqs para ler mensagens do Amazon SQS, que também é simples de usar. Assim, a arquitetura final ficou assim:
Depois que os dados chegam ao Elasticsearch, é fácil criar alguns painéis com o Kibana ou usar o Discover para consultar vulnerabilidades com todos os detalhes necessários.
Correção de vulnerabilidades
Agora que temos as varreduras e um bom painel, qual é o próximo passo? Não podemos esperar que os desenvolvedores monitorem esses painéis regularmente. Por isso, decidimos fazer com que a CI falhe quando for encontrado um problema de severidade alta ou superior para o qual haja uma correção disponível. Dessa forma, a responsabilidade passa para os desenvolvedores e responsáveis pelos projetos.
Naturalmente, precisávamos ter uma opção para adicionar algumas CVEs à lista de permissões ou substituir esse comportamento padrão para cada projeto. Por isso, criamos um repositório com perfis de verificação de segurança, que são utilizados pela nossa ferramenta de verificação, responsável por encapsular a execução do Trivy e gerenciar seu comportamento e sua saída.
Agora, qualquer pessoa desenvolvedora pode enviar uma solicitação de merge para este repositório e pedir uma exceção. Exemplo de perfil para o projeto kibana :
Melhorias futuras
Esta implementação de verificação de segurança é uma base sólida que pode ser ampliada para além dos nossos casos de uso iniciais. Por exemplo:
- Adicione notificações do Slack e use perfis de segurança para especificar o canal e as opções de cada projeto
- Adicionar integração com o GitLab Issues, Jira ou qualquer outro sistema de gerenciamento de chamados
- Criar um serviço simples ou sidecar para executar a verificação das imagens implantadas no cluster Kubernetes
Faça um fork e use-o
Você pode encontrar o Dockerfile e as ferramentas em nosso repositório público no GitLab: https://gitlab.com/volterra.io/security-scanning
Agradecimentos a Jakub Pavlík.
Publicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...