Para: quem administra os próprios sites ou serviços e quer receber informações sobre vulnerabilidades sem precisar acompanhar feeds manualmente. Este artigo aborda o que coletar, com o que cruzar e até que ponto confiar na IA.
O que aconteceu: uma pessoa soube primeiro, três vezes seguidas
Em uma única semana, em sites que o operador deste site administra, três situações ocorreram. Em todos os casos, o operador soube primeiro, por meio de redes sociais ou e-mail, e o monitoramento automatizado não tinha reportado nada até aquele momento.
Caso 1
Uma vulnerabilidade em PHP. O operador soube primeiro. O monitoramento automatizado não a havia sinalizado.Caso 2
Código malicioso inserido em um pacote Python. O operador soube primeiro. O monitoramento automatizado não o havia sinalizado.Caso 3
Um problema em uma imagem base de contêiner. O operador soube primeiro. O monitoramento automatizado não o havia sinalizado.
A primeira suspeita foi de "poucas fontes". Não houve uma causa única: as fontes oficiais podem ficar atrás do que está em alta (veja mais abaixo), e também faltou material para decidir se um item dizia respeito à nossa configuração. Termos como "PHP" ou "Python" aparecem em textos de notícias, mas isso é diferente dos nomes dos pacotes que você efetivamente executa.
O monitoramento reconstruído
1. Coletar
Avisos oficiais / avisos do GitHub / listas de pacotes maliciosos / KEV / notícias / redes sociais
↓
Lista A: termos de tecnologia que usamos
Rede ampla
Lista B: nomes reais dos componentes
Gerada a partir de lockfiles e pacotes do sistema operacional
↓
2. Regras capturam as correspondências (funcionam sem IA)
↓
3. Um modelo de IA barato faz a triagem inicial
Pode elevar a urgência. Não pode reduzi-la.
- O que coleta: avisos oficiais, avisos do GitHub, listas de pacotes maliciosos, KEV da CISA, notícias e redes sociais.
- Duas listas para cruzar: termos de tecnologia para uma rede ampla, e nomes reais dos componentes para correspondências de alta confiança. A lista de componentes é montada a partir dos lockfiles de todos os repositórios, somados aos pacotes do sistema operacional.
- Varredura da imagem inteira: verifica a imagem completa, incluindo a imagem base, e não apenas as dependências da aplicação.
- Defasagem de runtime: mede o quanto runtimes como Node, PHP e o banco de dados estão atrasados em relação às suas versões mais recentes.
- Primeira triagem por IA: um modelo de IA barato faz a primeira avaliação de "isto nos afeta?". A IA só pode elevar a urgência.
O que as medições mostraram, incluindo o que contrariou as expectativas
Premissa inicial: fontes oficiais bastam
Partimos do princípio de que acompanhar os avisos oficiais e o KEV captaria o que importa. Na prática, um assunto pode entrar em destaque antes de o aviso oficial ser publicado. As fontes oficiais, sozinhas, perdem essa corrida.
Após medir: adicionar redes sociais como ponto de entrada
Incluir redes sociais permitiu que o monitoramento percebesse coisas mais cedo do que apenas com fontes oficiais. Mas o conteúdo de redes sociais não é tratado como fato até que uma fonte oficial o confirme. Amplo na entrada, cuidadoso na decisão.
- Verificação de falhas: cerca de 100 vulnerabilidades críticas reunidas em 10 dias por um monitoramento separado (criado para encontrar candidatos a artigos) foram cruzadas com este monitoramento. Falhas entre as que afetaram os sites do operador: 0.
- Cota de IA esgotada: a cota mensal se esgotou e a triagem por IA ficou pausada por cerca de 6 dias. A correspondência por regras, que não usa IA, continuou funcionando o tempo todo. O projeto define uma data de fim da pausa com antecedência, e a parte de IA é retomada automaticamente a partir dessa data.
- Lacuna em um novo servidor: os pacotes do sistema operacional de um servidor recém-adicionado não estavam na lista de componentes. A reconstrução mensal da lista identificou o problema. Uma lista só é confiável se for regenerada regularmente, e não apenas criada uma vez.
Como montar isso no seu próprio ambiente
Gere a lista de componentes (SBOM) de forma mecânica
Monte-a a partir dos lockfiles de todos os repositórios e dos pacotes do sistema operacional dos seus servidores e contêineres. A CISA descreve um SBOM como um inventário aninhado, uma lista dos ingredientes que compõem os componentes de software. Geradores de SBOM como o Syft, de código aberto, leem pacotes do sistema operacional e as dependências das principais linguagens a partir de imagens de contêiner e sistemas de arquivos, e podem gerar saída em CycloneDX ou SPDX.
Cruze a lista com vulnerabilidades conhecidas
Para o cruzamento de dependências, o osv-scanner, de código aberto, lê lockfiles e contêineres. A configuração e a integração com CI estão descritas em osv-scanner: configuração e uso.
Priorize com KEV e EPSS
Quando há muitos achados, não é possível corrigi-los todos com a mesma urgência. Comece pelo que está confirmadamente sendo explorado (KEV) e pelo que tem alta probabilidade prevista de exploração (EPSS). Como combiná-los está em CVSS, EPSS e KEV: como usá-los em conjunto.
Se usar IA, use-a apenas para elevar
Mesmo que a IA diga "não afetado", não remova um item que uma regra captou. A IA pode dizer incorretamente "não relacionado", e o custo de um falso negativo é maior que o custo de um falso alarme.
Defina o que acontece quando a IA estiver indisponível
Cotas se esgotam, serviços falham e provedores deixam de funcionar. Antes de operar, defina que as regras sem IA, sozinhas, ainda enviam um conjunto mínimo de notificações, e configure uma data de retomada para que a parte de IA volte automaticamente.
Regenere a lista regularmente
As lacunas surgem quando um servidor ou repositório é adicionado, mas a lista não é atualizada. Reconstrua-a pelo menos uma vez por mês e confira se o que você adicionou está nela.
Não trate redes sociais como fato até que uma fonte oficial confirme
As redes sociais são rápidas, mas misturam erros e especulações que o fornecedor não confirmou. Use-as como ponto de entrada, mas baseie sua resposta em fontes primárias verificáveis, como o aviso do fornecedor ou o KEV.
Visão deste site: rede ampla nos termos de tecnologia, estreitada pelos nomes dos componentes
Na experiência do operador, a mudança para o cruzamento com os nomes reais dos componentes reduziu tanto os falsos positivos quanto as falhas. Mas, se a lista de componentes estiver desatualizada, isso leva diretamente a falhas. Você precisa das duas coisas: uma rede ampla e uma lista precisa para estreitá-la. Este artigo descreve o monitoramento construído para os sites operados pelo operador.
Fontes (primárias e oficiais)
- CISA — Known Exploited Vulnerabilities Catalog (vulnerabilidades confirmadas como exploradas)
- CISA — Software Bill of Materials (SBOM) (definição de SBOM)
- FIRST — EPSS (probabilidade prevista de exploração)
- OpenSSF — malicious-packages (repositório de relatórios de pacotes maliciosos no formato OSV)
- Anchore — Syft (gera SBOMs a partir de imagens de contêiner e sistemas de arquivos; saída em CycloneDX e SPDX; pacotes do sistema operacional e principais linguagens)
Leia em seguida
- Ferramenta: osv-scanner: configuração e uso
- Priorização: CVSS, EPSS e KEV: como usá-los em conjunto
- Exemplo: Versão de segurança crítica do PHP
- Relacionado: Como se defender de ataques à cadeia de suprimentos do npm