---
title: "Shopify cria Overexposed para detectar exposição no Kubernetes"
author: "Ignácio Afonso"
date: "2026-11-03 06:27:44.176-03"
category: "Segurança & Privacidade"
url: "http://desbugados.scale.press/portal/desbugados/post/2026/11/03/shopify-cria-overexposed-para-detectar-exposicao-no-kubernetes/md"
---

## Resumo
- A Shopify criou o Overexposed para localizar serviços expostos à internet sem autenticação.
- O scanner verifica Ingresses do Kubernetes no GKE e serviços do Cloud Run.
- A ferramenta combina o GCP Cloud Asset Inventory com sondagens HTTP anônimas.
- Os resultados são classificados em seis vereditos, incluindo exposto, protegido e inconclusivo.
- A nova abordagem reduziu os vereditos inconclusivos em cerca de 80%.
- O scanner usa validações contra SSRF, DNS rebinding e endereços privados.
- Evidências incertas permanecem inconclusivas para evitar falsos negativos de segurança.

---

Uma requisição HTTP anônima pode ser a diferença entre um serviço protegido e uma porta aberta na internet. Para reduzir esse espaço de dúvida, a [**Shopify**](https://shopify.engineering/overexposed) criou o **Overexposed**, um scanner interno para identificar serviços expostos à internet sem autenticação. Ele localiza Ingresses do Kubernetes no GKE e serviços do Cloud Run, tornando visível uma camada que costuma ficar escondida atrás de arquivos de configuração. A mudança importa porque o ponto de referência passou a ser o que a nuvem realmente mantém ativo.


## Da intenção ao que está no ar


Essa mudança nasceu de uma falha prática: a versão original do scanner, baseada em arquivos de configuração dos repositórios, não refletia o que era efetivamente aplicado nos clusters. A análise do [**InfoQ**](https://www.infoq.com/news/2026/11/shopify-kubernetes-ingresses) descreve essa diferença como um descompasso entre intenção e execução. Ao trocar esse retrato parcial por uma leitura do inventário de nuvem e por sondagens ativas, a nova versão reduziu os vereditos inconclusivos em cerca de **80%**, segundo a publicação. A história, aqui, não é de desprezo pelo código antigo: é a constatação de que configuração escrita e configuração aplicada podem contar histórias diferentes.


Com essa lente, o **GCP Cloud Asset Inventory** funciona como o ponto de partida para localizar os recursos, enquanto as sondagens HTTP anônimas verificam como esses serviços respondem de fora. O sistema organiza cada resultado em seis vereditos: exposto, esperado, protegido, não encontrado, inacessível e inconclusivo. Também há uma lista de permissões, ou allowlist, para registrar acessos públicos legítimos e evitar que sejam tratados como falhas. O ganho prático está em separar uma exceção conhecida de uma exposição que ninguém pretendia deixar aberta.


## Verificar sem abrir outra porta


Essa verificação ativa exige cuidado porque o próprio scanner faz requisições aos serviços encontrados. O Overexposed começa com uma requisição **HEAD**, segue com uma **GET** quando necessário, limita os redirecionamentos a três e testa variações de caminhos, como **/ADMIN**. A lógica procura sinais que uma simples leitura de configuração não mostraria, mas precisa impedir que um endereço controlado por terceiros seja usado para alcançar a rede interna. Por isso, a ferramenta valida DNS e endereços IP antes de conectar.


Essa camada de proteção foi desenhada contra **SSRF**, quando um serviço é induzido a fazer requisições para destinos que o atacante não deveria alcançar, e contra DNS rebinding, técnica que tenta trocar o destino depois da validação. O scanner rejeita endereços privados e de loopback e se conecta diretamente ao IP validado, em vez de confiar novamente na resolução do nome durante um redirecionamento. Piada ruim do plantão: se um endpoint está exposto, pelo menos ele já fez seu networking. Eu avisei que era ruim. A regra que fica é mais séria: o repositório registra a intenção, mas o cluster mostra a aplicação real; quando a evidência não basta, o resultado permanece **inconclusivo** para evitar um falso negativo de segurança.