Los clientes de GitHub Team pueden iniciar desde el 30 de septiembre pruebas autoservicio de GitHub Advanced Security para evaluar GitHub Code Security y GitHub Secret Protection. La nueva opción permite probar estas capacidades sin tener que iniciar primero un proceso comercial para un plan superior, según el changelog oficial de GitHub.
Qué se puede evaluar durante la prueba
GitHub señala dos bloques principales: Code Security, orientado a detectar vulnerabilidades en el código y dependencias, y Secret Protection, diseñado para localizar credenciales y secretos expuestos. Para una pyme de software, esto permite medir cuánto riesgo adicional aparece al activar controles que no formaban parte de su flujo habitual.
La prueba puede iniciarse desde la página Overview de la organización, desde Billing and licensing > Licensing o después de completar una evaluación de riesgo.
Qué debería medir una empresa durante el trial
El objetivo no debería ser únicamente contar alertas. Conviene medir cuántos hallazgos son realmente accionables, tiempo necesario para corregirlos, repositorios con mayor concentración de riesgo y esfuerzo adicional para los desarrolladores.
En Secret Protection, resulta especialmente útil comprobar si existen claves de API, tokens o credenciales históricas en repositorios y si el proceso de revocación está claro. Detectar un secreto sin retirarlo del sistema donde sigue siendo válido no resuelve el riesgo.
Cómo organizar una prueba útil
Una pyme puede seleccionar uno o dos repositorios representativos en lugar de activar todo de golpe. Debe incluir al menos un proyecto con dependencias externas, automatizaciones CI/CD y secretos gestionados por variables de entorno. Después puede comparar alertas con las herramientas que ya utiliza.
También conviene definir de antemano quién recibe cada tipo de alerta y qué plazo interno existe para vulnerabilidades críticas, altas y medias. Sin ese proceso, una herramienta adicional puede terminar generando más ruido que reducción de riesgo.
Qué decisión tomar al terminar
La empresa debería comparar coste, cobertura y carga operativa frente a su stack actual. Si Advanced Security sustituye varias herramientas dispersas, la decisión puede justificarse por simplificación; si duplica controles ya existentes, el valor debe medirse en precisión o integración.
Para reforzar la misma cadena de desarrollo pueden revisarse también la actualización de GitHub CodeQL, el proof of presence, las métricas de revisión, las propiedades externas de repositorios, el parche crítico de GitLab y la adopción de passkeys empresariales.
GitHub no plantea el trial como un cambio automático de licencia permanente. La prueba sirve para generar evidencia sobre cobertura y carga operativa antes de contratar. En una empresa con varios repositorios, conviene dejar por escrito qué métricas decidirán la continuidad: vulnerabilidades únicas detectadas, secretos revocados, tiempo de remediación y reducción de herramientas solapadas.
Fotografía: Lukas Blazek / Pexels.
