Blog

O desafio de escalar segurança com agentes de IA

Agentes de IA para programação — como o Kiro e o Claude Code — já fazem parte do dia a dia de muitos times de desenvolvimento. Com um simples prompt em linguagem natural, eles geram funcionalidades, escrevem testes e refatoram código. Em uma tarde, um único agente pode abrir dezenas de pull requests em diferentes repositórios.

Essa produtividade tem um custo: os agentes otimizam para completar tarefas na velocidade de uma máquina, sem qualquer compreensão do perfil de risco da organização. Além disso, por meio de protocolos como o Protocolo de Contexto de Modelo (MCP), eles ultrapassam os limites da IDE — chamando APIs, consultando bancos de dados e modificando infraestrutura inteira.

Para endereçar esse cenário, a AWS publicou um framework de controle de segurança de aplicações (AppSec) voltado especificamente para agentes de IA em desenvolvimento de software. O framework se organiza em dois pilares: controles no momento de autoria, que moldam o que o agente produz dentro da IDE, e controles no momento do build, que verificam e bloqueiam o que chega à produção. Os controles existentes do Ciclo de Vida de Desenvolvimento de Software Seguro (SDLC) continuam válidos e são peça central de uma estratégia de defesa em profundidade.

Os principais riscos identificados

O framework identifica sete categorias de risco, ordenadas por severidade:

• R001 — Injeção de prompt e de contexto: agentes leem conteúdo não confiável (descrições de issues, páginas web, respostas MCP, arquivos README de pacotes de terceiros). Esse conteúdo pode redirecionar o agente para divulgar segredos ou invocar ferramentas sem consentimento. É o risco número um do OWASP Top 10 para Aplicações com Modelos de Linguagem (LLM). O tratamento recomendado é separar o agente que orquestra ações confiáveis daquele exposto a conteúdo não confiável, aplicando acesso mínimo de somente leitura ao segundo, e exigindo aprovação humana para ações irreversíveis.
• R002 — Divulgação inadvertida de dados e configurações permissivas: agentes tendem a gerar políticas com permissões amplas demais, grupos de segurança abertos, armazenamento sem criptografia ou credenciais embutidas no código. O tratamento envolve documentos de steering com requisitos de segurança e varredura de política como código (Checkov, cfn-nag) na IDE e no pipeline.
• R003 — Mudanças não controladas chegando à produção: a geração em velocidade de máquina pode propagar um padrão falho por vários repositórios antes de ser identificado. O tratamento inclui regras de proteção de branch, revisão humana obrigatória em pull requests e execuções de agente em sandbox.
• R004 — Riscos na cadeia de suprimentos: agentes podem recomendar pacotes depreciados, referenciar versões com Vulnerabilidades e Exposições Comuns (CVEs) conhecidas ou até “alucinar” nomes de pacotes inexistentes. O tratamento é Análise de Composição de Software (SCA) no pipeline — por exemplo, com o Amazon Inspector ou Dependabot — e resolução de dependências via um registro controlado como o AWS CodeArtifact.
• R005 — Acesso externo não controlado: sem restrições sobre quais ferramentas e dados o agente pode acessar via MCP, uma única integração mal configurada abre caminho para recursos sensíveis. O tratamento é escopar os servidores MCP ao mínimo necessário e auditar as invocações de ferramentas.
• R006 — Alucinações e código incorreto: código que compila, passa no linting e parece razoável ainda pode estar funcionalmente errado — misusando APIs, introduzindo erros lógicos sutis ou implementando operações sensíveis de segurança de forma incorreta. O tratamento é combinar verificação determinística (Teste de Segurança de Aplicações Estático — SAST, testes unitários) com revisão não determinística (LLM como revisor).
• R007 — Expansão de escopo: dado um prompt de correção de bug, o agente pode também refatorar código ao redor, desabilitar um teste instável ou reorganizar imports. O tratamento é um documento de especificação que define o que deve mudar e o que não deve.

Controles determinísticos versus não determinísticos

O framework diferencia dois tipos de mitigação:

• Mitigações determinísticas [D] produzem o mesmo resultado toda vez. Linters, scanners SAST, detecção de segredos e política como código definem invariantes de segurança — sem credenciais hardcoded, sem políticas IAM com wildcard. Use quando a condição pode ser expressa como uma regra.
• Mitigações não determinísticas [ND] usam o julgamento do modelo. Incluem documentos de steering, revisão por LLM e verificação de conformidade com especificações. Capturam problemas que as regras deixam passar, mas são probabilísticas. São a nova camada que o código gerado por IA exige — porque um agente pode produzir código que passa em todos os testes determinísticos e ainda assim estar funcionalmente errado.
• Revisão humana [H] é a camada final para decisões que nenhum dos dois tipos de ferramenta consegue tomar. O ponto importante é: aplique onde o julgamento é realmente necessário, não em tudo. Rotear tudo para um humano gera fadiga de consentimento, onde revisores aprovam por reflexo e o controle perde valor.

Pilar 1: Controles no momento de autoria

Os controles de autoria atuam dentro da IDE, antes e logo após a geração do código.

Contexto como controle de segurança [ND]

Times de segurança escrevem invariantes de segurança como orientações em linguagem natural em um documento de steering — por exemplo: políticas IAM devem seguir o princípio do menor privilégio; credenciais devem vir do AWS Secrets Manager; grupos de segurança não podem permitir acesso irrestrito. Esse arquivo é carregado no contexto do agente no início de cada sessão, fazendo com que ele gere código com esses padrões por padrão. O steering reduz o volume de problemas que chegam ao pipeline, mas não substitui as verificações posteriores.

Especificações como limites de escopo [ND]

Antes de gerar código, exige-se uma especificação revisada que define o que deve mudar e o que não deve. Fluxos orientados por especificação criam um ponto de revisão humana na fase de design. Para correções de bug, a especificação inclui uma lista explícita de comportamentos que devem continuar funcionando — um limite escrito contra a expansão de escopo.

Acesso controlado a ferramentas via MCP [D + ND]

Servidores MCP atuam como gateways controlados entre o agente e ferramentas externas. O framework recomenda escopar cada servidor MCP ao conjunto mínimo de ferramentas necessárias e fornecer uma credencial dedicada com permissões reduzidas — não as credenciais do próprio desenvolvedor. Evite autoApprove: ["*"], que remove a aprovação humana em todas as chamadas de ferramentas. Consulte a documentação de configuração de MCP do Kiro para detalhes de implementação.

Varredura de código na IDE [D]

Análise estática em tempo real captura erros de sintaxe, incompatibilidades de tipo e problemas de configuração enquanto o desenvolvedor ainda tem contexto completo. Extensões focadas em segurança (plugins ESLint de segurança, Checkov, SAST) adicionam feedback imediato — uma política IAM malformada é sinalizada antes que o agente continue construindo sobre ela.

Hooks: guardrails automáticos no ponto de ação [D + ND]

Hooks de shell são disparados ao salvar arquivos e executam verificações determinísticas (linters, formatadores, scanners de segurança). Hooks baseados em IA são disparados ao completar tarefas e verificam se a implementação corresponde à especificação, se há casos extremos não testados e se arquivos foram modificados fora do escopo da tarefa.

Pilar 2: Controles no momento do build

Os controles de build rodam no pipeline após o commit do código e antes de chegar à produção.

Varredura de segurança em camadas [D]

A sequência recomendada é: detecção de segredos primeiro (mais barata, alta severidade), depois SAST, depois SCA e por fim varredura de Infraestrutura como Código (IaC). A varredura de IaC valida templates do AWS CloudFormation, Terraform e AWS CDK contra políticas de segurança antes do deploy. Cada etapa interrompe o pipeline em caso de falha. Os resultados são exportados no formato Formato de Intercâmbio de Resultados de Análise Estática (SARIF) para auditoria de conformidade. O projeto open source Automated Security Helper (ASH) agrupa scanners de segredos, SAST, SCA e IaC em um único comando executável localmente e no AWS CodeBuild.

Quality gates [D]

Gates de qualidade convertem resultados de varredura em decisões de prosseguir ou não. Defina limites por severidade: bloquear em achados críticos, exigir justificativa para altos, rastrear médios. A regra é determinística: se um limite é violado, o pipeline para. Diferencie modos bloqueante e consultivo — falhas duras na branch principal, consultivas em branches de feature.

Revisão assistida por IA [ND]

Um revisor LLM faz a triagem de cada pull request antes da revisão humana, verificando conformidade com a especificação, expansão de escopo e padrões de segurança que passam no SAST mas violam a intenção. O AWS Security Agent (revisão de código em preview no momento da publicação) verifica pull requests contra requisitos de segurança gerenciados pela AWS e personalizados. Um princípio crítico: o agente que escreveu o código não deve ser o mesmo que o revisa. Onde possível, use um modelo diferente para revisão — dois modelos iguais podem compartilhar os mesmos pontos cegos sistemáticos.

Revisão humana no loop [ND + H]

Exija aprovação humana na maioria dos pull requests, especialmente os que tocam código sensível a segurança ou de alto impacto. Escale a profundidade da revisão ao risco da mudança: mudanças de baixo risco podem ter revisão mais leve; mudanças de lógica nova ou sensível exigem revisão profunda e um segundo revisor. Posicione dois gates de aprovação: após as varreduras de segurança e antes do deploy em produção. Trate a revisão humana como controle secundário — revisores são não determinísticos e também podem deixar passar problemas.

Implementando na AWS

O framework é agnóstico de ferramenta, mas a AWS fornece blocos de construção diretos para cada pilar:

• Kiro para controles de autoria: documentos de steering em .kiro/steering/, fluxos orientados por especificação, hooks de agente e integrações MCP. Todos os guardrails ficam versionados no repositório em .kiro/, compartilhados por todo o time. Para ambientes corporativos, o Kiro suporta AWS IAM Identity Center para login único. Verifique a disponibilidade atual por Região.
• AWS CodeBuild e AWS CodePipeline para controles de build: cada ferramenta de varredura roda como uma ação de build; código de saída diferente de zero falha a ação; achados são exportados como SARIF para o Amazon S3; ações de aprovação manual interrompem o pipeline, enviam notificações via Amazon SNS e registram decisões e identidade do revisor para auditoria.

Por onde começar

A AWS sugere três passos iniciais:

• Comece com steering e especificações — encode requisitos de segurança como steering e use especificações para novas funcionalidades. Maior impacto, menor esforço. O projeto open source Project CodeGuard (iniciativa da Coalition for Secure AI sob a OASIS Open, da qual a Amazon é membro contribuinte) publica regras de steering reutilizáveis para classes de risco comuns — credenciais hardcoded, misconfigurações de IaC, cadeia de suprimentos e segurança MCP.
• Adicione gates determinísticos no pipeline — integre SAST, SCA e detecção de segredos. São controles básicos independentemente do uso de IA.
• Calibre e itere — revise o que os controles estão capturando, ajuste o steering para problemas recorrentes e expanda a autonomia do agente conforme a confiança cresce.

Um ponto central do framework: desenvolvedores continuam responsáveis pela segurança do que entregam. Agentes de IA aceleram o desenvolvimento; eles não transferem a responsabilidade.

Recursos adicionais

• Documentação do Kiro
• Guia do usuário do AWS CodePipeline
• AWS Agentic AI Security Scoping Matrix

Fonte

Balancing speed and safety: A control framework for AI coding agents (https://aws.amazon.com/blogs/security/balancing-speed-and-safety-a-control-framework-for-ai-coding-agents/)

O que é o Amazon Inspector SBOM Generator?

O Amazon Inspector é um serviço de gerenciamento de vulnerabilidades que escaneia continuamente workloads da Amazon Web Services (AWS) em busca de falhas de segurança em software. O motor por trás dessa capacidade é o Amazon Inspector SBOM Generator — conhecido como inspector-sbomgen — uma ferramenta de linha de comando independente que gera uma Lista de Materiais de Software (SBOM — Software Bill of Materials) a partir de imagens de contêiner, diretórios, arquivos compactados, sistemas locais, binários compilados e muito mais.

Ao longo dos últimos dois anos, a AWS expandiu a cobertura do inspector-sbomgen para dezenas de ecossistemas de linguagens de programação, sistemas operacionais e aplicações amplamente utilizadas. Agora, a empresa anuncia uma novidade relevante para quem constrói com essa ferramenta: um sistema de plugins para criação de coletores de pacotes personalizados.

Por que a AWS construiu um sistema de plugins?

Ecossistemas de software são dinâmicos por natureza. Novos gerenciadores de pacotes, formatos de lockfile e aplicações surgem constantemente — muitas vezes com pouco escrutínio de segurança. Isso deixa equipes de segurança com uma lacuna de visibilidade: workloads em produção rodando software que as ferramentas de SBOM ainda não reconhecem.

Antes dos plugins, o único caminho para suportar um novo ecossistema era abrir uma solicitação de funcionalidade e aguardar que a equipe do inspector-sbomgen integrasse o ecossistema e publicasse uma nova versão. O sistema de plugins muda esse cenário completamente.

Com plugins, é possível:

• Integrar ecossistemas não suportados nativamente: novos ecossistemas open source, formatos de pacote de nicho e ferramentas internas ou proprietárias podem ser inventariados sem modificar o inspector-sbomgen.
• Prototipar detecção rapidamente: o sistema foi projetado para ser amigável tanto para desenvolvedores quanto para assistentes de codificação com IA. Os plugins são escritos em Lua, carregados em tempo de execução e não exigem toolchain Go nem compilação.
• Construir sobre uma base estável: a API de plugins abstrai as diferenças entre tipos de artefatos, então a lógica de detecção é escrita uma única vez e funciona em imagens de contêiner, arquivos compactados, sistemas locais e mais.

Internamente, a AWS já utilizou o sistema de plugins para acelerar a entrega de novos ecossistemas. Na versão 1.13, mais de 20 ecossistemas que antes eram implementados em Go — incluindo Apache Tomcat, NGINX, MySQL, Redis, WordPress e a toolchain do OpenSSH — foram convertidos para plugins embutidos no binário. A mesma versão também adicionou mais de dez ecossistemas totalmente novos como plugins, incluindo Apache Cassandra, Apache Struts, Conda, pacotes Swift e coletores de agentes de IA (Amazon Q Developer, Kiro CLI, Claude Code, GitHub Copilot e Ollama).

Como os plugins do inspector-sbomgen funcionam

Os plugins seguem um pipeline de duas etapas:

• Descoberta (Discovery): varre o sistema de arquivos do artefato para identificar arquivos que contêm metadados de pacotes instalados.
• Coleta (Collection): abre cada arquivo descoberto, analisa seu conteúdo e publica os resultados no SBOM.

Por baixo dos panos, um barramento de eventos conecta os plugins de descoberta e coleta. Os plugins de descoberta publicam eventos listando os arquivos encontrados, e um ou mais plugins de coleta se inscrevem nesses eventos para disparar a coleta de pacotes. Desenvolvedores familiarizados com padrões de design vão reconhecer esse comportamento como o padrão observer.

Esse desacoplamento permite que um único plugin de descoberta alimente múltiplos coletores — por exemplo, um extraindo metadados de pacotes, outro buscando segredos e outro verificando políticas — tudo a partir da mesma lista de arquivos, sem precisar percorrer o sistema de arquivos do artefato novamente.

Criando seu primeiro plugin em 5 minutos

O inspector-sbomgen facilita a criação de um ambiente de plugin. O comando plugin new cria um novo workspace de plugin, e a flag --with-example popula o workspace com um par de plugins de descoberta e coleta prontos para execução imediata.

inspector-sbomgen plugin new --with-example

Após invocar o comando, será solicitado um nome para o plugin e um diretório para o workspace. É possível fornecer valores personalizados ou usar os valores padrão:

Plugin name (identifies the software ecosystem your plugin will inventory, e.g. debian-dpkg, rhel-rpm, python-pip, cmake) [my-custom-ecosystem]: <enter>
Project directory [my-sbomgen-plugins]: <enter>
Created plugin "my-custom-ecosystem" in my-sbomgen-plugins/

Também é possível pular os prompts interativos especificando o nome do plugin e o diretório diretamente via argumentos de Interface de Linha de Comando (CLI — Command Line Interface):

inspector-sbomgen plugin new \
  --with-example \
  --name my-custom-ecosystem \
  --path my-sbomgen-plugins

Após criar o workspace, o inspector-sbomgen exibe uma tela de próximos passos que guia desenvolvedores e assistentes de IA aos arquivos que precisam ser modificados e à documentação de suporte:

Next steps:

  Get started:
    1. Open plugin folder in a code editor (VS Code recommended)
    2. Add test files that your plugin will discover and parse (e.g., config files, lockfiles, binaries, etc.):
       my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata/

  Develop:
    3. Edit discovery:   my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua
    4. Edit collection:  my-sbomgen-plugins/collection/cross-platform/extra-ecosystems/my-custom-ecosystem/init.lua

  Test:
    5. Write unit tests: my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/init_test.lua
    6. Run unit tests:   inspector-sbomgen plugin test --path my-sbomgen-plugins

  Deploy:
    7. Distribute your plugin directory wherever you run inspector-sbomgen:
       inspector-sbomgen <arguments> --plugin-dir /path/to/my-sbomgen-plugins
       Example:
       inspector-sbomgen container --image alpine:latest -o /tmp/sbom.json --plugin-dir /path/to/my-sbomgen-plugins

For code completion, install the VS Code Lua language server extension:
  https://luals.github.io/#vscode-install

For more information:
  - Plugin guide:    my-sbomgen-plugins/docs/sbomgen-plugin-developer-guide.md
  - Testing guide:   my-sbomgen-plugins/docs/sbomgen-plugin-testing-guide.md
  - API reference:   my-sbomgen-plugins/docs/sbomgen-plugin-api-reference.md
  - Documentation:   https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html

A estrutura do workspace gerado é a seguinte:

tree my-sbomgen-plugins
├── AGENTS.md
├── collection
│   └── cross-platform
│       └── extra-ecosystems
│           └── my-custom-ecosystem
│               └── init.lua
├── discovery
│   └── cross-platform
│       └── extra-ecosystems
│           └── my-custom-ecosystem
│               ├── _testdata
│               │   ├── empty
│               │   └── example.lock
│               ├── init_test.lua
│               └── init.lua
├── docs
│   ├── sbomgen-plugin-api-reference.md
│   ├── sbomgen-plugin-developer-guide.md
│   └── sbomgen-plugin-testing-guide.md
├── library
│   └── sbomgen.lua
└── README.md

O projeto gerado inclui um par funcional de plugins de descoberta e coleta, testes unitários com fixtures em _testdata/, integração com o Ambiente de Desenvolvimento Integrado (IDE — Integrated Development Environment) e uma cópia local da documentação do desenvolvedor. O scaffolding é deliberadamente conciso e completo, com comentários claros em cada arquivo explicando o que cada função faz.

Exemplo de plugin de descoberta

O plugin de exemplo inventaria um arquivo fictício example.lock com o seguinte conteúdo:

my-package-alpha==1.0.0
my-package-beta==2.3.1
my-package-gamma==0.9.5

O plugin de descoberta sabe como localizar instâncias de example.lock no sistema de arquivos do artefato:

-- my-custom-ecosystem discovery plugin
-- Discovers example.lock files in the artifact file list.
function discover()
    return sbomgen.find_files_by_name({"example.lock"})
end

Exemplo de plugin de coleta

O plugin de coleta sabe como analisar o conteúdo de example.lock e publicar os pacotes encontrados no SBOM de saída:

-- my-custom-ecosystem collection plugin
-- Parses example.lock files and extracts package name and version.
function collect(file_path)
    local content = sbomgen.read_file(file_path)
    if content == nil then
        return
    end
    for line in content:gmatch("[^\n]+") do
        local name, ver = line:match("^(.+)==(.+)$")
        if name and ver then
            sbomgen.push_package({
                name           = name,
                version        = ver,
                purl_type      = "generic",
                namespace      = "my-custom-ecosystem",
                component_type = sbomgen.component_types.APPLICATION,
            })
        end
    end
end

Executando os testes

Os plugins incluem um framework de testes integrado para validar a lógica antes de escanear um artefato real. Os testes são escritos em Lua, ficam ao lado do plugin em init_test.lua e referenciam dados de fixture em _testdata/:

function test_discovers_packages()
    local result = testing.scan_directory("_testdata")
    testing.assert_equals(3, #result.findings)
    testing.assert_equals("my-package-alpha", result.findings[1].name)
    testing.assert_equals("1.0.0", result.findings[1].version)
end

function test_no_findings_for_empty_directory()
    local result = testing.scan_directory("_testdata/empty")
    testing.assert_equals(0, #result.findings)
end

Execute os testes com o seguinte comando:

inspector-sbomgen plugin test --path my-sbomgen-plugins -v

=== RUN   my-custom-ecosystem/discovery/init_test/test_discovers_packages
--- PASS: my-custom-ecosystem/discovery/init_test/test_discovers_packages (0.04s)
=== RUN   my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory
--- PASS: my-custom-ecosystem/discovery/init_test/test_no_findings_for_empty_directory (0.04s)
ok  2 tests passed

Esse é o ciclo de desenvolvimento mais ágil possível: sem toolchain Go, sem recompilação, sem inicialização de contêiner. Escreva o teste, execute, itere.

Escaneando um artefato real

Para que os plugins produzam resultados, o inspector-sbomgen precisa de um artefato que contenha os arquivos que o plugin procura. Para o plugin de exemplo, qualquer diretório com um arquivo example.lock funciona:

inspector-sbomgen directory \
  --plugin-dir ./my-sbomgen-plugins \
  --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \
  -o sbom.json

A flag --plugin-dir indica ao inspector-sbomgen onde carregar os plugins Lua. O SBOM resultante contém um componente CycloneDX para cada um dos três pacotes do example.lock, por exemplo:

{
  "bom-ref": "comp-2",
  "type": "application",
  "name": "my-package-alpha",
  "version": "1.0.0",
  "scope": "optional",
  "purl": "pkg:generic/my-sbomgen-plugin/my-package-alpha@1.0.0",
  "properties": [
    {
      "name": "amazon:inspector:sbom_generator:source_path",
      "value": "./my-sbomgen-plugins/example.lock"
    }
  ]
}

Todo componente gerado por plugin carrega uma propriedade amazon:inspector:sbom_generator:source_path que registra o arquivo de origem, permitindo rastrear cada componente até o artefato que o produziu.

Escaneamento de vulnerabilidades com o Amazon Inspector

Os resultados gerados por plugins são componentes SBOM de primeira classe e funcionam com qualquer consumidor downstream que leia SBOMs CycloneDX, incluindo o próprio Amazon Inspector. Para enviar um SBOM ao Amazon Inspector para análise de vulnerabilidades, basta adicionar a flag --scan-sbom (requer uma conta AWS ativa):

inspector-sbomgen directory \
  --path ./my-sbomgen-plugins/discovery/cross-platform/extra-ecosystems/my-custom-ecosystem/_testdata \
  --plugin-dir ./my-sbomgen-plugins \
  --scan-sbom \
  --aws-profile your_profile \
  --aws-region your_region \
  -o /tmp/sbom.json

Um ponto importante: plugins podem inventariar ecossistemas arbitrários, mas o Amazon Inspector só consegue reportar vulnerabilidades para componentes cujos ecossistemas já estão em seus feeds de avisos. Quando um componente de ecossistema ainda não suportado é enviado, o Inspector retorna o componente com a propriedade Component skipped: no supported rules found. — comportamento esperado, não um erro. O SBOM ainda é gerado corretamente e o componente continua sendo rastreado. Quando o Inspector adicionar cobertura para aquele ecossistema, o mesmo SBOM passará a produzir resultados de vulnerabilidades automaticamente, sem nenhuma alteração no plugin.

Suporte a IDE de primeira classe

Todo projeto de plugin gerado com o comando plugin new inclui um arquivo library/sbomgen.lua e um .vscode/settings.json que se integra automaticamente à extensão sumneko.lua do Servidor de Linguagem Lua para o VS Code. Com isso, cada função sbomgen.* passa a ter:

• Dicas de parâmetros com tipos.
• Documentação ao passar o cursor.
• Autocompletar para constantes (sbomgen.component_types.*, sbomgen.groups.*, sbomgen.platform.*).
• Verificação de tipos nas chamadas de função.
• Avisos inline quando campos obrigatórios estão ausentes em push_package().

O mesmo arquivo de definição torna o desenvolvimento de plugins eficiente com assistentes de codificação por IA, pois os tipos e a documentação estão embutidos em um formato que essas ferramentas conseguem ler.

Modelo de segurança dos plugins

Como os plugins executam código real dentro do mesmo processo do inspector-sbomgen, o ambiente de execução foi projetado para manter esse código estável e endurecido do ponto de vista de segurança. Cada plugin Lua roda em um sandbox isolado, com acesso apenas a um subconjunto restrito da biblioteca padrão Lua:

• Sem acesso direto ao sistema de arquivos: a biblioteca io do Lua não é carregada. Todas as operações de arquivo passam pelas funções sbomgen.*.
• Sem execução de subprocessos ou mutação de ambiente: a biblioteca os do Lua é bloqueada, impedindo que plugins iniciem processos, modifiquem variáveis de ambiente ou toquem em arquivos fora do artefato.
• Sem introspecção da Máquina Virtual (VM — Virtual Machine): a biblioteca debug do Lua é bloqueada.
• Sem carregamento irrestrito de código: dofile, loadfile e loadstring são removidos. O require() está disponível, mas restrito à árvore de diretórios do próprio plugin.

Se um plugin gerar um erro Lua não tratado, o inspector-sbomgen registra um aviso e continua com o próximo arquivo ou plugin — um plugin com falha não impede os demais de rodar. Além disso, plugins nunca sobrescrevem os coletores internos do inspector-sbomgen: todo plugin precisa declarar um nome único, e se um plugin personalizado usar um nome já reservado por um plugin oficial, ele é ignorado com um aviso. Os plugins internos sempre têm precedência.

Próximos passos

Para começar a construir seus próprios plugins, a AWS recomenda:

• Instalar a versão mais recente do inspector-sbomgen pelo guia do usuário do Amazon Inspector.
• Executar inspector-sbomgen plugin new --with-example e seguir os prompts.
• Rodar inspector-sbomgen plugin test --path ./my-sbomgen-plugins -v para ver os testes de exemplo passando.
• Substituir a lógica de exemplo pela detecção do seu próprio ecossistema.

A documentação de referência completa cobre todas as funções, constantes e comandos em profundidade:

• Guia do desenvolvedor de plugins Lua: conceitos, estrutura de diretórios e ciclo de vida.
• Guia de testes de plugins Lua: referência do framework de testes e convenções de fixtures.
• Referência da API de plugins Lua: catálogo completo da superfície da API sbomgen.*.

Conclusão

O sistema de plugins do inspector-sbomgen foi projetado para encurtar ao máximo o caminho entre uma ideia e um SBOM funcional — seja para adicionar suporte a um formato interno de lockfile, prototipar detecção para um novo ecossistema open source ou substituir um scanner caseiro por algo que toda a organização possa executar em escala. Com Lua, sandbox seguro, suporte a IDE e integração nativa com o Amazon Inspector, a AWS entrega uma extensibilidade real sem abrir mão da segurança e da previsibilidade da ferramenta.

Fonte

Extend Amazon Inspector SBOM Generator with Plugins (https://aws.amazon.com/blogs/security/extend-amazon-inspector-sbom-generator-with-plugins/)

O que mudou no AgentCore Identity

A AWS anunciou que o Amazon Bedrock AgentCore Identity agora suporta autenticação de cliente via Token Web JSON (JWT) de Chave Privada — o chamado Private Key JWT. Essa novidade muda a forma como agentes de IA se autenticam perante provedores de identidade externos, eliminando a necessidade de compartilhar segredos OAuth 2.0.

Em vez de depender de um segredo de cliente compartilhado, o agente apresenta uma asserção JWT assinada digitalmente. A chave pública fica registrada no provedor de identidade, enquanto a chave privada correspondente permanece protegida dentro do AWS Key Management Service (KMS). O próprio AgentCore Identity solicita ao KMS que assine a asserção — sem que a chave privada precise sair do serviço em nenhum momento.

Como o fluxo de autenticação funciona

Para entender a mecânica, considere um agente de suporte ao cliente que precisa consultar o histórico de pedidos de um usuário em uma API interna protegida por um provedor de identidade. O fluxo acontece assim:

• O agente chama GetResourceOauth2Token no AgentCore Identity para solicitar um token de acesso à API de pedidos.
• O AgentCore Identity lê o ID do cliente, o ARN da chave KMS e o algoritmo de assinatura configurados no provedor de credenciais.
• O serviço monta uma asserção JWT de curta duração com os atributos (claims) necessários e chama kms:Sign usando o algoritmo configurado — RS256, PS256 ou ES256.
• O KMS assina a asserção e devolve apenas a assinatura. A chave privada nunca sai do KMS.
• O AgentCore Identity envia a asserção assinada ao endpoint de token do provedor de identidade com grant_type=client_credentials e client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
• O provedor de identidade verifica a assinatura usando a chave pública registrada e retorna um token de acesso.
• O agente usa esse token para chamar a API de pedidos e receber os dados do cliente.

Fluxos de concessão suportados

A autenticação via Private Key JWT funciona com três modelos de fluxo OAuth diferentes, cobrindo os principais cenários de uso de agentes em produção.

Máquina para máquina (M2M)

Neste modelo, o agente age por conta própria, sem representar nenhum usuário humano. É o caso de jobs em background que sincronizam dados ou serviços que qualquer instância do agente pode acessar independentemente de quem o acionou. O token representa a identidade da aplicação ou do agente. Utiliza o fluxo client_credentials e o subject do token é o próprio cliente.

Em nome de um usuário (On-Behalf-Of — OBO)

Aqui, o agente age em nome de um usuário específico que já está autenticado. Existe um token de entrada do usuário, e o AgentCore Identity o troca por um token downstream que representa esse usuário — mantendo as permissões e a identidade dele na cadeia de chamadas. Dependendo do provedor de identidade, é possível usar a troca de token do RFC 8693 ou a concessão de autorização JWT do RFC 7523.

Acesso delegado pelo usuário

Neste cenário, não há token de entrada para trocar. O usuário passa por um fluxo interativo de login e consentimento — o fluxo de código de autorização OAuth de três pernas — aprovando explicitamente o que o agente pode fazer. Após o consentimento, o agente recebe um token que representa o usuário. Utiliza o fluxo authorization_code.

Pré-requisitos

Para seguir a configuração, a AWS indica que você precisa de:

• Uma conta AWS com acesso ao Console de Gerenciamento para o KMS, o AgentCore e o AWS CloudTrail.
• Um tenant no seu provedor de identidade onde seja possível registrar uma chave pública para uma aplicação.
• URL de descoberta e ID de cliente do provedor de identidade.
• Confirmação do algoritmo de assinatura exigido pelo provedor e verificação de que ele é suportado pelo KMS e pelo AgentCore Identity.
• Permissões IAM: kms:CreateKey e kms:PutKeyPolicy para criar a chave; kms:GetPublicKey para exportar a chave pública; bedrock-agentcore-control:CreateOauth2CredentialProvider para criar o provedor de credenciais. Se o provedor de identidade gerar o par de chaves e fornecer o material da chave privada, também serão necessárias kms:GetParametersForImport e kms:ImportKeyMaterial para importar a chave no KMS.

Passo a passo: configurando o Private Key JWT

Passo 1 — Criar a chave de assinatura no KMS e registrar a chave pública

O primeiro passo é criar uma chave KMS assimétrica que o AgentCore Identity usará para assinar as asserções JWT. Abra o console do AWS KMS na mesma região AWS do seu provedor de credenciais. Em Customer managed keys, escolha Create key e configure:

• Key type: Asymmetric
• Key usage: Sign and verify
• Key spec: compatível com o algoritmo de assinatura desejado (o exemplo da AWS usa ECC_NIST_P256 com o algoritmo ES256)

Na etapa de política da chave, adicione o seguinte statement para conceder ao AgentCore Identity permissão de uso — substituindo 111122223333 pelo ID da sua conta AWS e <region> pela região em uso. A condição kms:ViaService garante que a chave só pode ser usada quando a requisição vier do AgentCore Identity:

{
  "Id": "BedrockAgentCoreIdentityPrivateKeyJwtAccess",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "kms:Sign",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceAccount": "${aws:PrincipalAccount}"
        },
        "StringLike": {
          "kms:ViaService": "bedrock-agentcore-identity.<region>.amazonaws.com"
        }
      }
    }
  ]
}

Após criar a chave, anote o ARN — ele será necessário na configuração do provedor de credenciais. Em seguida, acesse a aba Public key da chave e faça o download da chave pública. O KMS fornece a chave em formato DER. Converta-a para o formato exigido pelo seu provedor de identidade (por exemplo, um certificado X.509 para o Microsoft Entra ID ou uma JSON Web Key para o Okta) e registre-a na sua aplicação.

Passo 2 — Adicionar um cliente OAuth no AgentCore Identity

Abra o console do Amazon Bedrock AgentCore. No painel de navegação esquerdo, em Build, acesse Identity. Na seção Outbound Auth, escolha Add Outbound Auth e depois Add OAuth client.

Passo 3 — Selecionar Private Key JWT como método de autenticação

Na página de adição do cliente OAuth, na seção Provider configurations, configure o Configuration type como Discovery URL para que o AgentCore Identity recupere automaticamente a configuração do provedor. Em Client authentication method, selecione Private key JWT.

Passo 4 — Informar URL de descoberta, ID do cliente, chave KMS e algoritmo

• Discovery URL: a URL onde o provedor publica sua configuração OpenID Connect (terminando em .well-known/openid-configuration).
• Client ID: o identificador do cliente registrado no provedor de identidade.
• KMS key: o ARN da chave KMS assimétrica criada anteriormente. A chave deve ter sido criada com uso SIGN_VERIFY e estar na mesma região. Também é possível usar uma chave de outra conta na mesma região informando o ARN diretamente — nesse caso, são necessárias permissões adicionais em ambas as contas. Veja a documentação sobre como permitir que usuários de outras contas usem uma chave KMS.
• Signing algorithm: o algoritmo exigido pelo seu provedor de identidade, compatível com o key spec da chave KMS.

Passo 5 — (Opcional) Adicionar claims customizados

Se o seu provedor de identidade exigir claims adicionais na asserção JWT, é possível adicioná-los nesta etapa. Em Header claims, adicione claims de cabeçalho específicos do provedor (como um identificador de chave). As chaves reservadas alg e typ não podem ser definidas. Em Payload claims, adicione claims de payload específicos do provedor. As chaves reservadas iss, sub, jti, exp, iat e nbf não podem ser definidas. Por fim, clique em Add OAuth Client e confirme que o provedor de credenciais aparece na lista de Outbound Auth.

Auditoria com CloudTrail

Toda vez que um agente usa o provedor de credenciais para buscar um token, as operações ficam registradas no AWS CloudTrail. Os principais eventos que você verá são:

GetWorkloadAccessToken (fonte: bedrock-agentcore.amazonaws.com) — o agente obtém seu token de identidade de workload. O token retornado é ocultado por razões de segurança:

{
  "eventSource": "bedrock-agentcore.amazonaws.com",
  "eventName": "GetWorkloadAccessToken",
  "requestParameters": {
    "workloadName": "my-agent-workload"
  },
  "responseElements": {
    "workloadAccessToken": "HIDDEN_DUE_TO_SECURITY_REASONS"
  },
  "resources": [
    {
      "accountId": "111122223333",
      "type": "AWS::BedrockAgentCore::WorkloadIdentity",
      "ARN": "arn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default/workload-identity/my-agent-workload"
    }
  ]
}

GetResourceOauth2Token (fonte: bedrock-agentcore.amazonaws.com) — o agente solicita um token de acesso para o recurso downstream. Os parâmetros mostram qual provedor de credenciais, escopos e fluxo OAuth foram usados:

{
  "eventSource": "bedrock-agentcore.amazonaws.com",
  "eventName": "GetResourceOauth2Token",
  "requestParameters": {
    "workloadIdentityToken": "HIDDEN_DUE_TO_SECURITY_REASONS",
    "resourceCredentialProviderName": "my-private-key-jwt-provider",
    "scopes": [
      "https://graph.microsoft.com/.default"
    ],
    "oauth2Flow": "M2M"
  },
  "resources": [
    {
      "accountId": "111122223333",
      "type": "AWS::BedrockAgentCore::OAuth2CredentialProvider",
      "ARN": "arn:aws:bedrock-agentcore:us-east-1:111122223333:token-vault/default/oauth2credentialprovider/my-private-key-jwt-provider"
    }
  ]
}

Sign (fonte: kms.amazonaws.com) — o AgentCore Identity assina a asserção JWT com a chave KMS. Este é o evento que comprova o funcionamento do Private Key JWT: os campos userIdentity.invokedBy, sourceIPAddress e userAgent são todos bedrock-agentcore.amazonaws.com, confirmando que foi o AgentCore Identity quem chamou o kms:Sign. Note que o evento registra o nome do algoritmo de assinatura do KMS, não o nome do algoritmo JWT configurado:

{
  "eventSource": "kms.amazonaws.com",
  "eventName": "Sign",
  "userIdentity": {
    "invokedBy": "bedrock-agentcore.amazonaws.com"
  },
  "sourceIPAddress": "bedrock-agentcore.amazonaws.com",
  "userAgent": "bedrock-agentcore.amazonaws.com",
  "requestParameters": {
    "signingAlgorithm": "RSASSA_PKCS1_V1_5_SHA_256",
    "keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
    "messageType": "DIGEST"
  },
  "responseElements": null,
  "readOnly": true,
  "managementEvent": true,
  "resources": [
    {
      "accountId": "111122223333",
      "type": "AWS::KMS::Key",
      "ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    }
  ]
}

Limpando os recursos criados

Para evitar cobranças desnecessárias e remover recursos que não serão mais usados, a AWS recomenda os seguintes passos:

Remover o provedor de credenciais OAuth

Abra o console do Amazon Bedrock AgentCore, acesse Identity no painel de navegação e localize o provedor criado na seção Outbound Auth. Selecione o provedor, escolha Delete e confirme a exclusão.

Agendar a exclusão da chave KMS

A exclusão de uma chave KMS é irreversível. Por isso, o KMS exige que você agende a exclusão com um período de espera em vez de excluir imediatamente. Antes de agendar, confirme que a chave não está mais referenciada por nenhum provedor de credenciais ou registro de provedor de identidade. Se não tiver certeza se a chave ainda está em uso, considere desativar a chave — o que impede seu uso mas mantém a possibilidade de recuperação.

Abra o console do AWS KMS na região onde a chave foi criada. Em Customer managed keys, selecione a chave assimétrica criada. Em Key actions, escolha Schedule key deletion e defina um período de espera entre 7 e 30 dias. Durante esse período, a chave fica desativada mas pode ser recuperada cancelando a exclusão agendada. Após o período, o KMS a exclui permanentemente. Lembre-se também de remover ou rotacionar a chave pública registrada no provedor de identidade.

Conclusão

Com o suporte a Private Key JWT no AgentCore Identity, a AWS oferece aos desenvolvedores uma forma sem segredos compartilhados e totalmente auditável de autenticar agentes em provedores de identidade externos. A chave privada permanece no KMS, cada operação de assinatura fica registrada no CloudTrail, e o mesmo provedor de credenciais cobre os fluxos M2M, on-behalf-of e de acesso delegado pelo usuário.

Para exemplos completos — incluindo registro em provedores como Entra e Okta, além de fluxos M2M e OBO — a AWS disponibilizou os samples do Amazon Bedrock AgentCore no GitHub.

Fonte

Authenticate with Private Key JWT using Amazon Bedrock AgentCore Identity (https://aws.amazon.com/blogs/machine-learning/authenticate-with-private-key-jwt-using-amazon-bedrock-agentcore-identity/)

O que foi anunciado

A AWS expandiu as capacidades do AWS WAF (Web Application Firewall — Firewall de Aplicações Web) com dois conjuntos de novidades: as transformações de texto pré-parse para argumentos de consulta e dez novas transformações de texto disponíveis para qualquer declaração de regra. Ambas as funcionalidades têm o mesmo objetivo central: garantir que o AWS WAF inspecione as requisições da mesma forma que a sua aplicação as interpreta.

Transformações pré-parse: o que são e por que importam

Antes de o AWS WAF dividir uma query string (string de consulta) em pares de chave-valor, agora é possível aplicar transformações sobre o texto bruto dessa string. Isso fecha duas categorias importantes de brecha de segurança:

• HTTP Parameter Pollution (Poluição de Parâmetros HTTP): técnica em que um atacante envia parâmetros duplicados para confundir a aplicação ou o WAF.
• Parser differential evasion (Evasão por diferença de parser): quando o WAF e a aplicação interpretam a mesma string de formas diferentes, criando uma janela de evasão.

Com as transformações pré-parse, é possível encadear até dez transformações em sequência — por exemplo, decodificação de URL, combinação de argumentos de consulta duplicados por vírgula e substituição de ponto e vírgula por &. Depois disso, ainda é possível empilhar as transformações pós-parse tradicionais dentro da mesma declaração de regra, tudo em uma única configuração.

Dez novas transformações de texto

Além das transformações pré-parse, a AWS também introduziu dez novas opções de normalização de conteúdo, disponíveis para uso em qualquer regra do WAF. Entre elas estão opções consideradas padrão do setor, como:

• Uppercase — conversão para letras maiúsculas
• Trim — remoção de espaços nas extremidades
• Remove Whitespace — remoção de espaços em branco
• SHA256 — geração de hash SHA256 do conteúdo

O conjunto também inclui funções de decodificação de linha de comando com consciência de sistema operacional e decodificação de JavaScript, desenvolvidas pelo Amazon Threat Research Team (Equipe de Pesquisa de Ameaças da Amazon).

Custo e disponibilidade

Cada nova transformação consome 10 WCUs (Web ACL Capacity Units — Unidades de Capacidade de Web ACL). Não há cobrança adicional além do preço padrão do AWS WAF, e o recurso já está disponível em todas as regiões da AWS.

Como começar

Para quem quiser explorar as novidades, a AWS disponibilizou documentação detalhada sobre cada funcionalidade:

• Transformações de texto pré-parse no AWS WAF
• Transformações de texto no AWS WAF
• Primeiros passos com o AWS WAF

Fonte

AWS WAF adds pre-parse text transformations and new text transformations (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-waf/)

O que foi anunciado

A AWS anunciou três novas capacidades para o conector de Interface de Programação de Aplicações REST (REST API) do AWS Glue: suporte a Nuvem Privada Virtual (VPC), filter pushdown e particionamento de dados. Juntas, essas melhorias tornam os pipelines de Extração, Transformação e Carga (ETL) com fontes REST muito mais seguros, eficientes e escaláveis — sem a necessidade de escrever código personalizado.

Contexto: o conector REST API do AWS Glue

O conector REST API do AWS Glue permite ingerir dados de qualquer fonte que exponha uma API baseada em REST, incluindo sistemas proprietários e plataformas emergentes que ainda não possuem conectores nativos no serviço. Com as novidades anunciadas, esse conector passa a cobrir três lacunas importantes que limitavam seu uso em ambientes corporativos mais exigentes.

As três novas capacidades

Suporte a VPC

Com o suporte à VPC, o conector REST API agora consegue acessar fontes de dados hospedadas em sub-redes privadas ou conectadas via VPN ou AWS PrivateLink, sem expor o tráfego à internet pública. Isso é especialmente relevante para organizações que mantêm sistemas internos isolados por questões de segurança e conformidade, e que precisam integrá-los a pipelines de dados na AWS sem abrir brechas de rede.

Filter Pushdown

O filter pushdown traduz os predicados de consulta diretamente em parâmetros nativos da API, fazendo com que apenas os registros correspondentes ao filtro sejam transferidos da fonte. Na prática, isso significa menos dados trafegando pela rede, redução de custos de transferência e melhor desempenho geral dos jobs do Glue — já que o trabalho de filtragem acontece na origem, não após a ingestão.

Suporte a Particionamento

O particionamento divide grandes conjuntos de dados entre múltiplos workers do Spark, utilizando estratégias baseadas em campos ou contagem de registros. O resultado são leituras paralelas que reduzem significativamente o tempo de ingestão em APIs paginadas e de alto volume. Para quem lida com grandes volumes de dados via REST, essa funcionalidade pode representar uma mudança expressiva na performance dos pipelines.

Disponibilidade

Todas essas capacidades já estão disponíveis em todas as regiões comerciais da AWS onde o AWS Glue está presente. Para começar a utilizá-las, a AWS recomenda consultar a documentação oficial do conector REST API do AWS Glue.

Fonte

AWS Glue announces VPC support, filter pushdown, and partition support for the REST API connector (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-glue-rest-connector-filtering-partitioning-vpc)

O problema: os primeiros momentos após a publicação são os mais arriscados

Quem trabalha com desenvolvimento em Amazon Linux e utiliza pacotes do npm ou do PyPI precisa estar atento a um risco específico: o período logo após a publicação de um pacote é, de longe, o mais perigoso do ponto de vista de segurança na cadeia de suprimentos.

Diferente dos pacotes oficiais do Amazon Linux — que passam por revisão dos mantenedores antes do lançamento —, os registros npm e PyPI têm publicação aberta. Qualquer pessoa pode enviar um pacote sem passar por revisão humana obrigatória. Isso abre espaço para que pacotes maliciosos sejam publicados por meio de credenciais roubadas ou ataques de impersonação.

O padrão observado nesses incidentes é sempre parecido: um autor publica um pacote ou versão inesperada e aguarda que sistemas automatizados e usuários o instalem. Pesquisadores de segurança e scanners automatizados geralmente detectam e removem esses pacotes em questão de horas — mas, nesse intervalo, muitos ambientes já foram expostos.

O relatório State of DevSecOps 2026 da Datadog revelou que 54% das aplicações JavaScript instalam ao menos uma dependência dentro de um dia após seu lançamento. Esse é exatamente o janela de maior risco. Veja alguns exemplos reais de eventos recentes e seus tempos de exposição:

• Nx s1ngularity (ago/2025): 4–5 horas
• axios (mar/2026): 2–3 horas
• Bitwarden CLI (abr/2026): 93 minutos
• TanStack (mai/2026): 30 minutos
• node-ipc (mai/2026): menos de 24 horas

Um detalhe importante: vários desses eventos geraram atestados de proveniência válidos e passaram em verificações de build. Ou seja, os mecanismos de autorização tradicionais não foram suficientes para bloqueá-los.

A tensão entre dois tipos de risco

Existe uma tensão natural entre dois riscos que puxam em direções opostas. Por um lado, manter pacotes desatualizados significa acumular vulnerabilidades conhecidas que nunca foram corrigidas. Por outro, instalar versões recém-publicadas significa correr o risco de incluir código malicioso que ainda não foi detectado.

A melhor abordagem, portanto, é se manter atualizado sem adotar versões imediatamente após o lançamento, aplicando correções de segurança recomendadas conforme necessário. É exatamente esse equilíbrio que a solução de cooldown de dependência busca oferecer.

A solução: cooldown de dependência com uma linha de configuração

A AWS apresentou uma solução direta: configurar um cooldown de dependência nos gerenciadores de pacotes npm e pip. Essa configuração instrui o gerenciador a ignorar versões publicadas há menos de 24 horas. Se um pacote não existia no registro pelo tempo configurado, ele simplesmente não será instalado — dando à comunidade de segurança tempo suficiente para identificar e remover versões problemáticas.

Um cooldown de 1 dia teria bloqueado todos os eventos listados na tabela acima. E, ao contrário dos mecanismos de autorização, o cooldown funciona de forma independente: ele bloqueia por idade, não por confiança.

Tanto o npm (versão 11.10.0 ou superior) quanto o pip (versão 26.1 ou superior) já suportam essa funcionalidade. O Amazon Linux 2023 inclui esses pacotes a partir do NodeJS 24 e Python 3.14, disponíveis desde a versão 2023.11.20260608.

Observação importante: se você utiliza instalações baseadas em lockfile — como npm ci ou pip install -r requirements.txt com versões fixadas — o cooldown não se aplica. Esses comandos instalam exatamente o que o lockfile especifica, independentemente da idade do pacote. O cooldown afeta apenas a resolução de pacotes novos ou atualizados.

Pré-requisitos

• Node.js 24 com npm 11.10.0 ou superior (em nodejs24-24.14.1-1.amzn2023.0.1 ou posterior)
• Python 3.14 com pip 26.1 (em python3.14-pip-26.1.1-1.amzn2023.0.1 ou posterior)
• pip-audit (ferramenta para escanear pacotes Python com defeitos conhecidos). Instale com: python3.14 -m pip install pip-audit

Como configurar o cooldown no npm

Crie o diretório de configuração global conforme a versão do NodeJS:

sudo mkdir -p /usr/lib/nodejs24/etc

Adicione a configuração de cooldown:

sudo npm-24 config set min-release-age 1 --location=global

Verifique se o cooldown está ativo:

npm-24 config list

A saída mostrará before = "<timestamp de 24 horas atrás>", confirmando que o npm converteu o cooldown de 1 dia em um filtro de data. Consulte a documentação do npm min-release-age para mais detalhes.

Como configurar o cooldown no pip

Crie o arquivo de configuração global do pip com o cooldown:

sudo python3.14 -m pip config set --global global.uploaded-prior-to P1D

Verifique a configuração:

python3.14 -m pip config list

A saída mostrará global.uploaded-prior-to='P1D'. Essa configuração pode ser aplicada imediatamente com segurança, pois versões mais antigas do pip (25.x) simplesmente ignoram o parâmetro sem causar erros.

Sobrescrevendo o cooldown para aplicar correções de segurança urgentes

O cooldown não precisa ser desativado completamente para aplicar correções de segurança. A recomendação da AWS é identificar os pacotes com vulnerabilidades conhecidas por meio das ferramentas de auditoria e sobrescrever o cooldown apenas para esses pacotes específicos.

Para identificar pacotes que precisam de atualização urgente, execute:

npm auditor
python3.14 -m pip_audit

Para pacotes npm

Instale um pacote específico ignorando o cooldown:

npm-24 install <package-name> --min-release-age=0

Para atualizar automaticamente todos os pacotes npm com vulnerabilidades conhecidas:

npm audit --json | python3 -c "
import json, sys, subprocess
data = json.load(sys.stdin)
for pkg in data.get('vulnerabilities', {}):
    subprocess.run(['npm-24', 'install', f'{pkg}@latest', '--min-release-age=0'])
"

Para pacotes pip

Instale um pacote específico ignorando o cooldown:

python3.14 -m pip install <package-name> --uploaded-prior-to="P0D"

Para atualizar automaticamente todos os pacotes pip com vulnerabilidades conhecidas:

python3.14 -m pip_audit --format=json | python3 -c "
import json, sys, subprocess
data = json.load(sys.stdin)
for vuln in data:
    pkg = vuln['name']
    fix = vuln.get('fix_versions', ['latest'])[0]
    subprocess.run(['python3.14', '-m', 'pip', 'install', f'{pkg}=={fix}', '--uploaded-prior-to=\"P0D\"'])
"

Importante: os scripts acima demonstram o conceito. Para uso em produção, adicione tratamento de erros, logging e testes adequados. Revise os pacotes antes de atualizá-los em pipelines automatizados.

Adoção da indústria: cooldowns já são tendência

A estratégia de cooldown de dependência já está sendo adotada por ferramentas e empresas relevantes do ecossistema. A partir de maio de 2026, diversas ferramentas populares passaram a incluir esse recurso:

• pnpm 11: já vem com minimumReleaseAge habilitado por padrão — um dos primeiros gerenciadores de pacotes a tornar o cooldown opt-out em vez de opt-in.
• Renovate: o preset config best-practices inclui um cooldown de 3 dias para npm desde 2025, amplamente adotado em empresas.
• StepSecurity Secure Registry: oferece período de cooldown configurável para clientes corporativos, com recomendação padrão de 10 dias.

Como a AWS contribui para a segurança da cadeia de suprimentos open source

A AWS também atua de forma proativa no monitoramento dos registros de pacotes. O Amazon Inspector, serviço de gerenciamento de segurança que escaneia continuamente cargas de trabalho em busca de vulnerabilidades e exposições de rede, utiliza regras de detecção assistidas por Inteligência Artificial (IA) para monitorar registros upstream de pacotes.

Em 2025, pesquisadores do Amazon Inspector identificaram mais de 150.000 pacotes npm inesperados vinculados a uma campanha de mineração de tokens. A equipe de segurança da AWS também publicou orientações detalhadas de resposta ao worm Shai-Hulud e ao evento do axios.

Além disso, a AWS contribui com a Open Source Security Foundation (OpenSSF) por meio de um grant de US$ 12,5 milhões para segurança open source, financiando infraestrutura de escaneamento proativo que beneficia todo o ecossistema.

Pacotes inesperados normalmente são detectados em poucas horas após a publicação. Um cooldown de 1 dia garante que você não os instale durante essa janela de detecção.

Recomendações práticas

Para proteger seu ambiente Amazon Linux 2023, a AWS recomenda:

• Configure um cooldown de 1 dia para npm e pip conforme os passos descritos acima. Registros externos não têm revisão humana — dê tempo aos defensores para identificar problemas.
• Sobrescreva o cooldown quando necessário para aplicar correções de segurança urgentes, usando as flags por comando.
• Execute npm audit ou pip_audit regularmente para identificar pacotes que precisam de atenção imediata.

Recursos adicionais

• Boas práticas de segurança do NodeJS
• Documentação do npm min-release-age
• Documentação de instalações seguras do pip
• Documentação do pip uploaded-prior-to
• Boas práticas da OpenSSF
• Documentação do Amazon Linux 2023

Fonte

Secure your npm and pip package updates in Amazon Linux (https://aws.amazon.com/blogs/security/secure-your-npm-and-pip-package-updates-in-amazon-linux/)