Segurança de identidades para proteger pipelines

Um incidente de cadeia de software que chega às credenciais

A repercussão recente de um comprometimento na cadeia de software do LiteLLM reforça uma lição importante para empresas que desenvolvem, integram ou implantam aplicações com automação: o risco não termina na dependência alterada. Ele pode alcançar as identidades de máquina usadas pelos pipelines para acessar repositórios, provedores de nuvem, registros de contêineres, ambientes de produção e serviços de inteligência artificial.

O relatório oficial do Python Package Index (PyPI) descreveu que versões maliciosas dos pacotes LiteLLM foram publicadas após a exposição de um token de API associada a uma dependência explorada do Trivy. Segundo o PyPI, o código coletava credenciais e arquivos sensíveis durante a instalação. O advisory do ecossistema Python identifica as versões 1.82.7 e 1.82.8 como afetadas e orienta que credenciais disponíveis no ambiente de execução sejam tratadas como potencialmente expostas, com revogação, rotação e revisão do ambiente afetado. Leia o relatório do PyPI e consulte o advisory PYSEC-2026-2.

Isso não significa que toda organização que utiliza componentes semelhantes tenha sido comprometida. A decisão correta é diferente: avaliar rapidamente quais processos automatizados executaram artefatos potencialmente afetados, quais segredos estavam acessíveis a eles e se houve uso posterior dessas credenciais fora do comportamento esperado.

Por que pipelines concentram risco empresarial

CI/CD é a sigla para integração contínua e entrega ou implantação contínua. Em termos práticos, são os fluxos automatizados que constroem, testam e distribuem software. Para cumprir esse papel, um pipeline costuma receber permissões que uma estação de trabalho comum não deveria ter: publicar pacotes, criar imagens, alterar infraestrutura, implantar aplicações e consultar serviços externos.

Essas permissões são exercidas por identidades não humanas, também chamadas de identidades de máquina. Elas incluem contas de serviço, tokens de automação, chaves de API, certificados, chaves SSH e papéis assumidos em nuvem. Uma identidade de máquina não toma decisões por conta própria, mas autentica processos que tomam. Por isso, quando um pipeline é manipulado ou executa uma dependência maliciosa, o invasor pode tentar agir com a legitimidade operacional daquela identidade.

O impacto potencial deixa de ser apenas técnico. Uma credencial de publicação pode afetar a integridade de entregas a clientes. Um token de nuvem com privilégios excessivos pode permitir acesso a dados, interrupção de serviços ou aumento indevido de custos. Uma chave usada para integração com modelos de IA pode expor capacidade de consumo, configurações e dados trafegados pela aplicação. A questão para a liderança não é apenas “qual pacote foi instalado?”, mas “quais operações de negócio esse processo podia autorizar?”.

Boas práticas de segurança de CI/CD apontam que pipelines frequentemente executam tarefas com identidades privilegiadas e, por isso, têm alto potencial de impacto quando comprometidos. A orientação inclui controle de acesso, gestão de segredos, privilégios mínimos e visibilidade sobre os eventos do pipeline. Veja as recomendações da OWASP para segurança de CI/CD.

Segurança de identidades: o controle que limita o alcance do incidente

Segurança de identidades é o serviço central para transformar credenciais de automação em controles verificáveis, rastreáveis e proporcionais ao risco. No contexto de pipelines, ela não se resume a guardar senhas em variáveis protegidas. O objetivo é definir com precisão quem ou o que pode acessar cada recurso, em qual contexto, durante quanto tempo e com quais evidências de uso.

O primeiro passo é separar identidades por função e ambiente. Um processo que executa testes não deve usar a mesma conta de serviço capaz de implantar em produção. Da mesma forma, uma automação responsável por publicar uma imagem não precisa, necessariamente, listar segredos de toda a organização ou administrar recursos de nuvem fora do seu escopo.

Essa segregação reduz o chamado raio de impacto: a extensão do dano possível quando uma credencial é exposta. Em vez de um único token permanente abrir acesso a diversos ambientes, cada etapa recebe uma identidade própria, permissões restritas e regras de uso compatíveis com sua finalidade.

O caso analisado também evidencia por que tokens estáticos merecem atenção prioritária. Credenciais de longa duração continuam válidas até serem manualmente revogadas ou expirarem. Já mecanismos baseados em federação de identidade podem emitir credenciais temporárias para uma execução específica, vinculadas ao repositório, ao workflow e ao contexto autorizado. Na publicação de pacotes, por exemplo, o PyPI descreve o uso de OpenID Connect para trocar uma identidade do ambiente de CI por um token temporário, eliminando a necessidade de manter tokens de API criados manualmente no pipeline. Entenda o modelo de Trusted Publishing do PyPI.

O que revisar após uma suspeita de exposição

Quando uma dependência, ação de automação ou artefato executado pelo pipeline entra em uma investigação, remover o componente é necessário, mas insuficiente. A organização precisa conduzir uma análise orientada por identidade e por impacto operacional.

• Identificar os pipelines e runners envolvidos: verificar quais execuções utilizaram a versão, a ação ou o artefato sob análise; incluir ambientes de desenvolvimento, homologação e produção.
• Mapear os segredos acessíveis em cada execução: considerar variáveis de ambiente, tokens de nuvem, chaves de registro de contêiner, credenciais de banco de dados, chaves SSH, certificados e tokens de publicação.
• Priorizar revogação e rotação por risco: começar por credenciais com acesso a produção, dados sensíveis, funções administrativas ou capacidade de distribuir software. Revogar sessões e tokens derivados é tão importante quanto gerar uma nova chave.
• Validar permissões efetivas: uma conta pode ter recebido mais acesso do que utiliza. Comparar a finalidade do pipeline com as ações realmente autorizadas revela privilégios que devem ser removidos.
• Investigar uso anômalo: buscar autenticações em horários, origens, regiões, repositórios, serviços ou volumes de consulta incompatíveis com o padrão da automação.
• Preservar evidências operacionais: logs de pipeline, auditoria do provedor de identidade, trilhas de nuvem e eventos de repositório ajudam a estabelecer cronologia, escopo e decisões de resposta.

No incidente que envolveu componentes open source do Trivy, a orientação oficial foi tratar como expostos todos os segredos acessíveis aos ambientes de execução potencialmente afetados, além de auditar versões, referências de automação e registros de execução. A recomendação de fixar ações em referências imutáveis, como hashes completos de commit, reduz o risco de uma tag mutável apontar para conteúdo alterado. Consulte a atualização e as orientações técnicas do fabricante.

Maturidade não é só cofre de segredos

Um cofre de segredos é útil, mas não resolve sozinho o problema de identidade. Se o pipeline possui uma credencial permanente para abrir o cofre e ler qualquer segredo, a concentração de risco continua. A maturidade aumenta quando a empresa combina processos e controles que reduzam a oportunidade de abuso.

Inventário com responsável e finalidade

Toda identidade de máquina deve ter um proprietário interno, uma finalidade documentada, ambiente autorizado, permissões concedidas, data de expiração quando aplicável e registro de último uso. Sem esse inventário, a rotação tende a ser ampla demais, lenta demais ou incapaz de alcançar credenciais esquecidas.

Privilégio mínimo e segregação de ambientes

As permissões devem ser específicas para cada etapa. Build, testes, publicação e implantação possuem necessidades distintas. Separar produção de ambientes não produtivos impede que uma falha em uma etapa de menor criticidade resulte automaticamente em acesso aos ativos mais relevantes para a operação.

Credenciais temporárias e contexto verificável

Credenciais de curta duração diminuem a janela de uso indevido. Quando associadas a atributos verificáveis — como repositório, branch protegida, ambiente e workflow aprovado — também melhoram a capacidade de bloquear execuções fora do fluxo esperado. Isso substitui parte da dependência de segredos permanentes por confiança contextual.

Telemetria para detectar o uso de credenciais válidas

Uma credencial roubada pode parecer legítima para controles que observam somente usuário e senha. Por isso, segurança de identidades precisa gerar sinais para acompanhamento contínuo: acesso ao cofre fora da janela de implantação, uso de uma conta de serviço em origem incomum, criação inesperada de chaves, elevação de privilégios e tentativas de acesso a recursos que não fazem parte do pipeline.

Essa telemetria pode apoiar monitoramento contínuo e investigação de incidentes, mas o serviço principal permanece a segurança de identidades: é ela que reduz privilégios, encurta a vida das credenciais e mantém a atribuição necessária para diferenciar uma automação legítima de um possível abuso.

Uma decisão prática para proteger a continuidade

O caso do LiteLLM mostra que dependências comprometidas podem transformar um fluxo de desenvolvimento em ponto de coleta de credenciais operacionais. A resposta empresarial não deve se limitar a bloquear um pacote ou atualizar uma ferramenta. Deve incluir a revisão das identidades que concedem poder ao pipeline.

O caminho prático começa pelo inventário das contas de serviço e segredos acessíveis às automações mais críticas. Em seguida, a empresa deve reduzir permissões permanentes, separar ambientes, adotar credenciais temporárias quando tecnicamente viável e acompanhar sinais de uso incompatíveis com o processo autorizado.

Com uma estratégia estruturada de segurança de identidades, a organização ganha capacidade de conter a exposição de uma dependência comprometida antes que ela se converta em acesso persistente a sistemas, dados ou entregas essenciais ao negócio.