Начнем с самого начала – что же такое Quality Gate, Security Quality Gate, QG? По своей сути, Quality Gate – это набор критериев, по которым оценивается качество кода перед его развертыванием в рамках процесса непрерывной интеграции и доставки (т.н. CI\CD).
Чем полезен Quality Gate? Он помогает командам разработки убедиться, что заданные стандарты качества кода соблюдаются, и в продакшн среду не попадает код, несоответствующий заданным уровням (в нашем случае речь, конечно, про объем уязвимостей).
Небольшое отступление: в мире разработки также есть термин Release Gate. Его основная цель – контроль функциональности кода, будь то время отклика или количество единовременных запросов к базе. Quality- и Release Gate могут быть объединены в один шаг, могут быть в нескольких итерациях в рамках одного пайплайна разработки, но, это, как говорится, уже совсем другая история.
Вернемся непосредственно к Quality Gate. Что заставляет команды задуматься о необходимости его внедрения? Ответ на поверхности – автоматизация. Но если копнуть чуть глубже, здесь речь идет о:
- Увеличении частоты релизов: быстрые релизы требуют более строгого контроля качества.
- Сложности кода: новые технологии и фреймворки требуют более тщательной проверки.
- Снижении количества ошибок: Quality Gate помогает выявлять ошибки на ранних стадиях разработки.
- Улучшении командной работы: чёткие критерии качества помогают всем членам команды понимать общие цели.
В совокупности, Quality Gate помогает избежать появления недопустимых уязвимостей в коде, и, как следствие, кратно снизить риски, в том числе финансовые.
Как реализовать QG
Популярным способом является внедрение Quality Gate как отдельного шага в пайплайне сборки/деплоя. Настраивается политика, где прописываются конкретные объемы уязвимостей по каждой степени критичности. Превышение этих объемов = непройденный Quality Gate. Либо, можно сделать изящнее, добавив вес для каждой степени критичности. Таким образом получится не пропустить релиз с уязвимым кодом, даже если в нем номинально отсутствуют уязвимости с наивысшей критичностью. В общем смысле механизм следующий: запускается сканирование – результаты формируются и считаются, а затем сравниваются с граничными значениями.
У такой реализации есть свои преимущества:
- Понятная логика, понятный механизм работы.
- Легко интегрируется и централизуется, если в организации реализован шаблонный деплой (джоба Quality Gate конфигурируется в одном месте, остальные пайплайны сборки обращаются к ней), как следствие – повышение качества всех продуктов, а не каких-то отдельных.
- Гибкость в настройке действия при непрохождении Quality Gate. Согласно политике организации, это могут быть, например, уведомление или блокировка сборки.
Из минусов стоит выделить:
- Повышенные требования к компетенциям для реализации.
- Без шаблонного деплоя придется монотонно настраивать Quality Gate в каждом репозитории и так же монотонно отслеживать.
- Желателен мониторинг работы джобы QG а также ограничение прав доступа на её отмену.
Описанный метод реализации может показаться затруднительным, но есть альтернатива: использование механизмов ASOC-платформы для выполнения функции Quality Gate.
Как работает ASOC в качестве QG
ASOC Cybercodereview позволяет использовать интеграцию с системой контроля версий (Gitlab\GitHub) для отслеживания появления уязвимостей.
В рамках созданного merge request автоматически запустится сканирование, которое в комментариях к этому merge request выдаст информацию об уязвимостях. Таким образом, без устранения найденных уязвимостей, такой merge request не попадет в продукт.
Merge request с найденными уязвимостями может быть автоматически закрыт. Так как ASOC в любом случае аккумулирует информацию об уязвимостях, это вынесет процесс триажа из системы контроля версий, при этом оставив блокирующий функционал.
При непрохождении Quality Gate выставляется статус коммита в пайплайне. То есть отдельных шаг в рамках одной джобы, который сигнализирует о сработавшем Quality Gate.
Плюсы такого подхода:
- Минимальные компетенции для внедрения.
- Минимальное время для завершения внедрения.
- Высокая степень покрытия репозиториев.
- Автоматическое добавление Quality Gate к создаваемым репозиториям.
Из минусов можно выделить:
- Отсутствие блокировки сборки/деплоя.
- Подход может не соответствовать политике организации.
- Необходимо дополнительное обучение команды в части корректной работы с таким механизмом.
Вместо заключения
Quality Gate в CI/CD помогает снижать количество ошибок и упрощать процесс разработки, это приводит к снижению затрат на исправление и повышению удовлетворенности пользователей. Выбор конкретного способа реализации остается за командой, в зависимости от степени зрелости и готовности к изменениям. Но, в итоге, любой из способов послужит одной главной цели – повышению качества и безопасности кода.