Tema: supply-chain
-
Vincular a identidade de publicação no npm e no PyPI aos artefatos de lançamento aprovados
A publicação confiável via OIDC elimina tokens de publicação armazenados, mas sua segurança ainda depende do workflow autorizado. Separe build e publicação, proteja as aprovações e verifique a identidade do artefato, sem tratar a proveniência como um veredito sobre a presença de malware.
-
Dependency confusion: quando um pacote público se sobrepõe a um privado
Se uma build resolve nomes de pacotes entre um índice privado e um público, um atacante pode publicar o nome privado no índice público com uma versão mais alta e conseguir que o seu código seja instalado; a documentação do pip considera inseguro usar --extra-index-url para pacotes privados exatamente por isso. As defesas são namespaces associados a um único registro, um índice único com proxy, fixação por hash e reserva de nomes.
-
Subresource Integrity para scripts e folhas de estilo de terceiros
Um atributo integrity em um elemento script ou link contém o hash SHA-256, SHA-384 ou SHA-512 em base64 do arquivo esperado; o navegador se recusa a executar ou aplicar um recurso cujo conteúdo não corresponda. Ele fixa exatamente o que uma CDN pode entregar, exige CORS para arquivos de outra origem e, por isso, só funciona com recursos de conteúdo fixo.
-
Definições de ferramentas MCP como superfície de ataque: descrições envenenadas, shadowing e alterações silenciosas
Os nomes, as descrições e as anotações das ferramentas de um servidor MCP são texto que o modelo lê antes de qualquer chamada. Um servidor malicioso ou comprometido pode usá-los para conduzir o agente, imitar ferramentas de outro servidor ou mudar de comportamento depois da aprovação. Os clientes devem fixar, comparar e revisar as definições como se fossem código.
-
Higiene de dependências e verificações da cadeia de suprimentos de software
Saiba do que você depende, fixe e verifique as versões, acompanhe vulnerabilidades conhecidas e compile a partir de fontes confiáveis; os níveis SLSA, o OpenSSF Scorecard e as instalações com verificação de hash oferecem passos concretos.
-
Nomes de pacotes alucinados ou parecidos: verificar uma dependência antes de o agente instalá-la
Modelos que geram código às vezes citam pacotes que não existem; um atacante pode registrar esse nome, e typosquatters registram variações próximas de pacotes populares. Antes de instalar, o agente deve confirmar que o pacote existe, que é o projeto pretendido e que não foi registrado recentemente com um nome confundível.
-
Incidente do LiteLLM de outubro de 2026: exposição confirmada de token e cuidados com logs do gateway
A análise posterior do LiteLLM substituiu a hipótese inicial de roubo de logs por evidências de exposição de token por uma API da Agent Platform. O incidente ainda ilustra por que credenciais de agentes, corpos de respostas e automação privilegiada precisam de limites de acesso separados.
-
Software Bill of Materials (SBOM) com SPDX e CycloneDX
Um SBOM é um inventário legível por máquina dos componentes de um artefato de software; SPDX e CycloneDX são os dois formatos mais usados, e gerar um SBOM a cada release ajuda a cruzar vulnerabilidades e a revisar licenças.
-
Cadência de atualização de dependências: lotes, agrupamento e o que integrar de uma só vez
Os bots de atualização abrem um pull request por dependência, salvo configuração em contrário; uma cadência sustentável faz merge das correções de segurança assim que chegam, agrupa atualizações patch e minor em lotes agendados e trata versões major como trabalho planejado. Dependabot e Renovate documentam agendamento e agrupamento, e o guia do Renovate aponta o custo do agrupamento: um grupo que falha bloqueia todos os seus membros.
-
Conter a propagação de worms no npm entre máquinas de desenvolvedores e contas de publicação
ChainDrop e o comprometimento do Tensorlake mostram como o roubo de credenciais durante a instalação pode levar à publicação não autorizada de pacotes. A contenção deve abranger a execução de dependências, as permissões de publicação, a persistência em repositórios e os artefatos de build contaminados.
-
Reforçando workflows do GitHub Actions: actions fixadas por SHA, tokens com privilégio mínimo e entradas não confiáveis
Fixe actions de terceiros a um SHA de commit completo, defina o GITHUB_TOKEN como somente leitura por padrão e amplie as permissões por job, nunca interpole campos de eventos não confiáveis em scripts run e trate pull_request_target e workflow_run como gatilhos privilegiados.
-
Períodos de espera para versões de pacotes: configurações exatas, unidades e limites de aplicação
Os controles de idade das versões diferem entre npm, pnpm, uv, Renovate e Dependabot. Configure as unidades corretas, verifique o tratamento dos registros de data e hora e a resolução de dependências transitivas e mantenha um procedimento explícito para atualizações urgentes de segurança.
-
Como construir imagens de contêiner pequenas e reproduzíveis
Fixe as imagens base por digest, instale dependências a partir de lockfiles com verificação de hash, copie apenas o que o runtime precisa, execute como usuário não root, adicione um health check e mantenha segredos fora das camadas e dos argumentos de build.
-
Listas de materiais de software (SBOM): o inventário da sua própria cadeia de suprimentos
Uma lista de materiais de software enumera, em formato legível por máquina, quais componentes e em quais versões estão num artefato entregue. SPDX (ISO/IEC 5962:2021) e CycloneDX (OWASP) são os formatos mais difundidos; a lista é gerada a cada release a partir do artefato compilado, guardada junto dele e usada para cruzar com avisos de vulnerabilidades e obrigações de licença. Com comprovantes de procedência (SLSA), torna a cadeia de suprimentos verificável.
-
Automatização da detecção de fim de vida em SBOMs, imagens de contêineres e inventários de software
Combine inventários de ambientes de execução e imagens com dados de ciclo de vida, preservando a identidade do produto, o provedor de suporte e a atualidade das evidências. Este fluxo proposto usa endoflife.date como fonte de descoberta, confirma prazos com fornecedores e emite alertas separados para suporte expirado e evidências ausentes.
-
Assinar commits e tags com uma chave SSH ou GPG
O Git assina commits e tags com OpenPGP, X.509 ou, desde gpg.format=ssh, uma chave SSH simples; quem assina define gpg.format e user.signingKey, quem verifica precisa de um arquivo de signatários permitidos (SSH) ou de um chaveiro confiável (GPG), e nas plataformas a checagem é feita com git verify-commit ou com o selo de assinatura do host.
-
Atestações de proveniência de build: o que a proveniência SLSA registra e como é verificada
A trilha Build do SLSA classifica o grau de confiança na proveniência de um artefato, de «a proveniência existe» (L1) até uma plataforma de build reforçada (L3). A proveniência é uma atestação in-toto que indica os digests dos artefatos, o builder, o tipo de build e seus parâmetros externos, e o consumidor a confere com uma raiz de confiança e valores esperados antes de usar o artefato.
-
Tags versus digests de imagens de contêiner: nomes mutáveis e endereços de conteúdo
Uma tag é um ponteiro legível que pode ser movido para outro manifest a qualquer momento; um digest é o hash dos bytes do manifest e identifica exatamente uma imagem, para sempre. Faça build e teste por tag, faça deploy e fixe a versão por digest, e registre o digest em cada nota de release.
-
Criação e manutenção de um inventário criptográfico para a migração pós-quântica
Registre onde a criptografia protege dados, quem responde por cada dependência e quais evidências sustentam o registro. Use uma CBOM CycloneDX para intercambiar ativos técnicos sem confundi-la com um plano completo de migração.
-
Quais verificações em pull requests de atualização automática de dependências já detectaram uma versão maliciosa ou defeituosa, e quais só geram ruído?
Pergunta em aberto: pull requests de atualização automática chegam todos os dias e muitas vezes são mesclados quando o CI fica verde; a documentação do npm descreve atestados de proveniência verificáveis com npm audit signatures, mas quais verificações (proveniência, revisão do diff do pacote descompactado, inspeção de scripts de instalação, períodos de espera, diffs do lockfile) têm histórico de detectar uma versão comprometida ou defeituosa?
Legível por máquina: JSON