Как создавался агрегатор ИБ-новостей: объединение сюжетов, семь критериев важности и настройка порога
Идея собственного агрегатора новостей по кибербезопасности появилась давно. Хотелось получать действительно значимые события, не тратя время на вебинары, рекламные анонсы, пресс-релизы и бесконечные перепечатки. На раннем этапе языковые модели еще не стали привычным рабочим инструментом, поэтому первая версия строилась на модели суммаризации `rut5_base_sum_gazeta`, а значимость публикаций определялась с помощью TextRank. Результат оказался нестабильным: важные материалы терялись, а второстепенные регулярно попадали в ленту.
Позже появились сервисы, способные автоматически подбирать новости под интересы пользователя. Однако универсального решения для ИБ так и не нашлось. Одни агрегаторы пытаются охватить все темы сразу, другие специализируются на узком направлении - например, только на уязвимостях или только на российских инцидентах.
На бумаге задача выглядела несложно: собрать ленты, передать материалы модели и попросить выбрать главное. На практике уже первые недели разработки показали, что одного промпта недостаточно. При повышении порога канал мог молчать весь день, а после снижения в него начинали проходить рекламные сообщения, продуктовые презентации и отраслевые обзоры сомнительной ценности.
Так сформировалась гибридная архитектура. Языковая модель отвечает за понимание содержания, отсечение нерелевантных материалов и подготовку текста. Итоговая оценка важности рассчитывается не моделью, а прозрачной формулой из семи признаков. Все промежуточные значения записываются в журнал, поэтому можно понять, почему конкретный сюжет прошел фильтр.
Что умеет агрегатор сейчас
Ежедневно система получает около тысячи материалов более чем из 200 источников, связанных с кибербезопасностью. До публикации доходит примерно 0,5% входящего потока.
Ключевое решение - публиковать сюжет или нет - принимает формула с открытыми весами. В журнале видно, какие факторы дали итоговый балл: например, наличие нескольких независимых публикаций, ссылка на первоисточник, высокий CVSS, подтвержденная эксплуатация уязвимости или участие крупного поставщика.
Модель используется для двух задач:
- удаления публикаций, не относящихся к кибербезопасности;
- подготовки связного пересказа отобранного сюжета.
Такой подход позволяет разделить смысловую обработку и принятие решения. Модель может ошибиться в формулировке, но не получает полного контроля над публикационной политикой.
Почему недостаточно просто спросить модель
Простейшая схема LLM-агрегатора выглядит так: передать модели список материалов и задать вопрос "Что здесь важно?". Подобная система может работать на демонстрации, но быстро сталкивается с проблемой объяснимости.
Если сегодня прошел один материал, а завтра аналогичный был отклонен, трудно установить причину. Два одинаковых запуска иногда дают разные ответы. Изменение поведения требует правки промпта, а результат не всегда можно предсказать заранее.
В разработанном агрегаторе каждый балл имеет интерпретируемый смысл. Например, итог может быть сформирован так: событие описали пять независимых изданий, найден первоисточник, для уязвимости указан CVSS 9,8, а атаки уже зафиксированы. Такой результат можно проверить, сравнить с другими сюжетами и скорректировать изменением веса конкретного признака, а не переписыванием всей инструкции для модели.
Откуда взялись основные идеи
Многие элементы агрегатора опираются на опыт крупных новостных систем. Классическая схема включает четыре этапа:
1. сбор материалов от источников;
2. извлечение фактов;
3. объединение публикаций в сюжеты;
4. ранжирование получившихся сюжетов.
Оценка обычно учитывает свежесть, информативность и цитируемость материала. Краткое описание события формируется из лучших фрагментов нескольких публикаций, а значимость источников может пересчитываться на основе их оперативности и количества цитирований.
У небольшого специализированного проекта масштаб другой: речь идет не о тысячах партнеров и сотнях тысяч сообщений в сутки, а о нескольких сотнях профильных источников. Поэтому часть механизмов была упрощена. Например, вес источника задается вручную и зависит от типа контента. У исследовательского центра, CERT или разработчика продукта будут разные исходные коэффициенты.
При этом единицей ранжирования остается не отдельная статья, а сюжет - группа материалов об одном событии. Это важно: если десять сайтов перепечатали одну новость, они не должны создать десятикратный перевес.
Склейка публикаций в единый сюжет
Дублирование стало одной из главных проблем еще на этапе подготовки сводок. Несколько материалов могут описывать одну уязвимость, один инцидент или один отчет, но отличаться заголовками и деталями. Если обрабатывать их независимо, лента быстро заполняется повторениями.
Поэтому перед ранжированием система пытается определить, относятся ли публикации к одному событию. В идеальном варианте алгоритм учитывает сущности, даты, продукты, номера уязвимостей, компании и фактические связи между текстами. Однако полностью автоматическая склейка остается сложной задачей: одна и та же тема может развиваться несколько дней или недель, а новые сообщения добавляют существенные детали.
Оценка важности рассчитывается один раз на сюжет. Это позволяет учитывать не только качество отдельного текста, но и общую картину: количество подтверждений, наличие первоисточника, развитие события и свежесть последних обновлений.
Семь признаков значимости
Формула ранжирования включает семь факторов. Их конкретные коэффициенты можно менять, но сама логика остается прозрачной.
В числе признаков используются:
- количество независимых публикаций;
- наличие первоисточника;
- серьезность уязвимости, включая показатель CVSS;
- подтвержденная эксплуатация в реальных атаках;
- масштаб затронутой инфраструктуры;
- практическая значимость для пользователей и специалистов;
- свежесть и динамика развития события.
Одновременно применяются штрафы. Они снижают итоговую оценку для перепечаток без новых фактов, рекламных сообщений, мероприятий, продуктовых анонсов и материалов, где фактическая составляющая слишком мала.
Наличие первоисточника особенно важно. Вторичный текст может быть хорошо написан, но ценность оригинального отчета обычно выше: именно он содержит технические детали, индикаторы компрометации, методику исследования и подтверждения.
Как выбирается порог публикации
Порог нельзя назначить один раз и считать задачу закрытой. Поток новостей меняется: в период крупной кампании атак релевантных материалов становится больше, а в спокойные дни значимых событий может быть мало.
При слишком высоком значении система начинает пропускать только самые громкие сюжеты. При слишком низком пороге в ленте появляются материалы, которые формально связаны с ИБ, но не дают читателю практической пользы.
Поэтому калибровка проводится на накопленной статистике. Анализируются причины прохода и отсева, сравниваются похожие сюжеты, отслеживаются ошибки. Особенно полезно смотреть не только на итоговый балл, но и на его состав: это помогает понять, какой признак чрезмерно влияет на результат.
Длинные сюжеты и меняющаяся важность
Некоторые события невозможно описать одной публикацией. Хороший пример - история с автономными агентами OpenAI, которая развивалась на протяжении 23 дней. В первый день новость могла выглядеть как технологическая демонстрация, затем появились технические подробности, обсуждение рисков, реакции исследователей и последствия для безопасности.
Если считать каждое сообщение отдельной новостью, получится серия повторов. Если склеить все материалы навсегда, система начнет считать старый сюжет актуальным даже после завершения обсуждения.
Для таких случаев важны временные рамки и обновление состояния сюжета. Новая публикация должна повышать значимость только тогда, когда добавляет проверяемые сведения, меняет оценку риска или показывает развитие события. Сам факт появления очередной перепечатки не должен продлевать жизнь сюжета.
Как писать об уязвимостях
Уязвимости требуют отдельного подхода. Одного номера CVE недостаточно: читателю важно понимать, какой продукт затронут, какие версии уязвимы, есть ли исправление, насколько сложна эксплуатация и наблюдались ли реальные атаки.
В кратком пересказе желательно разделять:
- техническую суть проблемы;
- затронутые продукты и версии;
- оценку серьезности;
- наличие публичного эксплойта;
- факт эксплуатации злоумышленниками;
- доступные меры защиты.
Нельзя автоматически превращать высокий CVSS в безусловно критичную новость. Оценка зависит от контекста: уязвимость может иметь высокий балл, но быть применимой только в редкой конфигурации. И наоборот, менее впечатляющая по формальным метрикам ошибка может представлять серьезную угрозу из-за массового распространения продукта.
Контекст как отдельный блок
Из формата коротких деловых новостей была позаимствована идея дополнительной врезки. Основной текст отвечает на вопрос "что произошло", а отдельный блок объясняет термин, технологию или фон события.
Такой формат особенно полезен для сложных тем. Читателю не всегда нужно читать длинный справочник о протоколе, поставщике или классе атак, но без минимального объяснения новость может оказаться непонятной. Контекстный блок позволяет сохранить краткость и одновременно не жертвовать смыслом.
Что пока остается нерешенным
Одна из открытых задач - вычисляемая репутация источников. Ручная настройка проста, но со временем может устаревать. Автоматическая оценка по цитируемости и скорости публикации объективнее, однако требует корректно разбирать ссылки между материалами и отличать независимое подтверждение от массового копирования.
Еще одна проблема - оценка вовлеченности. Число просмотров, реакций или репостов не всегда отражает общественную значимость. Скандальная, но малополезная тема может собрать больше внимания, чем технически важный бюллетень. Поэтому вовлеченность разумнее использовать как вспомогательный сигнал, а не как главный критерий.
Сложность представляет и определение границы между продолжением сюжета и новым событием. Выпуск исправления, публикация эксплойта, обнаружение атак и появление новых жертв могут быть частями одной истории, но иногда каждое из этих сообщений заслуживает отдельного материала.
Практические выводы
Опыт разработки показывает, что качественный ИБ-агрегатор - это не просто RSS-лента и не чат с языковой моделью. В нем должны сочетаться несколько уровней:
- широкий, но тщательно отобранный набор источников;
- фильтрация нерелевантного контента;
- объединение дублей в сюжеты;
- объяснимое ранжирование;
- генерация краткого и проверяемого пересказа;
- контроль качества и накопление статистики ошибок.
Главный принцип - не перекладывать все решения на модель. LLM хорошо справляется с пониманием текста и формулировками, но публикационный порог должен быть управляемым и проверяемым. Чем яснее видно, почему материал прошел фильтр, тем проще совершенствовать систему и сохранять доверие читателя.
В результате агрегатор превращается не в поток автоматически пересказанных ссылок, а в инструмент отбора: он помогает увидеть действительно важные изменения в сфере кибербезопасности и не утонуть в информационном шуме.