Questão de Engenharia de Software — Github e Gitlab — FCC 2025

Webhooks e Segurança em CI/CD

Gabarito: letra E. O problema descrito é uma falha de validação da mensagem no endpoint do webhook — o servidor não conseguiu confirmar que a mensagem recebida era legítima e íntegra. A solução técnica correta é habilitar a verificação de assinatura (usando um token secreto compartilhado), que permite ao endpoint validar a autenticidade e a integridade de cada mensagem recebida, rejeitando requisições forjadas ou adulteradas. As demais alternativas tratam de infraestrutura de rede (proxy, SSL, balanceamento) ou de diagnóstico (logs), que não resolvem a causa raiz: a ausência de um mecanismo de validação criptográfica da mensagem.

Um webhook é um mecanismo de notificação automática em que um sistema (no caso, o GitLab) envia uma requisição HTTP para uma URL pré-configurada (o endpoint) sempre que um evento específico ocorre — aqui, um push para o branch main. O endpoint, por sua vez, processa a mensagem e dispara o pipeline de CI. A grande vulnerabilidade desse modelo é que qualquer pessoa que descubra a URL do endpoint pode enviar requisições falsas, simulando eventos que não ocorreram ou adulterando o conteúdo da mensagem. Para mitigar esse risco, os provedores de webhook (GitHub, GitLab, etc.) implementam um mecanismo de assinatura de mensagem: o remetente calcula um hash da mensagem (geralmente HMAC-SHA256) usando um token secreto que é compartilhado apenas entre o remetente e o destinatário. O destinatário, ao receber a mensagem, recalcula o hash com o mesmo token e compara com o valor recebido. Se forem iguais, a mensagem é autêntica e íntegra; se não, a mensagem é rejeitada.

No cenário da questão, o endpoint "não conseguiu validar a mensagem enviada" — ou seja, ou o token não estava configurado, ou a verificação de assinatura não estava habilitada, ou o token configurado no endpoint não correspondia ao token configurado no GitLab. A solução é justamente habilitar o recurso de verificação de assinatura e garantir que o token secreto esteja corretamente configurado em ambos os lados. Isso não apenas resolve o problema imediato, mas também protege o pipeline contra requisições maliciosas, um requisito fundamental de segurança em ambientes de integração contínua.

É importante distinguir a verificação de assinatura de outras medidas de segurança de rede. O SSL/TLS (alternativa B) protege a comunicação em trânsito contra interceptação e adulteração por terceiros, mas não valida a identidade do remetente — qualquer um pode enviar uma requisição HTTPS para o endpoint. O proxy reverso (alternativa D) e o balanceador de carga (alternativa C) são componentes de infraestrutura que melhoram a disponibilidade, o desempenho e o diagnóstico, mas não adicionam nenhuma camada de validação de conteúdo. A API reversa (alternativa A) é um termo vago e não corresponde a uma prática padrão para esse fim. A verificação de assinatura, por outro lado, é a única solução que ataca diretamente o problema de validação da mensagem, garantindo que apenas requisições legítimas do GitLab sejam processadas.

Guarde este critério: quando o problema for validação de mensagem em webhooks, a resposta é sempre verificação de assinatura com token secreto. As alternativas de infraestrutura (proxy, SSL, balanceamento) resolvem problemas de disponibilidade, criptografia ou diagnóstico, mas não de autenticidade. É exatamente essa distinção que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Configurar uma "API reversa" para verificar e redirecionar mensagens não é uma prática padrão nem resolve o problema de validação. O termo "API reversa" não corresponde a um componente de infraestrutura reconhecido para esse fim. A validação de mensagens de webhook é feita no próprio endpoint, com verificação de assinatura, e não por redirecionamento para um endpoint alternativo.

Alternativa B — ❌ Incorreta

O SSL offloading (ou SSL/TLS) garante a criptografia da comunicação em trânsito, protegendo contra interceptação e adulteração por terceiros. No entanto, ele não valida a identidade do remetente nem a integridade do conteúdo da mensagem. Qualquer pessoa pode enviar uma requisição HTTPS para o endpoint; o SSL não impede que uma mensagem forjada seja processada. A falha descrita é de validação de autenticidade, não de criptografia.

Alternativa C — ❌ Incorreta

O balanceador de carga distribui as requisições entre múltiplos endpoints para melhorar disponibilidade e desempenho. Ele não adiciona nenhuma camada de validação de mensagem. Se o endpoint original não consegue validar a mensagem, um endpoint redundante terá o mesmo problema, a menos que a validação por assinatura seja implementada. O balanceamento resolve problemas de escala e redundância, não de autenticidade.

Alternativa D — ❌ Incorreta

O proxy reverso com logs detalhados é uma ferramenta de diagnóstico e monitoramento. Ele permite visualizar as requisições recebidas e identificar falhas de comunicação, mas não resolve o problema de validação. Os logs ajudam a entender por que a validação falhou, mas não implementam a validação em si. A solução correta é habilitar a verificação de assinatura, não apenas monitorar as falhas.

Alternativa E — ✅ Correta ⟵ GABARITO

Habilitar a verificação de assinatura (usando um token secreto) é exatamente a solução para o problema descrito. O GitLab assina cada mensagem de webhook com um token secreto compartilhado; o endpoint recalcula a assinatura e a compara com a recebida. Se forem iguais, a mensagem é autêntica e íntegra; se não, é rejeitada. Isso garante que apenas mensagens legítimas do GitLab sejam processadas, resolvendo a falha de validação e protegendo o pipeline contra requisições maliciosas.

Gabarito: letra E — habilitar a verificação de assinatura com token secreto para validar a integridade e autenticidade das mensagens do webhook.