Как ПриватБанк построил безопасную среду для тысячи разработчиков вместе с GitLab и Cloudfresh

ПриватБанк — один из крупнейших банков Восточной Европы. А с точки зрения технологий это еще и одна из крупнейших IT-организаций в Украине.

Более 80% программного обеспечения, которое используется внутри банка и клиентами, создается собственными командами. При этом банк должен отвечать строгим требованиям безопасности, комплаенса, стабильности и контроля изменений. Поэтому команда искала платформу, которая позволит стандартизировать разработку во всей организации.

Раньше инструменты были разрознены: Jenkins использовался для CI, код хранился в других системах, а процессы были распределены между разными платформами.

Это создавало проблемы:

• Отсутствие единой среды
• Разные стандарты разработки
• Низкая прозрачность процессов

Поэтому банк начал постепенно переходить к единой DevSecOps-платформе.

Почему GitLab?

Примерно за последние 1,5–2 года GitLab был утвержден как стандарт платформы разработки в банке. И не только для хранения кода. GitLab стал основой для управления проектами, CI/CD, безопасности кода, контроля изменений, аудита и комплаенса.

В ПриватБанке GitLab стал ядром DevSecOps-процесса.

Dev: Стандартизированная разработка и единый воркфлоу

Для ПриватБанка ключевым вызовом было не просто хранить код, а выстроить единый подход к разработке для всей организации.

Когда в компании работают сотни инженеров и десятки команд, даже небольшие различия в процессах могут создавать хаос: разные инструменты, разные правила работы с кодом и разные подходы к ревью. Именно поэтому банк начал использовать GitLab как единую платформу разработки, объединяющую все ключевые этапы работы с кодом:

В результате разработчик видит весь процесс в одной среде — от первого коммита до доставки изменений в систему.

Code review как стандарт инженерной культуры

Одним из ключевых изменений стало то, что GitLab лег в основу внутреннего стандарта разработки в банке. Любое изменение в коде проходит через merge request workflow. Когда разработчик создает мердж-реквест, другие инженеры проверяют изменения. Во время review команда может:

• Проверить соответствие стандартам кода
• Обратить внимание на потенциальные проблемы
• Предложить лучшие архитектурные решения
• Убедиться, что код соответствует требованиям безопасности

Вся история изменений сохраняется в системе, поэтому в любой момент можно понять, как развивался код и почему были приняты те или иные решения.

Для крупной организации это особенно важно: GitLab делает процесс review прозрачным и автоматизированным даже для распределенных команд. В результате code review становится механизмом повышения качества кода.

Гибкость разработки в масштабах банка

Еще один важный аспект для ПриватБанка — возможность работать над разными задачами параллельно.

В банковских системах наряду с долгосрочными проектами часто нужно быстро реализовать срочные изменения — например, новые регуляторные требования. Именно поэтому команды активно используют в GitLab гибкую модель работы с ветками. Это позволяет одновременно работать над разными типами задач:

• Долгосрочными функциональными разработками
• Критическими срочными изменениями
• Экспериментальными или исследовательскими проектами

На практике это означает, что команда может создать отдельную ветку для срочного изменения, реализовать ее и доставить в production, не останавливая работу над крупным проектом.

Infrastructure-as-Code и понятная архитектура

Не менее важный принцип инженерной практики банка — описание инфраструктуры вместе с кодом. Такой подход позволяет командам работать с системой как с целостной средой, а не только с отдельными фрагментами кода.

Когда новый инженер присоединяется к команде, он получает полный контекст системы:

• Документированный код
• Описанную архитектуру
• Понятную структуру компонентов

Это существенно упрощает онбординг и позволяет быстрее приступить к работе над проектом. Кроме того, GitLab позволяет запускать отдельные ветки для тестирования изменений. Разработчик может внести правки, развернуть их в собственной среде и сразу увидеть результат — без ожидания общей сборки системы.

Для организации масштаба ПриватБанка это заметно сокращает время между созданием и проверкой новых функций.

Sec: Безопасность как часть процесса разработки

Для финансового учреждения безопасность не может быть отдельным этапом после написания кода, поэтому в ПриватБанке её интегрировали непосредственно в процесс разработки. Когда разработчик создает новую функцию или добавляет библиотеку, в ходе пайплайна запускаются инструменты анализа безопасности еще до того, как изменения попадают в общий репозиторий.

В частности, банк использует в GitLab такие механизмы проверки:

• SAST — анализ исходного кода на потенциальные уязвимости
• Dependency scanning — проверка сторонних библиотек
• Vulnerability scanning — обнаружение известных рисков в зависимостях

Эти проверки работают прямо в CI/CD pipeline. Поэтому команда видит проблемы еще до того, как код попадает даже в тестовую среду.

Как объясняют в банке, ключевое изменение заключается в том, что разработчик получает обратную связь сразу. Если библиотека содержит уязвимость или не соответствует политикам организации, система сообщает об этом еще на этапе работы с кодом.

Это кардинально меняет сам цикл разработки. Раньше он выглядел примерно так:

1. Разработчик пишет код
2. Делает commit
3. Запускается сборка
4. Происходит проверка
5. Выявляется проблема
6. Код нужно переделывать и запускать цикл заново

Теперь часть этих повторяющихся шагов просто исчезает. Инженер видит проблему сразу и исправляет ее в момент работы с кодом.

По оценке команды, это позволило убрать несколько повторяющихся итераций проверки и сэкономить примерно 15–25% времени, которое раньше тратилось именно на такие циклы. Но для ПриватБанка самым важным результатом стала не скорость. Самым важным стало качество кода. Когда проверки интегрированы в процесс разработки, инженеры начинают писать код иначе. Они сразу учитывают требования безопасности, стандарты организации и архитектурные правила. В итоге код, который проходит в систему, с первого раза соответствует внутренним политикам.

Это приводит к нескольким важным изменениям:

Контроль open source и лицензий

Еще один важный аспект для банка — контроль open-source-компонентов.

Разные лицензии могут накладывать серьезные ограничения:

• Требовать открытия собственного кода
• Создавать юридические конфликты
• Приводить к штрафам или репутационным проблемам

Для организации масштаба ПриватБанка контроль таких рисков вручную практически невозможен, поэтому банк автоматизировал этот процесс с помощью GitLab.

Во время CI/CD pipeline система формирует Software Bill of Materials (SBOM) — полный список компонентов, входящих в состав программного продукта. Для этого используются индустриальные стандарты CycloneDX и SPDX. На основе этой информации команда банка настраивает собственные политики использования open source.

Это означает, что система автоматически:

• Определяет лицензии зависимостей
• Проверяет их на соответствие внутренним правилам
• Уведомляет разработчика о возможных нарушениях

Если новая библиотека не соответствует политикам организации, разработчик получает сигнал прямо во время merge request. Он может либо получить необходимое согласование, либо сразу выбрать другую зависимость. Таким образом, контроль лицензий перестает быть отдельным процессом, который происходит после разработки. Он становится естественной частью workflow инженера.

Полная прозрачность изменений и аудит

Для финансового учреждения не менее важным является контроль изменений в коде. Любое изменение должно быть отслеживаемым и понятным. Именно поэтому в GitLab ПриватБанк использует механизмы политик и контроля доступа, которые позволяют регулировать процесс внесения изменений.

В частности, команда настроила:

• Политики одобрения для критических изменений
• Обязательное рецензирование запросов на слияние
• Ограничения на commit для определенных ролей
• Полный аудиторский след всех изменений

Это значит, что в любой момент банк может ответить на три ключевых вопроса: кто внес изменение в код, кто его проверил и утвердил, и почему оно попало в релиз.

Для крупной финансовой организации такая прозрачность критична. Она позволяет оперативно проводить внутренние аудиты, анализировать инциденты и обеспечивать соответствие регуляторным требованиям.

В результате безопасность перестает быть отдельной функцией или процессом, который контролирует только специальная команда. Она становится неотъемлемой частью повседневной работы инженеров, интегрированной в саму платформу разработки.

Ops: Контролируемая доставка изменений

В среде, где десятки команд ежедневно меняют сотни систем, написать код — лишь половина задачи. Не менее важно, как этот код доставляется в систему. Любое изменение должно проходить четко контролируемый путь — от коммита до продакшена.

После того как GitLab был утвержден как стандарт платформы разработки, команда создала внутренние правила работы с CI/CD. В банке даже появились отдельные положения, определяющие, как должны строиться пайплайны и как команды должны работать с доставкой кода.

Большинство проектов сегодня используют GitLab CI/CD как основной механизм автоматизации. Это позволило стандартизировать процессы сборки, тестирования и доставки изменений в разных командах. При этом пайплайны остаются достаточно гибкими, чтобы учитывать специфику различных систем. В CI/CD-процессы банк интегрирует не только стандартные возможности GitLab, но и собственные инструменты контроля качества и безопасности.

В частности, в pipeline могут подключаться:

• Внутренние инструменты безопасности
• Собственные SAST-сканеры
• Проверки соответствия технологическим стандартам банка

Такой подход позволяет объединить автоматизацию GitLab с внутренними механизмами контроля, которые банк разрабатывал годами.

Работа с legacy-системами

Отдельный вызов для крупной финансовой организации — наличие значительного количества legacy-систем. Многие из них создавались еще до появления современных DevOps-практик и не всегда легко интегрируются в стандартные процессы автоматизации. Полностью перестроить такие системы за короткое время практически невозможно.

Поэтому команда банка использовала гибкость GitLab, чтобы постепенно интегрировать и эти системы в CI/CD-процесс. Даже если отдельные этапы для legacy-проектов остаются частично ручными, GitLab позволяет выстроить вокруг них контролируемый pipeline. Это означает, что:

• Все изменения проходят через единый процесс сборки
• Результаты проверок сохраняются в системе
• История релизов остается прозрачной

В конечном счете даже старые системы становятся частью единого инженерного процесса банка.

Меньше ручной работы — больше контроля

Для команды ПриватБанка главная ценность CI/CD заключается не только в скорости релизов. Важнее то, что доставка кода становится предсказуемым и контролируемым процессом.

Когда pipeline автоматизирует проверки и сборку системы, команды могут быть уверены, что каждое изменение проходит одинаковые этапы. Это снижает риск ошибок и делает процесс релизов более стабильным. В сочетании с механизмами Dev и Sec это создает единую модель работы:

• Код проходит стандартизированное ревью
• Автоматически проверяется на уязвимости
• Доставляется через контролируемый pipeline

Таким образом, GitLab помог ПриватБанку построить полноценный DevSecOps-процесс, где разработка, безопасность и операционные процессы работают как единая система.

Качество кода как главная метрика успеха

В ПриватБанке результаты внедрения GitLab оценивают не отдельными показателями скорости, а тем, какой код в итоге получает организация.

Это меняет не только технический процесс, но и работу команд. Инженеры тратят меньше времени на поиск проблем в production и больше — на развитие продуктов.

Еще один важный эффект — более быстрый онбординг новых разработчиков. Когда код структурирован, задокументирован и проходит стандартизированные проверки, новым инженерам значительно легче погружаться в проекты.

Масштаб инженерной организации

Чтобы понять, почему стандартизация процессов настолько важна, достаточно взглянуть на масштаб разработки в ПриватБанке. Сегодня GitLab используется для работы над сотнями систем и тысячами компонентов. В частности:

• 700+ внутренних и внешних платформ
• 1 000 разработчиков, работающих одновременно
• Десятки команд, работающих в режиме 24/7

И этот масштаб хорошо виден не только на уровне организации, но и в ежедневной работе с платформой. Только за последние два месяца в GitLab-среде ПриватБанка:

На таком масштабе любое отсутствие стандартов быстро превращается в серьезную проблему. Именно поэтому централизация процессов разработки стала одним из ключевых факторов успеха.

Стабильность платформы

GitLab в ПриватБанке работает в self-hosted среде, что позволяет полностью контролировать инфраструктуру и отвечать требованиям безопасности финансового учреждения.

По словам команды банка, платформа демонстрирует очень высокий уровень стабильности.

Для организации, где тысячи инженеров работают с кодом ежедневно, это критически важный фактор. Надежность платформы означает, что команды могут сосредоточиться на развитии продуктов, не тратя время на решение инфраструктурных проблем.

Партнерство с Cloudfresh

Переход ПриватБанка на коммерческую версию GitLab происходил в сотрудничестве с Cloudfresh — официальным партнером GitLab в Центральной Азии.

Команда Cloudfresh сопровождает банк в нескольких ключевых направлениях: от лицензирования платформы до поддержки инженерных команд при масштабировании DevSecOps-процессов.

В частности, сотрудничество включает:

• Консультации по лицензированию и оптимальной модели использования GitLab
• Техническую экспертизу при внедрении новых возможностей платформы, таких как Duo Agent Platform
• Поддержку инженерных команд при работе с GitLab
• Помощь в решении технических вопросов

Для крупной организации, где тысячи инженеров работают с платформой ежедневно, важно иметь доступ к экспертизе и оперативной поддержке.

Такой формат сотрудничества позволяет ПриватБанку не только поддерживать стабильную работу платформы, но и постепенно расширять ее использование. Вместе с Cloudfresh команда банка тестирует новые возможности GitLab и внедряет их в свои инженерные процессы.

ИИ-подход к разработке

Следующий этап развития платформы — интеграция ИИ-инструментов в процесс разработки. Команда уже тестирует новые IDE и ИИ-агентов, а также экспериментирует с возможностями GitLab Duo Agent Platform.

Среди потенциальных направлений использования:

• Автоматическая проверка качества кода
• Анализ соблюдения стандартов технологического стека
• Оптимизация CI/CD-процессов
• Дополнительная поддержка инженеров при написании кода

Пока эти возможности используются в пилотных сценариях, но команда банка активно исследует, как интегрировать ИИ в повседневный workflow разработчиков.

В результате GitLab стал для ПриватБанка не просто системой для хранения кода. Платформа объединила разработку, безопасность и операционные процессы в единую инженерную систему, которая позволяет и дальше масштабироваться одной из крупнейших финансовых организаций страны.