No dia 17 de agosto, o GitHub ficou quase 8 horas fora do ar, impactando severamente a operação global e equipes de desenvolvimento de software nas empresas. Se você é CISO, gestor de GRC ou TPRM, talvez não veja por que prestar atenção nisso. Afinal, foi uma questão técnica e de responsabilidade de times de infraestrutura e DevOps. Só que o relatório oficial do incidente não deixa tão aparente algo muito importante e desconfortável que deveria estar na sua mesa agora.

O que aconteceu?

Na infraestrutura do GitHub havia um código responsável pelo roteamento do tráfego que ela recebia dos usuários, e que estourou sua capacidade durante um pico de demanda. Picos podem acontecer com quaisquer plataformas e normalmente são soluços inconvenientes e sem muito impacto. Este, no entanto, foi efeito de algo autoalimentado, quase que se sabotando.

Parte do problema foi uma falha de configuração deste serviço, mas houve um efeito em cascata com outros componentes: o VS Code e o Copilot, respectivamente um editor de código usado por milhões de desenvolvedores e a IA especializada para escrever código. Tudo isso, incluindo o GitHub em si, é da Microsoft.

Em miúdos: o VS Code e Copilot não conseguiram enviar dados para o GitHub devido ao tal problema da configuração do serviço de roteamento. Ao receber o erro, o lógico é tentar novamente. Entretanto havia um “bug latente”, que não é um bug “recémnascido” daqueles que surgem quando o software é atualizado. É o tipo de bug que existe há um bom tempo mas que fica adormecido até uma situação com condições muito especiais.

O VS Code e Copilot tentavam novamente a cada erro, sem espaço de tempo adequado entre as tentativas e sem limites de vezes. Virou um loop que, em pouquíssimo tempo, aumentou o volume de requisição de tokens de 9 mil para 70 mil requisições por segundo. Lembra muito um ouroboros, a cobra que começa engolindo o próprio rabo até que ela mesma se consuma.

A distração da narrativa

A narrativa fácil nos comentários por aí foi de culpar a IA e o vibe coding. O cenário é popular: código sem cuidado, muitas vezes conduzido por pessoas que sequer são desenvolvedores e assumindo que seus prompts e respostas da IA estão sólidos. É o bode expiatório perfeito: moderno, polêmico e envolve a hype de IA. Apesar de reconhecer que estes problemas existem em algum grau, não foi o caso aqui. Veio de código escrito por engenheiros sênior, em uma plataforma madura, mantida por uma gigante da tecnologia com acesso amplo a recursos e pessoas. Isso deveria preocupar mais que as polêmicas de vibe coding, não menos.

Um relatório de auditoria como o SOC 2 é uma fotografia: mostra que controles formais existiam num momento específico da avaliação. O que aconteceu no GitHub foi um filme e nenhuma auditoria pontual foi desenhada para isso. Bugs latentes sempre existiram, com ou sem IA.

Isso não é novidade nenhuma, mas mudou a velocidade e aí sim o vibe coding contribui: mais código entrando em produção, em menos tempo, com menos gente pedindo explicitamente por resiliência antes de subir o código. A IA não cria o bug latente: ela aumenta o volume de código onde ele pode se esconder.

E por que CISOs, GRC e TPRM deveriam se preocupar com isso?

Como você já deve estar pensando: isso continua sendo uma tarefa dos times técnicos (engenharia, infraestrutura, DevOps etc.) e não sua. Concordo, mas o contexto é importante para você.

Como CISO, você pode ter muita maturidade em seus processos de resposta a incidentes e continuidade operacional. Como responsável por GRC, em seus processos atuais de conformidade regulatória, políticas internas e auditoria. Como responsável por TPRM, em seus processos atuais de classificação de criticidade e questionário de fornecedores.

Entretanto, estes processos não são suficientes para identificar e mensurar riscos de casos como o do GitHub. Ou você duvida que o GitHub ou a Microsoft passariam com luz verde quase perfeita por tudo isso?

O que CISOs, GRC e TPRM podem fazer a respeito?

O ponto prático? Não é papel de CISOs, GRC ou TPRM assistir ao filme, simular a queda, rodar o teste de carga ou executar o game day de continuidade. Mas é seu papel desenhar controles que garantam saber quem faz, com que frequência, e quais evidências precisam gerar para alimentar a análise de risco.

Este caso é muito valioso para que, no seu time e empresa, se responda de forma honesta às seguintes perguntas:

- O risco do seu maior fornecedor (principalmente se for o único) ficar fora do ar por horas está realmente mapeado como crítico, ou você assume que alguém já fez isso mesmo sem nunca ter visto formalizado?

- Alguém testa, na prática, o que acontece se este fornecedor crítico (talvez o único) falhar, ou a confiança está unicamente baseada nas certificações informadas no relatório dele?

- Se acontecer algo assim amanhã, você saberia dizer quem da sua empresa mapeou e pontuou um risco tão alto como esse, e por que ele foi aceito mesmo assim sem testes reais de impacto e um “Plano B”?

Pode ser que não goste das respostas. Isso incomoda, obviamente, porém esse desconforto é também uma excelente oportunidade para que CISOs, GRC e TPRM modernizem seus processos.

A não ser, claro, que você prefira que o próximo incidente crítico (como esse do GitHub) faça estas perguntas por você.

‍
Ricardo Costa

CAISO e Diretor Regional

‍