[v0.2] Decisão de escopo: cobrir comprometimento de runner CI/CD (IMDS)

[YDSantos12]

Contexto

Datadog destaca que o Shai-Hulud 2.0 chama o instance metadata service (IMDS) de AWS, Azure e GCP para roubar credenciais temporárias de workload — incluindo serverless e containers (ECS, Cloud Functions).

IMDS só existe dentro de instância cloud ou runner CI/CD, NÃO em estação de dev. Hoje o BLAST-RADIUS é uma ferramenta de estação de dev.

Decisão estratégica

Ataques de supply chain frequentemente comprometem o RUNNER CI/CD, não só a estação. Se o BLAST-RADIUS expandir escopo para coletar em runner comprometido, cobre o vetor de propagação completo do Shai-Hulud.

Opções:

1. Manter escopo só estação de dev — IMDS fora de escopo
2. Adicionar modo --ci-runner\ que coleta IMDS workload credentials quando executado dentro de instância cloud

Se implementar

• Detectar se está rodando em instância cloud (presença de IMDS endpoint)
• AWS: \http://169.254.169.254/latest/meta-data/iam/security-credentials/\
• Azure: \http://169.254.169.254/metadata/identity/oauth2/token\
• GCP: \http://metadata.google.internal/computeMetadata/v1/\
• Reportar como \workload_credential\ tier REVOGAR AGORA

Prioridade

PRIORIDADE 2 — alto valor SE o escopo incluir CI/CD. Requer decisão de produto primeiro.

Referência

Datadog: IMDS calls em AWS/Azure/GCP para workload credentials (VM, serverless, containers).