Drydock revisa artefatos npm e PyPI antes da publicação

Revisão antes da publicação

O Drydock se apresenta como uma camada de segurança para revisar o artefato de um pacote antes que ele chegue ao registro público. A proposta é comparar o candidato exato - incluindo scripts de build, saída de bundler e arquivos que podem não existir no Git - com a última versão publicada. O diff é determinístico e cada achado de cadeia de suprimentos é ancorado a uma linha alterada. Entre os sinais de risco estão scripts de instalação, execução de processos, acesso à rede, leitura de credenciais e novos binários. O conteúdo do pacote nunca é executado.

O relatório mostra severidade, findings e árvore de release. Em um exemplo, um pacote @acme/cli passa de 4.2.0 para 4.3.0 com 17 arquivos, 4 alterados e 3 findings: 2 críticos e 1 médio. A adição de postinstall no package.json é marcada como crítica porque passa a executar lib/install.js durante npm install. A revisão leva a uma decisão humana.

Dois modos

Stage Watchtower é consultivo. O mantenedor roda npm stage publish, o registro deixa um candidato privado e o Drydock revisa o tarball, fixando sinais de risco no diff. A aprovação ou rejeição é feita de forma independente no npm com 2FA. O Drydock não consegue impedir uma publicação manual separada.

Workflow Gate é obrigatório. Para PyPI, extensões do VS Code ou fluxos npm que não usam staging, um GitHub Environment pausa o job de publicação depois que a CI envia o artefato. O Drydock revisa o upload; o mantenedor aprova ou rejeita; se aprovado, o job segue com a própria credencial. A ferramenta nunca publica nem guarda a credencial de publicação. Tokens com escopo apenas buscam evidências de release; relatórios mantêm evidências redigidas em vez de arquivos brutos.

Integração com dependências

O Drydock pode colocar um diff de artefato em cada PR de dependência. Renovate e Dependabot já sabem as versões alteradas; o Drydock transforma o par em um diff público e determinístico, sem conta ou token. Há um preset do Renovate para adicionar uma coluna Drydock às tabelas de atualização npm e PyPI. Para Dependabot, um workflow verifica o commit assinado e insere um comentário com link de diff para atualizações únicas ou agrupadas, sem fazer checkout do código do PR.

Por que revisar o publish

A justificativa é que ataques relevantes chegam no artefato publicado, não no pull request. A revisão de PR examina a árvore de código; o registro entrega algo diferente: um artefato construído que pode carregar hooks de instalação, bundles minificados e arquivos que nunca estiveram no Git, publicado com uma credencial que pode não ser de quem se imagina. Depois que uma versão entra no ar, ela é imutável e instalada em minutos.

São citados casos: event-stream, em 2018, com direitos de publicação transferidos e um drenador de carteira voltado ao Copay que só existia no tarball npm; ua-parser-js, em 2021, com conta npm sequestrada e três versões maliciosas com criptominerador e ladrão de credenciais; node-ipc, em 2022, com uma publicação legítima do próprio mantenedor que sobrescrevia arquivos conforme o IP do instalador; e chalk & debug, em 2025, com um mantenedor vítima de phishing e 18 pacotes comprometidos, somando cerca de dois bilhões de downloads semanais, com versões que roubavam cripto no ar por horas antes de alguém comparar. Nenhum caso apareceu no PR. Todos passaram por uma publicação que ninguém revisou.

Conclusão

O Drydock posiciona a última checagem útil entre o artefato pronto e o registro. A decisão permanece humana: 2FA no npm para stage publish ou gate de CI para releases de workflow. Segundo a página, cada caminho de release configurado passa a ter um segundo par de olhos antes da publicação e a configuração leva minutos.