1 месяц, 1 команда и сокращение расходов в 30 раз: как мы разработали и внедрили свой ASOC в Банке

⭐ Участник Продуктовой Премии Tproger 2025

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

ОТП Банк спроектировал и внедрил систему, которая применяет различные практики подходов оценки безопасности DevSecOps при создании каждого Pull Request — ещё до слияния с основной веткой.

За месяц команда опытных инженеров спроектировала систему, а потом в течении 1 года и внедрила систему, которая снизила затраты на устранение проблем безопасности до 30 раз и существенно разгрузила нагрузку с команд разработчиков.

* согласно IBM Cost of a Data Breach Report и NIST Guide for Conducting Risk Assessments

Задача: найти уязвимости до их попадания в продакшен

Бизнес-задача — снизить репутационные риски компании и операционные затраты на исправление проблем информационной безопасности. Чем позже находится уязвимость, тем дороже её устранение: если баг в коде пропустили на этапе разработки, его обнаружат уже в продакшене, когда придётся откатывать релизы и экстренно патчить систему.

Техническая задача — создать автоматический сканер по всем практикам DevSecOps, который выявляет проблемы безопасности на самом раннем этапе: при создании Pull Request для слияния с основной веткой репозитория. Система должна работать независимо от платформы, выдерживать повышенные нагрузки и автоматически создавать задачи на устранение найденных проблем.

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

Параметры проекта

Срок создания архитектуры: 1 месяц

Срок разработки: 1 год от постановки задачи до релиза

Технологический стек: Python, Docker Compose, PostgreSQL, LDAP, LLM

Статус: внутренняя разработка, активно развивается

Архитектура: модульная система на Docker

Система представляет набор сервисов на Docker Compose, которые можно развернуть на любой машине на базе ОС *nix.


* - любой из возможных префиксов существующих ОС, построенных на базе Unix.

Архитектура построена по модульному принципу:


→ Модуль обработки/записи событий от внешних систем

→ Модуль управления очередью очереди событий

→ Модуль управления состоянием событий

→ Модули для каждой практики DevSecOps

→ Модули сервисных процедур

→ Модули работы с таблицами базы данных

→ Модуль автоматического создания задач в job-tracker

→ Ядро системы


Описание функционала:


Pull Request создан/изменён

Внешними системами созданы WEB-hooks


→ Каждый модуль системы отвечает за конкретную практику DevSecOps/сервисную процедуру

→ Ядро обеспечивает координацию работы модулей и реализацию логики системы в целом

→ Результаты записываются в единую базу данных на основе PostgreSQL

→ Логи работы системы и её компонентов передаются в БД или внешний агрегатор событий

→ Автоматическое создание задач на устранение проблем

→ Аутентификация через LDAP

→ Дедубликация уязвимостей


Ядро системы управляет соответствующими модулями выявления проблем с безопасностью, а также прочими сервисными процедурами. Каждый сервис является самостоятельным и отвечает за функционал по конкретной практике DevSecOps. Это даёт независимость от платформы и возможности горизонтального и вертикального масштабирования.

Модульная архитектура была выбрана, потому что это удобно и потенциально выгодно для горизонтального расширения, есть возможность создания контуров High Availability. Каждый модуль можно масштабировать отдельно под нагрузку.

Пять ключевых возможностей сканера

1. Проверка на этапе Pull Request

Система срабатывает автоматически при попытке слить код с основной веткой. Разработчик создаёт PR — сканер запускается и анализирует изменения на все известные уязвимости.

В едином инструменте разработчика видны статусы прохождения Quality Gate. Ссылки на отчёты находятся прямо в Git-системе, а цвет отчёта сразу говорит о наличии проблем.

2. Полная автоматизация без участия команды

Вся проверка происходит без действий со стороны разработчиков или DevSecOps-инженеров. Не нужно запускать сканы вручную, отслеживать результаты или формировать отчёты. Система сама находит проблемы, записывает их в базу и создаёт задачи на устранение с указанием ответственных лиц.

Не требуется привлечение команд для настройки pipeline. Автоматическое создание задач включает проверку на дублирование — если задача на такую же уязвимость уже есть, новую не создаём.

3. Интеграция со сторонними инструментами

Сканер может работать с внешними сканерами безопасности и агрегаторами событий. Это позволяет встроить его в существующую инфраструктуру банка без перестройки процессов. Логи системы передаются в PostgreSQL или внешние системы мониторинга.

В BI на дашборде можно получить информацию по статусам сканирования всех проектов. Менеджеры могут получить общую картину состояния безопасности по каждому проекту Банка.


4. Работа под высокой нагрузкой

Система выдерживает одновременную проверку множества Pull Request без деградации производительности. Модульная архитектура позволяет масштабировать сервисы горизонтально — добавлять новые контейнеры под нагрузку, или вертикально — увеличивать ресурсы существующих.

5. Фильтрация ложных срабатываний через LM

Статические анализаторы кода часто выдают false positive — помечают безопасный код как небезопасный, но в реальности это не так. Это создаёт шум и заставляет разработчиков тратить время на проверку несуществующих проблем. Для решения этой задачи в систему интегрировали специализированную языковую модель, которая анализирует контекст и отсеивает ложные срабатывания.

Отчёт о найденных уявимостях содержит только релевантную информацию.



6. Модификация пояснений к уявзимостям через LM

Статические анализаторы кода часто предоставляют инструкцию по устранению выявленных уязвимостей в неинтуитивном/неструктурированном виде. Это создаёт трудности для разработчиков и увеличивает time-to-market для создаваемых программных продуктов в целом. Для решения этой задачи в систему интегрирована большую специализированная языковая модель, которая оптимизирует текст и делает инструкция более понятной и эффективной.

Задачи содержат эффективные инструкции по устранению выявленных уязвимостей в коде.

7. Дайджест по уязвимостям

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

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

Главные трудности в реализации

🔴 Сложность логики выявления артефактов сканирования

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

✅ Решение: Провели анализ выходных данных всех используемых инструментов и создали унифицированные модули парсинга. Каждый модуль преобразует специфичный формат внешнего сканера в единую структуру для записи в PostgreSQL.

🔴 Специфика работы разных сканеров

Инструменты DevSecOps работают по-разному: одни проверяют зависимости, другие — статический код, третьи — конфигурации. Нужно было объединить их в единую систему без потери функциональности.

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

🔴 Отсутствие информации о состоянии процессов

Внешние системы не всегда предоставляют актуальную информацию о статусе проверок в режиме реального времени. Сложно понять, завершился ли скан или ещё выполняется.

✅ Решение: Настроили систему событий (events), которая отслеживает изменения состояний во внешних инструментах и синхронизирует данные.

🔴 Отсутствие стандартизации в выполнении операций в CI/CD

Современные системы CI/CD предоставляют обширный выбор в реализации того или иного шага, будь то сборка проекта или пуш готового образа. Есть сложность в интерпретации выполняемых операций и предсказания ожидаемого типа артефакта на выходе, например, образ или биллютень используемых в разработке сторонних компонентов.

✅ Решение: Создали отдельные модули анализа и парсинга этапов CI/CD, что позволило гарантировано определить scope применимых практик DevSecOps, тем самым повысить эффективность оценки уровня безопасности проекта в целом.

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

Снижение расходов на устранение проблем безопасности до 30 раз за счёт раннего анализа — исправить уязвимость на этапе PR в разы дешевле, чем после релиза в продакшен.

Главные эффекты для бизнеса: повышение качества кода продукта через постоянные автоматические проверки, снижение репутационных рисков компании за счёт предотвращения утечек и инцидентов безопасности, снижение технического долга команд разработки, улучшение процессов разработки через встраивание security practices в ежедневный workflow.

Полная автоматизация освободила разработчиков и DevSecOps-инженеров от рутинной работы по запуску сканов и анализу результатов. Система работает сама — от триггера PR до создания задачи на исправление.

Планы развития

1. Интегрировать в систему процессы выявления проблем безопасности при разработки собственных LM;
2. Интегрировать в систему процессы выявления проблем безопасности при разработки агентов AI;
3. Интегрировать в систему процессы выявления проблем безопасности при внедрении LLM;
4. Интеграция с системой класса ASPM;
5. Интеграция с собственной системой уведомления;
6. Внедрение метрик health-check для оценки состояния работоспособности системы и её компонентов.