ASOC-платформа из OpenSource и LLM: как собрать за вечер и закрыть пробелы безопасности

Андрей Отинов -

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

Источник: Habr

Практическое следствие: без единой платформы, которая проверяет все репозитории — активные и архивные — компания рискует пропустить уязвимости в коде, который никто не трогает годами. Решение, которое предлагает автор опубликованного на Habr туториала, — собрать собственную ASOC-платформу (Application Security Orchestration and Correlation) из открытых компонентов и подключить к ней LLM для анализа уязвимостей.

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

Что такое ASOC и почему пайплайнов недостаточно

ASOC — это класс платформ, которые координируют работу разных сканеров безопасности (SAST, DAST, SCA), собирают данные об уязвимостях в одном месте и передают их разработчикам. Если упростить: это единая панель управления для AppSec-процессов.

Автор туториала объясняет, почему полагаться только на сканирование в пайплайне сборки — рискованно. Три главные проблемы:

  1. Архивные репозитории выпадают из поля зрения. Если секрет попал в код два года назад, а репозиторий с тех пор не собирался, сканер его не найдёт. Но секрет остаётся в истории Git.
  2. Нет общей картины по компании. Нельзя увидеть динамику по времени жизни уязвимостей (TTL) или сравнить состояние безопасности разных проектов.
  3. Зоопарк исключений. Когда у сотен репозиториев свои правила для тестовых папок, управлять этим вручную — ад.

ASOC-платформа решает эти проблемы, но вопрос в том, покупать готовое решение (DefectDojo, Qualys) или собирать своё.

Что изменилось: LLM как компонент ASOC

Главная новость не в том, что ASOC-платформы существуют — они есть давно. Новизна в том, что автор показывает, как встроить LLM в такую платформу, чтобы автоматизировать анализ уязвимостей и генерацию отчётов.

Раньше для этого требовалась команда инженеров безопасности, которые вручную разбирали вывод сканеров. Теперь, по замыслу автора, LLM может взять на себя часть этой работы: объяснить разработчику, почему найденная проблема опасна, и предложить вариант исправления.

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

Как собрать ASOC-платформу: ключевые компоненты

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

Компонент Назначение Пример OpenSource-инструмента
Сканер кода (SAST) Поиск уязвимостей в исходном коде Semgrep, SonarQube
Сканер зависимостей (SCA) Проверка библиотек на известные уязвимости OWASP Dependency-Check, Trivy
Сканер секретов Поиск паролей, токенов, ключей в коде Gitleaks, TruffleHog
База данных уязвимостей Хранение и дедупликация результатов PostgreSQL + DefectDojo (как вариант)
Оркестратор Запуск сканеров по расписанию и сбор результатов GitLab CI, Airflow, собственный скрипт
LLM-модуль Анализ уязвимостей, генерация описаний и рекомендаций OpenAI API, локальная модель через Ollama

Автор подчёркивает, что не пытается изобрести велосипед и знает о существовании DefectDojo и Qualys. Его цель — показать, что разработка собственного инструмента сегодня не является сложной задачей.

Где выгода: что даёт самодельная ASOC-платформа

Если собрать платформу по описанному методу, компания получает:

  • Единую точку управления. Все результаты сканирования — в одном месте, независимо от того, какой сканер использовался.
  • Автоматическое сканирование архивных репозиториев. Платформа может проверять всё, что есть в Git, а не только то, что собирается в CI/CD.
  • Метрики и динамику. Можно увидеть, как меняется количество уязвимостей по проектам и командам.
  • LLM-ассистента для разработчиков. Вместо сухого отчёта сканера — понятное описание проблемы и рекомендация по исправлению.

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

Где риски и ограничения: что автор говорит честно

Автор туториала прямо предупреждает о нескольких важных ограничениях:

  1. Проект не production-ready. Чтобы довести платформу до промышленного использования, её нужно дорабатывать, особенно в части автоматизации.
  2. Автор не senior-специалист. Он открыт к критике и не претендует на идеальную архитектуру.
  3. LLM может ошибаться. Анализ уязвимостей языковой моделью — это вспомогательный инструмент, а не замена эксперту.
  4. Стоимость LLM. Если использовать платные API (например, OpenAI), затраты могут быть значительными при большом количестве репозиториев.
  5. Поддержка и обновления. Самодельную платформу нужно поддерживать силами своей команды.

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

Что проверить до того, как начинать сборку

Прежде чем тратить вечера на реализацию, стоит ответить на несколько вопросов:

  1. Сколько у вас репозиториев? Если меньше 50, возможно, проще настроить сканирование в пайплайне и использовать готовый DefectDojo.
  2. Есть ли у вас человек, который будет поддерживать платформу? Без DevOps- или ИБ-инженера самодельное решение быстро превратится в проблему.
  3. Готовы ли вы к ложным срабатываниям LLM? Языковая модель может неправильно интерпретировать уязвимость, и это потребует ручной проверки.
  4. Какой бюджет на LLM? Если планируете использовать платные модели, посчитайте стоимость на ваш объём кода.

Практический чек-лист для первой недели

Если вы решили попробовать, вот что можно сделать за первую неделю без перестройки процессов:

  • [ ] Установите один SAST-сканер (например, Semgrep) и запустите на 2-3 репозиториях вручную.
  • [ ] Настройте Gitleaks для поиска секретов во всех репозиториях — включая архивные.
  • [ ] Соберите результаты в простую таблицу или Google Sheets — это минимальная замена ASOC.
  • [ ] Попробуйте отправить вывод сканера в LLM (через API или локальную модель) и оцените качество анализа.
  • [ ] Сравните время, которое уходит на ручной разбор уязвимостей, с тем, что даёт LLM.
  • [ ] Решите, нужна ли вам полноценная платформа или достаточно улучшить существующий пайплайн.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше