01 · Contexto
Qué está ocurriendo
GitHub anunció el 29 de octubre nuevos rangos para entregar webhooks desde github.com. La Meta API ya los incluye en el campo hooks: 9.234.98.160/28, 9.234.98.176/28 y 9.234.106.48/28. Quienes mantienen una lista estática de direcciones permitidas deben agregarlos junto a los existentes para evitar rechazar entregas. El cambio alcanza todos los planes, incluido GitHub Enterprise Cloud.
El anuncio aclara que no hace falta actuar por estas adiciones cuando la lista ya se mantiene actualizada mediante la Meta API. No se trata de reemplazar todos los rangos previos, migrar el receptor ni cambiar sus credenciales. También es un cambio distinto de los destinos de almacenamiento o la infraestructura de ejecución de GitHub Actions: aquí se habla de tráfico entrante hacia los receptores de notificaciones.
Las prácticas oficiales de GitHub recomiendan usar un secreto para comprobar las entregas, conservar HTTPS y la verificación de certificados, procesar solo los eventos necesarios y revisar su tipo y acción. También indican responder oportunamente y considerar colas para trabajo posterior. Son controles del receptor que siguen siendo relevantes después de actualizar una regla de red.
02 · Impacto
Por qué importa
Como análisis, un filtro de red desactualizado puede parecer un problema de la aplicación: dejan de llegar avisos, no se inicia una integración y el equipo busca errores donde el código no cambió. Sin embargo, resolver la conectividad abriendo indiscriminadamente el acceso crea un problema distinto. Una lista de direcciones permitidas y la validación de la carga útil cumplen funciones complementarias. El origen de red admitido no basta para decidir qué acción puede ejecutar un evento. Esta separación resulta especialmente importante cuando una notificación inicia una compilación, actualiza un ticket o activa otro proceso automatizado.
03 · Recomendaciones
Qué conviene hacer
- Como recomendación, identifique qué receptores dependen de listas estáticas y quién administra su ingreso de red. Compare su configuración con el campo hooks actual, documente la diferencia y tramite un cambio acotado. No copie rangos de otros servicios por semejanza ni sustituya una lista específica por una autorización amplia de tráfico.
- Después del cambio, pruebe una entrega controlada y siga su recorrido hasta el resultado esperado, no solo hasta una respuesta HTTP exitosa. Revise registros de rechazo, validación del secreto y manejo de duplicados. Si hubo interrupciones, evalúe las entregas pendientes antes de reenviarlas para evitar efectos repetidos. Mantenga un procedimiento periódico de actualización con responsable y evidencia, aunque la obtención de rangos esté automatizada.