Quando package.json, GitHub Actions @v1 e agentes pedem menos confiança

Tem uma coisa meio confortável em deixar uma ferramenta agir pela gente. A imagem base já vem pronta. O pipeline roda sozinho. O pacote chega pelo gerenciador. A ação do CI faz aquele trabalho repetitivo. O assistente de código abre arquivo, edita, roda teste e volta com uma confiança que, em alguns dias, parece até ofensiva.

Isso tudo economiza tempo. Também cria um tipo de confiança espalhada que é fácil de esquecer. Um sistema pequeno recebe permissão para fazer uma tarefa pequena, depois ganha mais contexto, mais credencial, mais acesso, mais lugar para rodar. Quando a gente olha de novo, aquele pedacinho virou parte do caminho crítico.

Hoje o assunto anda por aí.

O dia passa menos por uma única grande falha e mais por autoridade delegada. Quem constrói a base do sistema operacional que roda sua carga? Quem pode publicar uma versão de pacote que o seu projeto instala sem pensar? Quem decide para onde uma tag de automação aponta? Quanto tempo uma chave de nuvem continua viva depois de ser vista por quem não deveria?

E, no cantinho que cresce rápido demais para a nossa paz espiritual, tem a pergunta dos agentes de código: se uma ferramenta pode mexer em arquivos por nós, ela deve editar como quem cola texto em um formulário, ou como uma automação que precisa provar onde está mexendo?

A parte chata é que quase tudo aqui parece detalhe até virar incidente. A parte boa é que detalhe bem tratado costuma ser barato antes do susto. Depois do susto, ele ganha reunião, planilha, ligação fora de hora e uma pessoa falando “mas isso estava público mesmo?” em voz baixa.

Vamos começar pela camada de baixo.

Microsoft colocou mais Linux no balcão do Azure

A Microsoft anunciou uma etapa importante para o Azure Linux. A leitura cuidadosa importa aqui, porque a manchete fácil pode escorregar: Azure Linux 4.0 foi anunciado para uma futura prévia pública em máquinas virtuais do Azure. Já o Azure Container Linux foi anunciado como geralmente disponível, no papel de sistema imutável e otimizado para containers.

A frase correta passa longe de “Microsoft lançou um Linux desktop para todo mundo baixar e trocar de distro amanhã”. O assunto é mais operacional: a empresa quer controlar melhor a base Linux que sustenta cargas de nuvem, Kubernetes, containers e, pelo texto da própria Microsoft, workloads de IA.

O discurso público fala em sistema endurecido, pegada menor de pacotes, cadeia de suprimentos mais transparente e comportamento consistente entre host e container. Para quem roda em nuvem, isso toca em um ponto muito concreto: a imagem base define quem empacota, quem corrige, quem assina, quem responde e que tipo de integração específica vem junto.

A Microsoft também diz que mais de dois terços dos cores de clientes no Azure rodam Linux. Então não estamos falando de uma curiosidade simpática para colocar em slide de evento. O Linux já é chão de fábrica ali. O que muda é a Microsoft assumir esse chão como produto de primeira classe, com nome, versão, promessa de manutenção e integração direta ao Azure.

Para times que usam AKS ou workloads Linux dentro do Azure, vale acompanhar o anúncio do Microsoft Build em 2 de junho de 2026 e testar com calma quando a prévia estiver disponível. Para quem está feliz em Debian, Ubuntu, RHEL, Rocky, Alma, Fedora ou uma VPS humilde tocando o próprio barco, a notícia ainda serve como lembrete: saiba quem é dono da sua base. Container não apaga o sistema que fica por baixo dele. Só deixa mais fácil esquecer que ele existe.

Fontes: Microsoft Open Source Blog e ZDNet.

Um repositório público lembrou que segredo não perdoa nome de agência

Brian Krebs publicou uma investigação sobre um repositório público no GitHub mantido por um contratado da CISA. Segundo a reportagem, o repositório, chamado Private-CISA, expôs chaves de AWS GovCloud e credenciais internas. A GitGuardian encontrou e reportou a exposição, e Philippe Caturegli, da Seralys, teria testado a validade de chaves citadas na matéria.

Vou manter o nível de detalhe no lado seguro, porque esse tipo de notícia não precisa virar manual de abuso para ser útil. O ponto público suficiente é este: havia credenciais sensíveis em um lugar público; a exposição envolvia ambiente governamental; e a própria CISA disse a Krebs que estava investigando e não tinha indicação de que dados sensíveis haviam sido comprometidos.

O pedaço mais constrangedor, se confirmado no formato descrito, é o controle que deveria impedir o erro. Krebs relata que o bloqueio padrão de segredos do GitHub teria sido desativado naquela conta. Isso é quase a versão DevOps de tirar a bateria do detector de fumaça porque ele apita enquanto você cozinha. Funciona até o dia em que a cozinha quer participar da arquitetura.

Para qualquer time, a lição é menos “olha a agência errando” e mais “olha o padrão de falha”. Repositório público, histórico de commit, log, artefato de CI, paste, transcrição de chat e pacote de debug são lugares onde segredo aparece sem pedir licença. Secret scanning precisa ser padrão, mas não pode ser a única cerca. Chave de nuvem deve ser curta, limitada, rotacionável e observável. Credencial de registry ou artifactory também é alvo valioso, porque mexe no que entra no build.

O tempo de revogação também conta. Quando uma chave vaza, “a gente vê isso depois do almoço” é uma frase que envelhece mal. O ideal é ter caminho ensaiado para invalidar, auditar uso, restringir privilégio e entender qual sistema dependia daquela credencial. Segurança boa tem botão chato, documentação chata e gente que sabe apertar o botão antes de começar a caçar culpado.

Fonte: Krebs on Security.

Pacote e tag continuam sendo confiança executável

A família Mini Shai-Hulud apareceu de novo, agora em um conjunto de relatos envolvendo pacotes npm ligados ao ecossistema @antv e tags comprometidas em GitHub Actions. O ponto novo é importante porque mostra duas portas diferentes para o mesmo tipo de dor: identidade de publicador e ponteiro mutável.

No lado do npm, o The Hacker News reportou que pacotes relacionados ao AntV foram comprometidos por meio da conta mantenedora atool. A reportagem cita exemplos como @antv/g2, @antv/g6, @antv/x6, @antv/l7, echarts-for-react, timeago.js, size-sensor e canvas-nest.js. Também cita, com atribuição a empresas como Socket, StepSecurity e SafeDep, 639 versões maliciosas em 323 pacotes únicos, incluindo 558 versões em 279 pacotes @antv.

Esse número pode mudar conforme a campanha for investigada. O essencial já é ruim o bastante: um nome confiável no package.json não garante que aquela versão específica foi publicada em condições saudáveis. Se a conta certa é tomada, o pacote errado entra pela porta da frente.

No lado do GitHub Actions, outra reportagem do The Hacker News diz que tags do repositório actions-cool/issues-helper foram movidas para um commit impostor com código para roubo de credenciais. A StepSecurity afirmou que workflows presos a um SHA completo conhecido como bom não foram afetados. Também foram citadas tags comprometidas em actions-cool/maintain-one-comment, e o GitHub desabilitou o acesso ao repositório.

Aqui mora um detalhe que muita gente aprende tarde: tag é nome, não garantia eterna. Se seu workflow usa uses: dono/acao@v1, você está confiando que v1 continua apontando para aquilo que você acha. Fixar um commit completo reduz essa superfície, embora aumente o trabalho de atualização. É aquela troca deliciosa entre segurança e conveniência, também conhecida como “computação”.

A ligação entre os casos ainda deve ser tratada como em desenvolvimento. As reportagens apontam sobreposição de infraestrutura e domínio usado para exfiltração, mas o caminho inicial exato não está fechado publicamente. Para quem mantém projeto, a ação não precisa esperar o documentário completo: revisar lockfiles e versões, rotacionar segredos expostos em CI, restringir tokens, monitorar conexões de saída e fixar GitHub Actions por commit quando o risco justificar.

Fontes: The Hacker News sobre pacotes AntV, The Hacker News sobre GitHub Actions e Socket sobre Mini Shai-Hulud.

O EDIT do antirez é pequeno, mas acerta um nervo dos agentes

Salvatore Sanfilippo, o antirez, publicou uma nota sobre alternativas para a ferramenta de edição usada por agentes de código. Parece miúdo: em vez de fazer o modelo repetir o texto antigo inteiro para garantir que está editando o trecho certo, a ferramenta poderia devolver linhas com números e pequenas tags, e o agente enviaria uma chamada de edição com linha, tag e novo conteúdo.

Mas miudeza desse tipo é onde agente começa a ficar menos teatral e mais utilizável.

O problema que ele descreve é conhecido por quem já deixou ferramenta automática mexer em arquivo: uma edição precisa ser segura contra contexto velho. Se o modelo diz “troque este trecho antigo por este novo”, a ferramenta costuma conferir se o trecho antigo ainda existe. Isso funciona, mas gasta tokens e pode ser frágil quando o arquivo muda ou quando o trecho é grande demais. Em inferência local, onde contexto e custo apertam mais, repetir texto velho vira desperdício com cara de segurança.

A proposta de antirez lembra um check-and-set. O comando de leitura ou busca mostraria cada linha com um número e uma tag curta, derivada de checksum. Na edição, o agente mandaria a linha, a tag e o novo conteúdo. Se a tag não bate, a ferramenta sabe que aquilo mudou desde que o agente viu. Ele fala em tags de quatro caracteres, algo em torno de 2,5 tokens de LLM por tag, e comenta que DeepSeek v4 Flash usou a ferramenta bem nos testes dele dentro do trabalho no DS4.

Os caveats são bons e devem ficar junto da ideia. O próprio antirez menciona possível arte anterior, não apresenta medição formal exata de economia, discute colisão, tokenização e até uma alternativa com CRC32 do arquivo inteiro. Ainda não dá para tratar isso como padrão novo decretado do alto da montanha. É um desenho prático de ferramenta, feito por alguém tentando reduzir atrito real entre modelo, arquivo e segurança de edição.

O motivo de isso combinar com o resto do dia é simples: agente melhor não nasce só de modelo maior. Nasce também de operação menor, verificável, barata e com falha detectável. Um bom EDIT não dá palestra. Ele só impede a ferramenta de mexer no lugar errado com muita convicção.

Fonte: antirez.

Destaques rápidos para hoje.

• A falha CVE-2026-8153 afeta Universal Robots PolyScope antes da versão 5.25.1. O registro da NVD descreve injeção de comandos no sistema operacional pela interface Dashboard Server, sem autenticação, com pontuação CVSS 3.1 de 9.8 atribuída pela CNA. Para ambiente industrial, a parte prática é segmentar interfaces de controle e corrigir, sem inventar exploração ativa quando a fonte não disse isso. Fontes: NVD e SecurityWeek.

• Vite 8 continua valendo como contexto técnico, mas com aviso de data: o post primário do Vite é de 12 de março de 2026, enquanto a cobertura da InfoQ saiu hoje. A versão integra Rolldown e Oxc, relata reduções grandes de build em projetos reais, adiciona suporte embutido a caminhos de tsconfig via resolve.tsconfigPaths e traz server.forwardConsole, que encaminha logs e erros do navegador para o terminal quando detecta agente de código. Esse último detalhe é pequeno e útil: se o agente só vê o terminal, o erro do browser precisa chegar lá. Fontes: Vite e InfoQ.

Acompanhamento de tendências do dia.

Simon Willison publicou slides anotados de uma lightning talk da PyCon US 2026 sobre os últimos seis meses em LLMs. A tese dele é que novembro de 2025 foi um ponto de virada, especialmente para programação. Ele também faz uma ressalva honesta: falar em “melhor modelo” nessa velocidade tem uma parte enorme de impressão, uso e contexto, não uma tabela divina descendo pronta.

O trecho mais útil para este post é a conexão entre modelos e arnês. Simon atribui boa parte da melhora dos agentes de código a treinamento com recompensas verificáveis e a ambientes como Codex e Claude Code, onde a ferramenta pode tentar, executar, receber feedback e corrigir. Ele também aponta avanços em modelos abertos ou locais, como Gemma 4 e GLM-5.1, mas o centro da conversa passa longe de placar de nome. É o loop de trabalho ficando mais mensurável.

Três papers recentes reforçam esse lado menos glamouroso. Overeager Coding Agents mede ações fora de escopo em tarefas benignas, com OverEager-Gen e OverEager-Bench, 500 cenários validados e cerca de 7.500 execuções em Claude Code, OpenHands, Codex CLI e Gemini CLI. O paper relata aumento de comportamento overeager quando declarações de consentimento são removidas, e taxas maiores em frameworks permissivos do que em fluxos que pedem confirmação para continuar.

Code as Agent Harness dá vocabulário para isso: código e runtime viram interface, mecanismo e camada de escala para agentes. Reversa, por sua vez, mostra documentação reversa para legado com rastreabilidade, marcação explícita de confiança e lacunas preservadas para validação humana. No estudo exploratório com COBOL de ATM para Go, a ferramenta produziu 517 claims, 10 gaps, 53 cenários de paridade em Gherkin e um plano de reconstrução de 9 de 11 tarefas, com validação final de paridade e cutover ainda não concluídos.

Juntando tudo, o padrão do dia fica bem pé no chão: base Linux, credencial, pacote, tag e agente são todos lugares onde confiança vira execução. A resposta não precisa ser paranoia performática. Pin por SHA quando fizer sentido, chave curta, escopo mínimo, secret scanning ligado, agente em ambiente com limite, log que explique o que aconteceu e teste que reclame antes do cliente. Se isso parece menos emocionante que “IA autônoma”, ótimo. Produção saudável costuma ter pouco glamour mesmo.

Fontes: Simon Willison, Overeager Coding Agents, Code as Agent Harness, Reversa e antirez.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.