Varredura de Segurança

O que Varredura de Segurança faz?

Responder bem a uma pergunta: esses projetos estão expostos a uma vulnerabilidade de dependência que importa agora? "Importa agora" significa catalogado e acessível, ou um incidente ativo na natureza que ainda não se propagou totalmente para os bancos de dados de auditoria.

O valor sobre um simples npm audit é a camada de pesquisa. Os bancos de dados de avisos ficam atrasados em relação à divulgação, e incidentes de pacotes maliciosos são frequentemente tratados com a remoção da publicação (sem aviso consultável). Portanto, esta varredura combina as ferramentas determinísticas com pesquisa ao vivo sobre o que está sendo ativamente explorado e verifica o arquivo de bloqueio diretamente para esses nomes — o sinal confiável mais rápido, que nenhuma ferramenta de auditoria oferece.

Somente leitura por padrão: isso investiga e relata. Apenas proponha correções; não aplique aumentos de versão sem a aprovação do usuário (eles podem quebrar compilações).

Quando usar

• "Investigar segurança" / "verificar dependências vulneráveis" / "executar uma varredura de segurança."
• "Somos afetados por <um CVE, GHSA ou história de comprometimento de pacote específico>?" — o usuário leu sobre algo e quer saber sua exposição.
• Uma verificação periódica (componha com o skill schedule para uma varredura em nuvem recorrente — veja o final).

Passo 1 — Escopo

Decida o que examinar. Padrão para o projeto atual; ofereça uma varredura de vários repositórios se a frase do usuário for ampla ("nossos projetos", "tudo", "a frota").

• Projeto atual: o repositório em que você está.
• Vários repositórios: enumere os repositórios irmãos próximos ao atual — ou seja, o pai da raiz git atual (comumente ~/projects/*/ ou ~/src/*/). Confirme o diretório com o usuário antes de percorrê-lo, em vez de presumir; um palpite errado desperdiça uma varredura longa. Para cada repositório, detecte ecossistemas pelo manifesto (abaixo), faça a varredura por vez, relate por projeto.

Passo 2 — Detectar ecossistemas e localizar arquivos de bloqueio

Por projeto, um ecossistema está presente se seu arquivo de bloqueio for:

Ecossistema	Manifesto / arquivo de bloqueio	Onde geralmente fica
npm	package-lock.json	frontend/ ou raiz do repositório
Go	go.mod / go.sum	backend/ ou raiz do repositório
Python	poetry.lock, requirements.txt, uv.lock	raiz do repositório
Swift/SPM	Package.resolved	ios/ ou um .xcodeproj

O arquivo de bloqueio — não o manifesto — é o que você examina: ele fixa as versões transitivas exatas realmente instaladas.

Passo 3 — Linha de base determinística (por ecossistema)

Execute a própria ferramenta do ecossistema. Elas capturam tudo o que já está nos bancos de dados de avisos. Prefira ferramentas com análise de alcançabilidade (elas relatam apenas vulnerabilidades que seu código pode realmente alcançar) quando disponíveis.

• npm: cd <dir> && npm audit --omit=dev --audit-level=high (o que vai para os usuários) e um simples npm audit (tudo, informativo). Sem alcançabilidade — relata demais; pondere descobertas de produção.
• Go: govulncheck ./... — faz análise de alcançabilidade (sinaliza apenas vulnerabilidades em código chamado); instale uma vez com go install golang.org/x/vuln/cmd/govulncheck@latest. O padrão ouro dessas ferramentas.
• Python: pip-audit (ou pip-audit -r requirements.txt).
• Qualquer ecossistema, ou quando uma ferramenta está faltando: osv-scanner contra o arquivo de bloqueio, executado via contêiner para que não haja nada para instalar: <runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>. Banco de dados mais amplo; a alternativa para Swift/SPM, que tem ferramentas de primeira parte escassas.

Capture o que cada um relata. Distinga produção/alcançável de desenvolvimento/tempo de compilação — um alto em uma ferramenta de compilação que nunca é enviada não é o mesmo que uma descoberta em uma dependência de tempo de execução.

Passo 4 — Pesquisar o cenário de ameaças ativo (o valor agregado)

Isso é o que uma auditoria simples não pode fazer. Use WebSearch / WebFetch para encontrar o que está atualmente ativo, então traga os nomes de volta para o Passo 5.

• Incidentes recentes na cadeia de suprimentos nos ecossistemas do projeto: pesquise por campanhas recentes de comprometimento e malware npm/PyPI/Go; verifique o Banco de Dados de Avisos do GitHub (github.com/advisories) e OSV (osv.dev) para entradas publicadas recentemente tocando pacotes que você viu no Passo 2.
• Se o usuário nomeou um CVE / GHSA / incidente específico, busque o aviso oficial e extraia o(s) nome(s) exato(s) do(s) pacote(s) afetado(s) e faixa(s) de versão — é isso que você comparará com o arquivo de bloqueio.
• Prefira fontes primárias (o aviso, a postagem do mantenedor, o aviso de segurança do registro) em vez de manchetes de agregadores; observe quando algo não for confirmado.

Mantenha atual: date cada afirmação e diga qual foi sua janela de pesquisa (por exemplo, "incidentes ativos divulgados nas últimas ~8 semanas").

Passo 5 — Cruzar referências de nomes contra o arquivo de bloqueio diretamente

Para cada pacote descoberto no Passo 4, não espere pela ferramenta de auditoria — verifique a árvore fixada você mesmo. Este é o passo do sinal antecipado:

# npm
cd <dir> && npm ls <pacote>
grep -n '"<pacote>"' package-lock.json
# Go
grep -n '<caminho-do-módulo>' go.sum
# Python
grep -in '<pacote>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<pacote>' --include=Package.resolved .

Em seguida, compare a versão fixada com a faixa afetada do aviso. Três resultados por nome: exposto (presente e na faixa), limpo (ausente, ou presente mas fora da faixa), incerto (versão transitiva que você não conseguiu resolver completamente — investigue mais ou sinalize).

Passo 6 — Relatório

Por projeto, lidere com o veredito, depois as evidências:

• Expoto — pacote, versão fixada, aviso/incidente, se é alcançável em produção, e uma remediação concreta (aumento de versão direcionado; nunca um npm audit fix cego). Se uma versão comprometida pode ter sido instalada, observe que seu pós-instalação pode já ter sido executado — a maior razão pela qual um padrão ignore-scripts é importante.
• Limpo — as ameaças ativas pesquisadas verificadas e não presentes. Diga o que você verificou, para que "limpo" signifique algo.
• Incerto / não coberto — ecossistemas com ferramentas escassas (Swift), transitivas não resolvidas, ou pesquisa que não pôde confirmar uma faixa. Nomeie a lacuna em vez de implicar cobertura total.

Não implique que você encontrou tudo. Indique a janela e os ecossistemas realmente examinados.

Composição

• Varredura recorrente: passe o procedimento deste skill para o skill schedule para uma execução semanal em nuvem nos repositórios, para que um novo incidente seja detectado em dias, em vez de quando alguém pensar em olhar.
• Antes de um lançamento ou push: execute uma varredura de projeto único focada. Ela combina naturalmente com uma etapa de pré-push make audit / make secret-scan se o projeto tiver uma.

Notas

• Ferramentas de auditoria são indicadores atrasados; as notícias e o Passo 4 deste skill são os antecedentes. Quando eles discordarem — a pesquisa diz que um pacote está comprometido, mas as ferramentas estão em silêncio — confie na verificação direta do arquivo de bloqueio e trate como ativo.
• npm audit relata gravidade do aviso, não sua explorabilidade (sem análise de alcançabilidade) — ele relata demais. govulncheck é o oposto e o modelo a preferir onde um ecossistema o oferecer.
• Este skill responde à exposição. A remediação (aumentos de versão, fixação, npm rebuild para uma exceção de script direcionada) é uma etapa separada e aprovada pelo usuário — mostre a correção, não a aplique sem aviso prévio.