GitHub quiere reducir el ruido de los avisos de seguridad de baja calidad y los reportes generados automáticamente. Desde el 1 de octubre, los informes privados de vulnerabilidades pueden utilizar un formulario estructurado que obliga a aportar más contexto antes de enviar un hallazgo.
Según el changelog oficial de GitHub, el formulario predeterminado exige cuatro campos: resumen, detalles, prueba de concepto y impacto. La prueba de concepto debe tener al menos 150 caracteres.
Menos reportes vacíos y más información accionable
Hasta ahora, un único campo de texto libre facilitaba que llegaran avisos difíciles de reproducir o con poca información. El nuevo formato busca que el equipo de seguridad pueda evaluar antes si existe una vulnerabilidad real y qué prioridad merece.
Las organizaciones pueden personalizar el formulario mediante un archivo .github/VULNERABILITY_REPORT.yml y aplicar la configuración a varios repositorios desde el repositorio .github de la organización. También es posible exigir que el investigador asigne una CWE y mostrar previamente la política SECURITY.md.
La actualización encaja con la ampliación de GitHub Advanced Security a pruebas para organizaciones con plan Team, que acerca controles de seguridad a más equipos de desarrollo.
GitHub incluye una declaración sobre uso de IA
Los investigadores pueden marcar si utilizaron asistencia de inteligencia artificial para encontrar o redactar el informe. La casilla no invalida el reporte, pero aporta contexto al mantenedor en un momento en el que los proyectos reciben cada vez más contenido automatizado.
GitHub también está incorporando IA en el propio ciclo de desarrollo. La compañía ha llevado HydraFusion a VS Code para coordinar varios modelos en una misma tarea, por lo que la plataforma está intentando combinar automatización con controles que mantengan la calidad del trabajo.
Qué deberían hacer los responsables de repositorios
Los equipos que aceptan private vulnerability reports deberían revisar su formulario por defecto y decidir si necesitan campos adicionales para su producto. En software empresarial puede ser útil pedir versión afectada, entorno, pasos exactos de reproducción y alcance del impacto.
También conviene alinear esta política con el resto de la automatización. GitHub ha cambiado recientemente la retención de checks y ejecuciones de Actions y ha actualizado Actions Runner Controller para operar flotas de runners en Kubernetes.
En repositorios privados, Dependabot ya permite elegir runners específicos por repositorio, otra pieza que afecta directamente a la arquitectura de seguridad y CI/CD.
La seguridad del repositorio se vuelve más gobernable
Para empresas con muchos proyectos, la tendencia es clara: GitHub está trasladando más decisiones de seguridad desde procesos manuales hacia configuraciones centralizadas y políticas. La plataforma ya permite sincronizar ownership, criticidad y compliance desde un CMDB.
El nuevo formulario no elimina los falsos positivos, pero sube el nivel mínimo de información que recibe el mantenedor. Para pymes de software y equipos internos de TI, eso puede reducir tiempo de triage y ayudar a concentrarse en vulnerabilidades que realmente pueden reproducirse y corregirse.
