Actualidad empresarial BlackHold News
Buscar en BlackHold News
Desarrollador revisando informes privados de vulnerabilidades

GitHub limita los informes privados de vulnerabilidades para frenar el spam automatizado

GitHub ha introducido límites diarios para los private vulnerability reports con el objetivo de reducir el volumen de avisos automatizados o de baja calidad que reciben los mantenedores. El cambio, anunciado el 1 de octubre de 2026, limita cuántos informes nuevos puede enviar una misma cuenta por día y añade controles para que cada repositorio defina su propia política, según el anuncio oficial.

El límite afecta solo a nuevos informes

Cuando un usuario alcanza el máximo diario, GitHub le muestra un mensaje para que vuelva a intentarlo más tarde. Los límites se aplican a la creación de nuevos reports, pero no impiden seguir comentando advisories ya abiertos.

De esta forma, el control busca frenar envíos masivos sin cortar conversaciones legítimas sobre una vulnerabilidad que ya está siendo investigada.

Los administradores pueden fijar un máximo propio

Además del límite global de GitHub, cada administrador puede configurar un máximo diario para su repositorio desde Settings > Advanced Security > Private vulnerability reporting.

También existe una lista de trusted reporters. Los investigadores incluidos en ella quedan exentos del rate limit, lo que permite proteger el repositorio frente a automatismos sin penalizar a investigadores con los que el proyecto trabaja habitualmente.

Disponible en Free, Pro, Team y Enterprise Cloud

La medida se aplica a repositorios públicos que tengan habilitado el private vulnerability reporting y está disponible en GitHub Free, Pro, Team y Enterprise Cloud.

Para pymes que mantienen software abierto, el cambio puede ahorrar tiempo de triaje. Un equipo pequeño puede verse desbordado si recibe decenas de reportes automáticos que describen falsos positivos o problemas sin reproducibilidad suficiente.

Qué conviene configurar ahora

El administrador debería revisar el volumen histórico de reports, definir un límite razonable y crear una lista de investigadores de confianza si trabaja con programas de disclosure recurrentes. El objetivo no es bloquear investigación legítima, sino evitar que el canal privado se convierta en una cola de spam.

Para equipos que gestionan repositorios y seguridad, también conviene revisar los cambios recientes de GitHub sobre code scanning en repositorios inactivos, la retirada de runners macOS 14, la API de merge asíncrono, el nuevo dashboard de GitHub, la alerta de Microsoft sobre Zimbra y el Digital Defense Report 2026.

Fotografía: cottonbro studio / Pexels.

Scroll al inicio