Эта статья является частью серии "Внедрение GitHub Advanced Security в большом масштабе". Предыдущие статьи в этой серии см. в разделе "Этап 3. Пилотные программы".
Перед включением GitHub Advanced Security необходимо создать внутреннюю документацию, которая будет определять процессы для команд. Все должны знать, что делать, когда они получают оповещение системы безопасности, даже если процесс просто просит команду принять максимально верное решение. Документация также предотвратит блокировку работы разработчиков при наличии вопросов. Необходимо поместить документацию по GHAS в существующую документацию, ориентированную на разработчиков, например на портал разработчиков или в собственную базу знаний.
Если вы запустили пилотные программы, используйте опыт и отзывы от команд, участвующих в них, чтобы скорректировать документацию. Это особенно полезно, если вы столкнулись с проблемами, специфичными для вашей компании, так как другие команды, скорее всего, тоже с ними столкнутся.
Если вы пропустите этап создания внутренней документации, развертывание не будет выполняться в нужном темпе. Создание внутренней документации может замедлить первоначальное развертывание на одну-две недели, но это время будет восполнено, когда разработчики смогут сами отвечать на свои вопросы, а не обращаться к вашей команде.
Обучение, вероятно, является наиболее важной частью развертывания, как оно учит разработчиков, что делать в различных ситуациях. Вы должны убедиться, что разработчики способны поддерживать безопасность своего репозитория, а группа безопасности уполномочена проверять как то, что делают разработчики, так и то, что это отвечает интересам безопасности. Помимо внутренней документации, образование может принимать форму онлайн-сеансов, Q&As и т. д.
В следующей статье этой серии см. раздел "Этап 5. Развертывание и масштабирование проверки кода".