«DevSecOps para Iniciantes»: Testando Pipelines CI/CD com Vulnerabilidades Reais

Nos seis episódios anteriores, construímos nosso próprio pipeline de desenvolvimento seguro: configuramos máquinas virtuais, estabelecemos a infraestrutura com GitLab, Vault, Nexus, DefectDojo e Dependency-Track, criamos um pipeline CI/CD, integramos scanners de segurança e configuramos backups. A questão principal que permanece é: nosso pipeline consegue identificar vulnerabilidades reais, ou apenas exibe "checkmarks" verdes para os desenvolvedores no GitLab? Como diz o ditado antigo dos "DevSecOps Boyars": "No nosso negócio, não acreditamos em palavras – a segurança precisa ser verificada".

Portanto, hoje submeteremos nosso pipeline a um teste de fogo. Utilizaremos a aplicação vulnerável Reactvulna, a carregaremos no GitLab e a executaremos através do pipeline que construímos. Em seguida, analisaremos os resultados do escaneamento e veremos quão bem nossa infraestrutura integrada lida com a detecção de problemas de segurança. É importante estabelecer um acordo inicial: este ciclo de artigos não substitui os requisitos de metodologias sérias de desenvolvimento seguro como GOST, OWASP SAMM, BSIMM, entre outras. É, antes, um exemplo prático de como organizar um pipeline de desenvolvimento seguro de software com investimento mínimo. Tudo o que é descrito no ciclo é puramente minha experiência pessoal, os "tropeços" que tive e os resultados de longas noites debruçado sobre o teclado. Não representa a posição oficial dos meus empregadores atuais ou anteriores. Não encare este artigo como um guia para cópia cega; teste tudo em ambientes de teste, faça backups e aborde experimentos com a cabeça fria. Erros são possíveis, e não se deve ter medo de cometê-los. O importante é tirar conclusões e construir gradualmente processos mais confiáveis do que os de ontem.

Para testar o pipeline, utilizaremos o Reactvulna – uma aplicação React propositalmente vulnerável para testar ferramentas de segurança. À primeira vista, é um serviço web comum para compra de ingressos de cinema, com autenticação de usuários, catálogo de filmes, chat e outras funcionalidades familiares. No entanto, por baixo do capô, os desenvolvedores deixaram intencionalmente um conjunto de vulnerabilidades típicas, incluindo XSS, CSRF, segredos de teste no código-fonte e outros problemas de segurança comuns. Vamos analisar alguns exemplos:

1. XSS (Cross-Site Scripting): A aplicação possui várias vulnerabilidades XSS. Uma delas está na função websocketMessageArrived. O nome do usuário (chatMessage.author.name) e o texto da mensagem (chatMessage.message) são inseridos diretamente no innerHTML do elemento <p>. O código relevante é: p.innerHTML = '<span><i>' + chatMessage.author.name + '</i></span><span>:&nbsp;</span><span>' + chatMessage.message + '</span>'. Isso permite a injeção de scripts maliciosos.
2. CSRF (Cross-Site Request Forgery): Na função sendChatToBackend, as requisições PUT são executadas sem o uso de tokens CSRF. Se um usuário já estiver autenticado na aplicação, um atacante pode tentar forçar o navegador dele a executar tal requisição em seu nome. O trecho de código é: fetch(Constants.backendRESTUrlBase + 'messages/chat', { method: 'PUT', credentials: 'include', headers: { 'Content-Type': 'application/json', 'Cache': 'no-cache' }, body: JSON.stringify({text: text, toUser: addressee}) });.
3. Hardcoded Secrets: No código-fonte do Reactvulna, incluí um arquivo config.js contendo chaves de API para um serviço de análise fictício. Verificaremos se o Gitleaks consegue encontrá-las.
4. Cabeçalhos Inseguros: A configuração da aplicação não inclui Content Security Policy (CSP). Esta é uma das descobertas que nos motivou a integrar o Nuclei ao nosso pipeline.
5. Dependências Vulneráveis: O package.json contém versões desatualizadas de bibliotecas com vulnerabilidades conhecidas. Tais problemas devem ser detectados por ferramentas de análise de dependências e geração de SBOM.
6. Armazenamento Inseguro de Tokens: Após a autenticação bem-sucedida, o token JWT é armazenado no localStorage em vez de um cookie httpOnly. Combinado com XSS, isso permite o acesso ao token do usuário. O código em src/Login.js demonstra isso: window.localStorage.setItem('loggedIn', true); window.localStorage.setItem('loggedInUser', JSON.stringify(loginResponse));.

Se nosso pipeline de desenvolvimento seguro encontrar pelo menos uma parte desses problemas, já será um bom resultado. Se algo for perdido, ajustaremos as configurações, alteraremos as regras para o Opengrep e adicionaremos verificações customizadas no Nuclei. O mais importante é obtermos uma imagem honesta do que o pipeline vê e o que permanece em sua zona cega. Isso é inestimável para um startup que não quer ir para produção com "caravelas" sob os pés. É melhor cair uma vez em um campo de treinamento do que em um ambiente de produção. O Reactvulna é uma "caixa de areia", um "boneco de treino". Após cada grande atualização de ferramentas, é útil retestar o pipeline com ele e verificar se a qualidade da detecção de problemas mudou. Se houver progresso – ótimo. Se não – significa que ainda há algo a ser aprimorado.

Começamos clonando o repositório Reactvulna e o carregando no GitLab. Em seguida, preparamos as integrações necessárias: criamos um produto no DefectDojo e um projeto no Dependency-Track, além de adicionarmos as variáveis do GitLab DEPENDENCY_TRACK_PROJECT_DOCKER_UUID, DEPENDENCY_TRACK_PROJECT_UUID e DOJO_PRODUCT_ID. Agora, podemos executar o pipeline e verificar seu desempenho em uma aplicação real. O Gitleaks escaneará por segredos, o Opengrep buscará vulnerabilidades no código, o Trivy gerará o SBOM e o Nuclei realizará o escaneamento dinâmico da aplicação em execução. Os relatórios obtidos serão enviados automaticamente para o DefectDojo e Dependency-Track. Após a conclusão do pipeline, acessaremos o DefectDojo para ver quais descobertas foram incluídas nos relatórios finais. Em seguida, compararemos os resultados com a lista de vulnerabilidades conhecidas do Reactvulna, publicada pelos autores do projeto. Tentaremos rastrear tanto as vulnerabilidades perdidas quanto os falsos positivos. Esperamos que o pipeline de desenvolvimento seguro detecte entre 70% e 90% das vulnerabilidades inseridas. As ferramentas não são onipotentes, portanto, não esperamos um resultado de 100%. No entanto, o Gitleaks deve encontrar segredos no código sem dificuldade, o Trivy certamente chamará a atenção para dependências desatualizadas, e o Nuclei não deixará de lado problemas de segurança nos cabeçalhos.

Para começar, verificamos se o artefato construído foi carregado no Nexus. Tudo normal: o artefato está no lugar e a tag BUGS está presente. Verificamos o Dependency-Track. A importação também foi concluída com sucesso. Verificamos os resultados da análise de dependências no Dependency-Track. Como previmos, a ferramenta detectou um grande número de vulnerabilidades. Adicionalmente, podemos visualizar o grafo de dependências da aplicação. Não esquecemos do contêiner. Para a imagem Docker, o Dependency-Track também construiu com sucesso o grafo de dependências e realizou a análise de vulnerabilidades. Foram encontradas algumas vulnerabilidades no curl. Agora, verificamos quais defeitos foram encontrados nas etapas de secrets-scan, sast, iac-scan e dast. Navegamos até o DefectDojo e verificamos se um novo "Engagement" apareceu para a execução atual do pipeline. Spoiler: tudo funcionou perfeitamente. No total, os scanners coletaram 97 descobertas. Parte delas certamente serão falsos positivos, então agora é hora de comparar os resultados com a lista de vulnerabilidades conhecidas do Reactvulna e ver quão precisamente nosso pipeline funcionou. É preciso considerar que o Opengrep consegue encontrar não apenas erros no código, mas também alguns problemas de IaC e segredos. Devido a isso, parte dos defeitos pode aparecer várias vezes, mas com diferentes fontes de detecção. Para verificar os relatórios dos scanners, filtraremos a lista pelo campo Test Type com valores de Found By. Estamos interessados nos valores Semgrep JSON Report, Gitleaks Scan, Nuclei Scan e Checkov Scan. Começando com o Semgrep JSON Report, encontramos o XSS: Em seguida, encontramos o segredo de teste: Detectamos a ausência de content-security-policy na configuração: Também foi detectado um defeito no arquivo Docker: Em geral, não consegui encontrar apenas o CSRF na lista de defeitos, mas talvez eu não tenha procurado bem. Podemos considerar o teste um sucesso! Importante não é apenas quais vulnerabilidades foram detectadas, mas como o próprio pipeline funcionou. Todas as etapas foram concluídas com sucesso: compilação da aplicação, geração de SBOM, busca por segredos, análise estática, verificação de código de infraestrutura, escaneamento dinâmico, bem como a publicação dos resultados no DefectDojo, Dependency-Track e Nexus. Vale a pena prestar atenção especial à velocidade de execução. Com o conjunto completo de verificações, o pipeline concluiu o trabalho em um tempo razoável. Para os desenvolvedores, isso é tão importante quanto a qualidade da detecção de vulnerabilidades: se as verificações forem muito lentas, a equipe rapidamente as começará a perceber como um obstáculo. A figura abaixo mostra os jobs do pipeline executado e o tempo de trabalho de cada etapa. Em resumo, o pipeline passou com sucesso no teste com a aplicação vulnerável. A maioria dos problemas esperados foi detectada automaticamente, e as integrações com serviços externos funcionaram sem falhas.

Voltando ao nosso "reino de startup". Lembra-se de como tudo começou? Um jovem CEO, prazos apertados, hackers mal-intencionados à porta, vazamento de bancos de dados, usuários fugindo... E agora, vamos ver o que nós, com os "boyars" desenvolvedores, conseguimos construir. Em sete artigos, passo a passo, construímos nosso próprio pipeline de desenvolvimento seguro, utilizando ferramentas gratuitas e hardware comum. Não tínhamos assinaturas "gold", clusters na nuvem por um milhão de moedas e um exército de engenheiros DevSecOps. Viemos com VirtualBox gratuito, cinco máquinas virtuais em um PC doméstico e ferramentas de código aberto. O que alcançamos em nosso reino? Os "boyars" desenvolvedores:

• Aprenderam a "alfabetização" da segurança.
• Pararam de armazenar senhas e segredos no repositório – o Gitleaks os captura em tempo real.
• Pararam de escrever código "furado" – o Opengrep destaca defeitos de segurança e funções perigosas.
• Pararam de construir contêineres como root – o Checkov reclama do Dockerfile.
• Pararam de implantar em produção sem verificações – o Nuclei escaneia a aplicação em tempo real.
• Pararam de perder dependências – SBOM e Dependency-Track monitoram cada pacote.
• Pararam de adivinhar qual imagem é de quem – o Nexus armazena tudo com tags claras (e até :bugs, se algo quebrar).
• Pararam de se perder em relatórios – o DefectDojo coleta tudo em um só lugar e deduplica.
• Pararam de temer falhas – backups são feitos todas as noites, mesmo que o PC esteja em modo de suspensão.

O trabalho para os desenvolvedores, é claro, aumentou. Mas não tanto a ponto de iniciar um motim. Concordamos em corrigir vulnerabilidades reais em primeiro lugar, e deixar o restante para refatoração planejada. E o que dizer do "rei"? O "rei" até recompensou os "boyars" – não com ouro, mas com novos servidores e permissão para finalmente parar de economizar cada megabyte. Mas o laboratório antigo foi mantido – para memória e para novos experimentos. No "reino" permaneceu um baú inteiro de conhecimento:

• Como planejar um RBPO do zero.
• Como implantar cinco máquinas virtuais e conectá-las em rede.
• Como instalar GitLab, Nexus, Vault, DefectDojo, Dependency-Track e scanners CLI.
• Como configurar tudo isso, conectar autenticação JWT.
• Como escrever um pipeline multi-etapas com quatro fases e dez jobs: obter segredos do Vault, gerar SBOM, escanear código e contêineres, enviar relatórios para DefectDojo e Dependency-Track, e imagens para o Nexus.
• Como fazer backup e não chorar se o disco falhar.
• Como testar todo o sistema em uma aplicação vulnerável e garantir que ele funcione.

A principal lição de todo o ciclo foi bastante simples. A segurança não surge por si só. Ela precisa ser construída gradualmente, "tijolo por tijolo". Mas se for feita de forma consistente, mesmo com os materiais mais modestos, é possível construir um "terem" (uma casa tradicional russa) sólido. "A história é uma mentira, mas há uma dica nela"... E este ciclo de artigos não é uma história, mas uma realidade. Eu mesmo passei por esse caminho, cometi erros e tentei resumir minha experiência neste ciclo. Agora você poderá seguir o mesmo caminho mais rápido e com mais confiança, sem pisar nos meus "degraus". E se encontrar novos – conte sobre eles. E agora, vá, "príncipe-startup". Construa seus pipelines, proteja seu código, desenvolva seu "reino" e implemente desenvolvimento seguro onde ontem não havia tempo nem recursos para isso. Que seus pipelines sejam verdes, seus segredos – bem escondidos, e seus relatórios de escaneamento – chatos e vazios :)

Se este ciclo foi útil – compartilhe os artigos com colegas, dê "likes" e escreva comentários no Habr. O que vem a seguir? Durante o trabalho neste ciclo, me convenci de uma coisa: mesmo um pipeline aparentemente completo como este, sempre pode ser melhorado. Apesar do final desta série, ainda há muitos temas para continuação. É possível configurar notificações em mensageiros ao aparecerem novas vulnerabilidades, integrar um repositório interno de dependências ao processo de desenvolvimento, conectar novas ferramentas de análise e discutir muitos outros cenários práticos. Fim do ciclo ou início de um novo? A decisão é sua! PURP – um canal no Telegram onde a cibersegurança é revelada de ambos os lados da barricada: t.me/purp_sec – insights e informações do mundo do hacking ético e da proteção orientada a negócios por especialistas da Bastion.