ASOC своими руками: как автоматизировать DevSecOps-контроли через Open Source и LLM

Application Security Orchestration and Correlation, или ASOC, решает знакомую проблему: security-инструментов много, сигналов ещё больше, а разработчикам нужен понятный ответ — что чинить первым, где риск реальный, кто владелец и как это связано с конкретным сервисом.

ASOC-платформу можно строить не только покупкой большого enterprise-продукта. Для части команд достаточно собрать собственный слой корреляции поверх уже существующих сканеров, CI/CD и таск-трекера, дополнив его Open Source-инструментами и LLM для объяснения находок.

Зачем вообще нужен ASOC

Если в компании есть SAST, DAST, dependency scanning, container scanning, secret scanning и ручные проверки, быстро появляется хаос. Один и тот же сервис может иметь findings в разных системах. Часть дублей, часть ложных срабатываний, часть давно исправлена, часть критична только в production-контексте.

Без оркестрации это превращается в таблицы, ручную сортировку и споры между security и разработкой. ASOC добавляет слой, который:

• собирает findings из разных источников;
• нормализует формат;
• связывает находки с сервисами и владельцами;
• удаляет дубли;
• приоритизирует по риску;
• создаёт задачи;
• отслеживает SLA;
• помогает объяснять проблему разработчику.

Где здесь помогают LLM

LLM не должна решать, является ли уязвимость критичной, без фактов. Но она полезна как объясняющий и классифицирующий слой.

Например, модель может:

• кратко пересказать длинный отчёт сканера;
• объяснить impact простым языком;
• предложить first steps для проверки;
• сгруппировать похожие findings;
• подготовить текст задачи для Jira/GitHub Issues;
• подсказать, какой команде вероятнее принадлежит проблема;
• помочь с triage ложных срабатываний, если есть контекст.

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

Минимальная архитектура

Самодельный ASOC можно начать с простой схемы:

Сканеры и CI/CD
      ↓
Ingest workers
      ↓
Единая база findings
      ↓
Корреляция и приоритизация
      ↓
LLM-объяснения и задачи
      ↓
Dashboard / tracker / alerts

На первом этапе не нужно строить идеальную платформу. Достаточно подключить 2–3 источника, например dependency scanning, secret scanning и SAST. Главная ценность появится уже после нормализации и дедупликации.

Что важно хранить в finding

У каждой находки должны быть стабильные поля:

• источник;
• тип проблемы;
• severity;
• affected service;
• repository и branch;
• файл или компонент;
• версия зависимости;
• окружение;
• статус;
• владелец;
• дата первого обнаружения;
• дата последнего подтверждения.

Без этих полей ASOC быстро станет ещё одной свалкой. Особенно важен владелец. Если находка не привязана к команде, она будет висеть бесконечно.

Приоритизация важнее количества

Security-команды часто проигрывают не из-за отсутствия сканеров, а из-за избытка необработанных сигналов. Поэтому ASOC должен отвечать на вопрос: что чинить первым?

Приоритет можно считать по нескольким факторам:

• severity из сканера;
• наличие exploit;
• internet-facing сервис или внутренний;
• production или test;
• критичность бизнес-функции;
• есть ли compensating controls;
• повторяется ли finding;
• насколько свежая версия зависимости.

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

Интеграция с CI/CD

Хороший DevSecOps-процесс не просто создаёт отчёт, а встраивается в pipeline. Но блокировать каждый build из-за каждой medium-находки — плохая идея. Команда быстро начнёт обходить проверки.

Лучше разделить режимы:

• informational для старых проблем;
• warning для новых некритичных;
• blocking для secrets, critical vulnerabilities и нарушений policy;
• manual approval для спорных случаев.

ASOC помогает тем, что знает историю. Если проблема старая и уже заведена задача, pipeline может не создавать дубликаты. Если появилась новая critical-находка в internet-facing сервисе — можно блокировать merge.

Ограничения самодельной платформы

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

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

Итог

ASOC — это не магическая кнопка безопасности, а слой инженерной связности между сканерами, CI/CD, командами и задачами. Open Source и LLM позволяют собрать полезный внутренний инструмент без огромного бюджета, если начать с малого и не пытаться сразу заменить все процессы.

Самая ценная часть такой системы — не красивый dashboard, а нормализация, дедупликация, владельцы и понятные объяснения для разработчиков. Именно это превращает AppSec из потока тревог в управляемый процесс.