Dependency Firewall: bloqueie pacotes arriscados antes do build

Pacotes maliciosos podem aparecer disfarçados como pacotes confiáveis. Por exemplo, em junho de 2026, pesquisadores do GitLab encontraram cinco pacotes maliciosos no PyPI, quatro deles typosquats do Flask, Requests e NumPy, que são executados no momento da instalação e roubam credenciais de CI/CD. E isso importa, já que agentes de IA agora adicionam dependências de código aberto por conta própria, muitas vezes sem revisão, e os desenvolvedores perdem a visibilidade sobre quais pacotes podem contaminar o build.

Essa combinação abre uma brecha real: um pacote malicioso ou vulnerável pode entrar no seu build sem qualquer autorização. Uma vez lá dentro, o código desse pacote roda com o mesmo acesso que o seu pipeline tem, e a partir daí consegue alcançar qualquer sistema que os seus pipelines de desenvolvimento tocam.

O GitLab Dependency Firewall, apresentado hoje no Transcend em acesso antecipado, bloqueia pacotes que batem com a sua política — maliciosos, vulneráveis ou fora de conformidade — antes que eles cheguem ao seu build. Com a governança embutida, a ferramenta impede o risco antes mesmo da instalação, o que libera a sua equipe do processo de rastrear, remover ou refazer o que uma política bloqueia. Desenvolvedores e seus agentes continuam puxando as dependências de que precisam sem esperar por uma revisão manual de segurança, e os pacotes que atendem à sua política passam a fazer parte do seu build oficial.

Assista à gravação do nosso evento Transcend para ver demonstrações dos novos recursos da plataforma e entender o que é preciso para levar a velocidade da IA agêntica a todo o ciclo de vida do software.

Bloqueie pacotes maliciosos sem quebrar o seu build

Sem uma política no momento da instalação, um pacote problemático entra no build primeiro e só é pego depois. A análise de composição de software (Software composition analysis - SCA) verifica o que você já trouxe para o projeto — então, quando ela sinaliza um pacote malicioso, uma vulnerabilidade de alta gravidade ou uma licença que o seu time jurídico não aceita, a dependência já está instalada e pode até já ter sido entregue dentro de um artefato. Rastrear até onde ela foi, removê-la e reconstruir o build transforma uma execução de rotina do pipeline em um trabalho extra e não planejado para o seu time de engenharia.

Com o Dependency Firewall, você decide o que pode entrar nos seus builds antes mesmo da instalação, definindo políticas para:

1. Status malicioso — pacotes sinalizados no banco de dados de avisos de malware do GitLab
2. Gravidade da vulnerabilidade — a gravidade que você define (crítica, alta, média ou baixa) e quantas ocorrências você permite nesse nível, incluindo zero
3. Tipo de licença — quais licenças você permite ou recusa, listadas pelo nome completo, e como tratar pacotes cuja licença não pode ser identificada
4. Idade do pacote — a idade mínima que um pacote precisa ter antes de entrar em um build, para que uma versão publicada minutos atrás não entre direto sem que ninguém a tenha analisado

Colocar essa política em prática não precisa colocar a sua entrega em risco. Comece no modo de aviso: o firewall registra o que uma política capturaria, mas deixa o build seguir normalmente. Ele grava um evento de auditoria, uma entrada no dashboard e uma linha no resumo do CI, para que você possa avaliar se vale a pena bloquear o build ou não.

Depois que você confiar nas políticas, mude para o modo de bloqueio: o pipeline para assim que encontra uma correspondência e mostra o motivo. Quando alguém realmente precisa liberar um pacote já aprovado, um bypass registrado permite que um usuário ou token autorizado prossiga — tudo fica no histórico.

Aplicação de políticas de segurança

Defina a política uma vez ou personalize por time

Um firewall que só atua no nível do registro dá a mesma política para todo mundo, mas isso raramente combina com a forma como os times realmente trabalham. Um serviço de pagamentos e um protótipo interno carregam perfis de risco bem diferentes, e um único conjunto de regras para todo o registro não consegue exigir mais de um do que do outro.

Com o Dependency Firewall, você define uma política no grupo de nível superior, e todo projeto abaixo dele herda as mesmas regras. Quando um time precisa de algo diferente, você pode definir uma política específica para aquele grupo ou projeto.

Dá para aplicar a regra no nível do registro e governar toda a organização a partir de uma única plataforma, sem abrir mão da possibilidade de apertar as regras onde o risco é maior. As regras vivem como código em um projeto de política de segurança, então são revisadas e alteradas por meio de uma solicitação de merge, como o resto da sua configuração. Elas são herdadas do grupo de nível superior até serem passadas para cada projeto, e, quando as regras se sobrepõem, vale a mais restritiva. Um serviço crítico pode ficar acima da régua-base da organização, e nenhum projeto fica abaixo dela.

Nova política do dependency firewall

Verifique um pacote antes de trazê-lo para o projeto

Um desenvolvedor — ou um agente realizando o trabalho — geralmente só descobre que um pacote não é permitido quando o pipeline falha. Isso custa um ciclo inteiro de build e quebra a concentração bem na hora em que o trabalho está fluindo.

Com o GitLab Dependency Firewall, você já sabe a resposta antes de adicionar uma dependência, direto no lugar onde já está trabalhando — e consegue escolher um pacote que passa de primeira.

Usando a GitLab CLI no terminal ou em um script, uma verificação por linha de comando já diz se um pacote vai passar ou ser bloqueado pela sua política, sem que o desenvolvedor precise abrir um console separado. Ela cobre gerenciadores de pacotes comuns, como npm, pip, Poetry, Maven, Gradle e Bundler, com mais integrações a caminho.

Use a linha de comando para identificar se um pacote vai passar ou ser bloqueado pela sua política

Veja e comprove cada decisão

Um líder de segurança precisa conseguir provar o que um controle está fazendo durante uma auditoria. Um controle que bloqueia silenciosamente, sem deixar registro, não responde à pergunta do auditor e não constrói confiança com os times que ele governa.

Você tem uma visão única de tudo o que o firewall já permitiu, avisou e bloqueou, com um registro imutável de cada decisão que pode ser entregue a um auditor.

O dashboard do Dependency Firewall mostra a atividade e os resultados de todos os projetos dentro do escopo definido. Cada aviso, bloqueio ou bypass gera um evento de auditoria que registra a regra correspondente, a política por trás dela e o pacote envolvido.

Dashboard do Dependency Firewall

Tenha acesso antecipado ao GitLab Dependency Firewall

Agora você pode travar pacotes maliciosos, vulneráveis ou fora de conformidade antes que cheguem a um build. A solução é compatível com o GitLab Artifact Central e com registros externos do Sonatype Nexus Repository e do JFrog Artifactory, e não exige manter uma ferramenta separada ao lado da sua implantação do GitLab. O Dependency Firewall já está em acesso antecipado para clientes GitLab.com e GitLab Self-Managed nos planos Premium ou Ultimate. Solicite seu acesso antecipado agora mesmo!