Este artículo forma parte de una serie sobre la adopción de GitHub Advanced Security a escala. Para ver el artículo anterior de esta serie, consulta "Fase 3: Programas piloto".
Antes de habilitar GitHub Advanced Security, debes crear documentación interna que defina los procesos que deben seguir los equipos. Todos necesitan saber qué hacer cuando reciben una alerta de seguridad, incluso si el proceso simplemente pide al equipo que aplique su mejor criterio. La documentación también impedirá que los desarrolladores se bloqueen cuando tengan preguntas. Debes colocar la documentación sobre GHAS con la documentación existente dirigida a los desarrolladores, como el portal para desarrolladores o la knowledge base personalizada.
Si has ejecutado programas piloto, usa las experiencias y los comentarios de los equipos implicados en esos pilotos para generar la documentación. Esto es especialmente útil si has encontrado problemas específicos de tu empresa, que es probable que otros equipos también encuentren.
Si omites la creación de documentación interna, el lanzamiento no irá al ritmo previsto. La creación de documentación interna puede ralentizar el lanzamiento inicial en una o dos semanas, pero ese tiempo quedará compensado cuando los desarrolladores puedan responder a sus propias preguntas en lugar de acudir a tu equipo.
La formación probablemente es la parte más crucial del lanzamiento, ya que enseña a los desarrolladores qué hacer en diferentes situaciones. Debes asegurarte de que los desarrolladores estén capacitados para mantener la seguridad de su repositorio y que el equipo de seguridad esté autorizado para comprobar lo que hacen los desarrolladores y que esto sea lo mejor para la seguridad. Además de la documentación interna, la formación puede adoptar la forma de sesiones en línea, preguntas y respuestas, etc.
Para ver el siguiente artículo de esta serie, consulta "Fase 5: Lanzamiento y escalado del análisis de código".