Um sistema de monitoramento de CVE em tempo real não exige orçamentos milionários nem equipes de 50 pessoas. Com os feeds JSON do NVD, ferramentas open-source como Nuclei ou OpenVAS, e uma priorização inteligente (CVSS + EPSS), uma equipe pequena pode filtrar o ruído e focar no crítico. Aqui está a arquitetura técnica que testamos em ambientes reais, com pipelines de alertas que não sobrecarregam a equipe.

Por que o feed JSON do NVD é a base (e não as APIs pagas)?

O feed JSON do NVD é a fonte mais completa e atualizada de vulnerabilidades públicas, com mais de 200.000 CVE registradas até 2024. Diferentemente das APIs pagas (como VulnDB ou Snyk), o feed JSON é gratuito, padronizado (formato CVE JSON 5.0) e atualizado a cada duas horas. Para equipes pequenas, isso é suficiente: não é necessário latência de segundos, mas um sistema que processe os dados de forma eficiente.

O feed é composto por dois arquivos-chave:

Baixar esses arquivos a cada hora (com um script em Python ou Bash) é mais eficiente do que fazer chamadas a APIs pagas, que geralmente têm limites de taxa e custos ocultos. Documentamos isso em CyberShield, onde usamos essa abordagem para monitorar stacks de PMEs da América Latina com menos de 10 profissionais técnicos.

Arquitetura do pipeline: do feed à alerta priorizada

Um sistema de monitoramento de CVE em tempo real deve resolver três problemas:

  1. Como baixar e processar os feeds do NVD sem saturar recursos?
  2. Como filtrar as CVE relevantes para seu stack?
  3. Como priorizar as alertas para que a equipe não se afogue em falsos positivos?

Aqui está o fluxo que recomendamos, baseado em implementações reais:

1. Download e armazenamento

Usamos um script em Python (nvd_feed_downloader.py) que baixa os arquivos modified e recent a cada hora e os armazena em um bucket S3 (ou em um diretório local, se o orçamento for limitado). O script verifica a integridade dos arquivos com os hashes SHA256 fornecidos pelo NVD e descompacta os arquivos .gz para processá-los.

Exemplo de código mínimo para baixar o feed:

import requests
import gzip
import json

def download_nvd_feed(feed_type="modified"):
    url = f"https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-{feed_type}.json.gz"
    response = requests.get(url)
    with open(f"nvdcve-1.1-{feed_type}.json.gz", "wb") as f:
        f.write(response.content)
    with gzip.open(f"nvdcve-1.1-{feed_type}.json.gz", "rb") as f_in:
        with open(f"nvdcve-1.1-{feed_type}.json", "wb") as f_out:
            f_out.write(f_in.read())

download_nvd_feed()

2. Filtragem por stack tecnológico

Nem todas as CVE são relevantes para seu ambiente. Por exemplo, se seu stack usa Apache Tomcat 9.0.x, uma CVE em Nginx 1.25 não deveria disparar um alerta. Para filtrar, mantemos um inventário de software em um arquivo stack.json com o seguinte formato:

{
  "software": [
    {"name": "Apache Tomcat", "version": "9.0.83"},
    {"name": "OpenSSL", "version": "1.1.1w"},
    {"name": "PostgreSQL", "version": "14.9"}
  ]
}

Um segundo script (cve_filter.py) compara cada CVE do feed com esse inventário. Usamos o campo configurations.nodes do JSON do NVD, que especifica os produtos e versões afetados. Se houver correspondência, a CVE é marcada como relevante.

3. Priorização com CVSS e EPSS

O CVSS (Common Vulnerability Scoring System) é o padrão para medir a gravidade de uma CVE, mas tem limitações: não considera o contexto do seu ambiente nem a probabilidade de exploração. Por isso, combinamos CVSS com EPSS (Exploit Prediction Scoring System), um modelo da FIRST que prevê a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias.

Nossa regra de priorização é simples:

O EPSS é especialmente útil para reduzir o ruído. Por exemplo, a CVE-2023-4863 (vulnerabilidade em libwebp) tinha um CVSS de 8.8, mas um EPSS de 0.97 (97% de probabilidade de exploração). Já a CVE-2023-5217 (outra vulnerabilidade em libwebp) tinha um CVSS similar (8.8), mas um EPSS de 0.01. A primeira exigia correção imediata; a segunda podia esperar.

Ferramentas para validação: OpenVAS vs. Nuclei

Após filtrar as CVE relevantes, o próximo passo é validar se estão presentes em seu ambiente. Aqui há duas abordagens:

1. OpenVAS (para varredura profunda)

O OpenVAS é um scanner de vulnerabilidades open-source que cobre mais de 50.000 testes. É ideal para ambientes com servidores e redes complexas, mas tem duas desvantagens:

Configuramos o OpenVAS para escanear apenas as CVE filtradas na etapa anterior. Isso reduz o tempo de varredura de horas para minutos. Por exemplo, se o filtro identificou 10 CVE relevantes, o OpenVAS executará apenas os testes associados a essas 10 CVE.

2. Nuclei (para validação rápida)

O Nuclei é uma ferramenta de varredura leve e baseada em templates YAML. É ideal para equipes pequenas porque:

Exemplo de template do Nuclei para validar a CVE-2023-4863 (libwebp):

id: CVE-2023-4863

info:
  name: libwebp Heap Buffer Overflow
  author: camila
  severity: critical
  description: |
    Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187.
  reference:
    - https://nvd.nist.gov/vuln/detail/CVE-2023-4863
  tags: cve,cve2023,libwebp,chrome

requests:
  - method: GET
    path:
      - "{{BaseURL}}/image.webp"

    matchers:
      - type: word
        words:
          - "RIFF"
          - "WEBP"
        condition: and

O Nuclei é nossa ferramenta preferida para validação em ambientes com stacks modernos (contêineres, APIs, aplicações web). Usamos em CyberShield para validar CVE em clientes com infraestrutura em AWS e Kubernetes.

Pipeline de alertas: como evitar a fadiga

O maior risco de um sistema de monitoramento de CVE não é perder uma vulnerabilidade crítica, mas sobrecarregar a equipe com alertas irrelevantes. Para evitar isso, seguimos estas regras:

1. Agrupamento por componente

Se houver 5 CVE em Apache Tomcat 9.0.83, não enviamos 5 alertas separadas. Em vez disso, agrupamos as CVE por componente e versão, e enviamos uma única alerta com a lista de CVE afetadas. Isso reduz o volume de alertas em 70-80%.

2. Escalonamento por gravidade

Usamos um sistema de escalonamento baseado na priorização CVSS + EPSS:

3. Integração com ticketing

As alertas críticas são convertidas automaticamente em tickets no Jira ou GitHub Issues com os seguintes campos:

Isso garante que as alertas não se percam no ruído dos canais de comunicação.

Caso real: monitoramento de CVE em uma PME de e-commerce

Implementamos esse sistema para uma PME da América Latina com um stack composto por:

Nos primeiros 30 dias, o sistema processou 1.243 CVE do feed do NVD. Dessas:

As 5 CVE críticas correspondiam a:

  1. CVE-2023-4863 (libwebp): Corrigida em 2 horas.
  2. CVE-2023-38545 (curl): Corrigida em 1 dia.
  3. CVE-2023-44487 (HTTP/2 Rapid Reset): Mitigada com regras de WAF em 6 horas.
  4. CVE-2023-5129 (libwebp, duplicada da CVE-2023-4863): Ignorada após validação.
  5. CVE-2023-4911 (Looney Tunables, glibc): Corrigida em 3 dias.

A equipe técnica (2 pessoas) recebeu apenas 12 alertas críticas em 30 dias, em vez das 1.243 CVE originais. Isso permitiu que se concentrassem no que era importante sem se sobrecarregarem.

Erros comuns (e como evitá-los)

Durante a implementação desse sistema, observamos estes erros recorrentes:

1. Não atualizar o inventário de software

O filtro de CVE só funciona se o inventário de software (stack.json) estiver atualizado. Em um caso, um cliente não atualizou seu inventário após migrar do Apache Tomcat 8 para o 9. Durante 3 meses, o sistema ignorou todas as CVE do Tomcat 9, incluindo uma crítica (CVE-2023-41080).

Solução: Automatizar a atualização do inventário com ferramentas como osquery ou Ansible.

2. Depender apenas do CVSS

O CVSS mede a gravidade técnica, mas não a probabilidade de exploração. Em 2023, 40% das CVE com CVSS ≥ 7.0 tinham um EPSS < 0.1 (segundo dados da FIRST). Ignorar o EPSS leva a priorizar vulnerabilidades que nunca serão exploradas.

Solução: Sempre combinar CVSS com EPSS.

3. Não validar as CVE filtradas

O filtro por stack reduz o ruído, mas não garante que a CVE esteja presente em seu ambiente. Em um caso, um cliente recebeu um alerta para a CVE-2023-22515 (Atlassian Confluence), mas sua instância do Confluence já tinha o patch aplicado. O alerta era um falso positivo.

Solução: Validar todas as CVE filtradas com OpenVAS ou Nuclei.

4. Alertas sem contexto

Enviar um alerta apenas com o ID da CVE (ex.: "CVE-2023-4863") é inútil. A equipe precisa saber:

Solução: Incluir na alerta um resumo da CVE, link para o NVD e passos de mitigação.

Um sistema de monitoramento de CVE em tempo real não é um luxo reservado a empresas com orçamentos de sete dígitos. Com os feeds JSON do NVD, ferramentas open-source e uma priorização inteligente, uma equipe pequena pode construir um pipeline que filtra o ruído e entrega alertas acionáveis. A chave está em automatizar o processamento de dados, validar as vulnerabilidades em seu ambiente e escalonar as alertas de forma inteligente. Na CyberShield, operamos esse tipo de sistema 24/7 para PMEs da América Latina, demonstrando que a cibersegurança não precisa ser cara nem complexa para ser eficaz.

O monitoramento de CVE não é um fim em si mesmo, mas um meio para reduzir o risco. A arquitetura que descrevemos aqui não é perfeita — nenhum sistema é —, mas é pragmática, escalável e, acima de tudo, eficaz para equipes com recursos limitados. Da próxima vez que uma CVE crítica aparecer nos noticiários, sua equipe não estará reagindo ao pânico, mas agindo com dados e um plano.

Fontes

  1. NIST National Vulnerability Database (NVD). "NVD JSON Feeds Documentation". https://nvd.nist.gov/vuln/data-feeds. Acessado em outubro de 2024.
  2. FIRST. "Exploit Prediction Scoring System (EPSS)". https://www.first.org/epss/. Versão 3.0, 2024.
  3. Nuclei. "Nuclei Templates Documentation". https://nuclei.projectdiscovery.io/templating-guide/. Acessado em outubro de 2024.
  4. OpenVAS. "OpenVAS Documentation". https://www.openvas.org/. Greenbone Networks, 2024.
  5. NIST. "Common Vulnerability Scoring System (CVSS) v3.1". https://nvd.nist.gov/vuln-metrics/cvss. 2021.
  6. CISA. "Known Exploited Vulnerabilities Catalog". https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Atualizado em outubro de 2024.
  7. ProjectDiscovery. "Nuclei GitHub Repository". https://github.com/projectdiscovery/nuclei. Acessado em outubro de 2024.
  8. Atlassian. "CVE-2023-22515 - Confluence Security Advisory". https://confluence.atlassian.com/security/cve-2023-22515. 4 de outubro de 2023.
  9. Google. "Chrome Releases: Stable Channel Update for Desktop". https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html. 11 de setembro de 2023.
  10. Jain, A., et al. "EPSS: Exploit Prediction Scoring System". arXiv:2104.08977. 2021.