Threat intel para engenheiros: verifique a sua stack, ignore o resto

23.09.20264 min de leituraEquipa Atalaia

Às equipas de engenharia diz-se que devem "consumir threat intelligence". Na prática, isso significa um feed de advisories, posts de blogs de fornecedores e relatórios sobre atores, a maioria sem nada a ver com o software que correm. O resultado é fadiga de alertas ou um feed que ninguém lê.

A nossa posição é simples. Para uma equipa de engenharia, a threat intelligence é útil quando responde depressa a uma pergunta: isto está na nossa stack, e é alcançável? Tudo o que não ajuda a responder a isso pode esperar ou sair.

O que significa threat intel para engenheiros

Um SOC ou uma equipa de intel dedicada preocupa-se com atores, campanhas e indicadores. Esse trabalho tem valor, mas não é o que uma equipa de produto precisa logo de manhã. Os engenheiros precisam de saber quando uma dependência, imagem base, ferramenta de build ou integração SaaS que usam tem um problema conhecido, e se devem largar o que estão a fazer.

Isso transforma a threat intel de um exercício de leitura numa pesquisa. O advisory diz "pacote X, versões abaixo de Y". A pergunta de engenharia é "onde é que temos X abaixo de Y?" Se responder a isso demora um dia a perguntar no chat, a intel chega tarde demais para importar.

Faça da resposta uma query

A forma de tornar essa pesquisa rápida é ter um software bill of materials atual para cada serviço e imagem, guardado num sítio onde possa pesquisar. Gere-os no CI com o Syft em cada build:

# In CI, after building the image
syft registry.example.test/payments-api:1.42.0 \
  -o cyclonedx-json=sbom/payments-api.cdx.json

Quando sai um advisory, pode verificar um SBOM em segundos:

# Which version of a named package is in this service?
jq -r '.components[] | select(.name == "xz" or .name == "liblzma")
  | [.name, .version] | @tsv' sbom/payments-api.cdx.json

# Scan an SBOM against current vulnerability data with Grype
grype sbom:sbom/payments-api.cdx.json --only-fixed

E em todo o parque:

# Every service that ships a given package, with versions
for f in sbom/*.cdx.json; do
  jq -r --arg svc "$(basename "$f" .cdx.json)" \
    '.components[] | select(.name == "lodash")
     | [$svc, .version] | @tsv' "$f"
done | sort -u

Junte o SBOM aos dados de deploy, que versão de cada serviço está a correr em que ambiente, e consegue dizer não só "temos isto" mas "temos isto em produção nestes três serviços".

Em que agir

Quando conseguir responder à pesquisa depressa, o filtro para agir é curto:

• Explorado ativamente, e presente nos seus SBOMs. Os catálogos públicos de vulnerabilidades exploradas são um bom sinal principal. Uma correspondência aqui é trabalho para hoje.
• Tudo o que toque nas suas ferramentas de build e release. Actions de CI comprometidas, worms em registries de pacotes e dependências de build com backdoor atingem a fábrica, não apenas um produto. O compromisso do tj-actions/changed-files (março de 2025) e o worm npm Shai-Hulud (setembro de 2025) são exemplos desta classe.
• Acessível a partir da internet. Uma biblioteca vulnerável num batch job interno é menos urgente do que a mesma biblioteca atrás de uma API pública. Use o que sabe da arquitetura para ordenar.
• Os seus fornecedores de identidade e SaaS. Incidentes nos serviços que guardam os seus tokens ou o seu código precisam de resposta mesmo quando não há nenhum pacote envolvido: rodar, rever os logs de auditoria, procurar novos acessos.

O que ignorar

Esta é a parte que as pessoas acham desconfortável, mas dizer não é o que mantém o feed útil.

• Perfis de atores e nomes de campanhas. Leitura interessante, raramente acionável para uma equipa de produto. Deixe-os a quem faz deteção.
• Relatórios genéricos de tendências. "Os ataques à cloud estão a aumentar" não muda o que faz esta semana.
• Advisories para software que não usa. Se a consulta ao SBOM não devolver nada, está feito. Registe que verificou e siga em frente.
• Scores de severidade isolados. Um score crítico num caminho de código que nunca chama tem menos prioridade do que um médio na sua página de login.
• Listas de indicadores sem contexto. Listas de IPs e hashes pertencem às ferramentas de deteção, não a um canal de engenharia.

O que faríamos

1. Gere um SBOM CycloneDX com o Syft para cada imagem na CI, associado ao digest da imagem.
2. Guarde os SBOMs de forma centralizada e mantenha um mapa de que digest corre onde.
3. Subscreva um canal a um pequeno conjunto de fontes: a base de dados de advisories dos seus ecossistemas de pacotes, um catálogo de vulnerabilidades exploradas conhecidas e os avisos de segurança do seu Git host, CI e cloud provider.
4. Para cada novo advisory, corra a query ao SBOM. Publique a resposta, com ou sem correspondência, na thread dentro de uma hora.
5. Escale apenas as correspondências que estão a ser exploradas, que são alcançáveis ou que estão nas suas ferramentas de build. Tudo o resto passa a ser uma atualização normal de dependências.

Threat intel feita assim tem menos a ver com ler mais e mais a ver com responder mais depressa. O SBOM é a lista de peças da linha; mantenha-o atual e a maioria dos advisories passa a ser uma verificação de dois minutos.

Onde isto fica na linha

Na torre (em desenvolvimento):