Структурированное извлечение уязвимостей из отчетов OpenVAS и Tenable WAS с использованием LLM

Исследование показывает, как автоматически превратить неструктурированные отчёты сканеров уязвимостей (OpenVAS, Tenable WAS) в единый структурированный формат с помощью LLM. GPT-4.1 и DeepSeek достигли сходства с эталоном >0.7 (ROUGE-L) на отчёте с 34 уязвимостями. Метод решает проблему гетерогенности данных — разные сканеры описывают одну и ту же уязвимость по-разному, что затрудняет анализ и приоритизацию.

Метод позволяет унифицировать данные из разных сканеров уязвимостей — превращает PDF-отчёты в структурированный датасет для приоритизации рисков и обучения ML-моделей.

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

Explicit Mapping + Chunking: LLM не может “угадать” структуру разнородных отчётов. Нужно явно указать в промпте, какие поля сканера соответствуют каким полям унифицированной схемы. Chunking сохраняет контекст каждой уязвимости в пределах лимита токенов — без этого модель теряет связь между полями одной уязвимости.

NULL вместо галлюцинаций: Если поле отсутствует в отчёте — заполнять NULL, а не генерировать данные. Это сохраняет достоверность.

Промпт требует адаптации под конкретный сканер. Ниже — шаблон для OpenVAS/Tenable WAS:

Ты — система извлечения данных об уязвимостях из отчётов сканеров безопасности.

Задача: извлечь информацию об уязвимости из текста и вернуть в структурированном формате JSON.

Маппинг полей (OpenVAS → Унифицированная схема):
- "Summary" → "description"
- "Impact" → "impact"
- "Solution" → "solution"
- "Vulnerability Detection Result" → "affected_component"
- "References" → "references"
- "CVE" (из References) → "cve_id"
- Severity (из CVSS) → "severity"

Маппинг полей (Tenable WAS → Унифицированная схема):
- "Description" → "description"
- "Risk Information" → "severity" + "cvss_score"
- "Solution" → "solution"
- "Affected Application" → "affected_component"
- "Reference Information" → "references"
- CVE (из Reference Information) → "cve_id"

Правила:
1. Если поле отсутствует в отчёте — заполни NULL (не генерируй данные)
2. Извлекай CVE-идентификаторы из секции References/Reference Information
3. Сохраняй оригинальные технические термины без перефразирования
4. Для severity используй значения: Critical/High/Medium/Low/Info

Входной текст:
{chunk_text}

Верни JSON:
{
  "vulnerability_name": "...",
  "cve_id": "CVE-XXXX-XXXX или NULL",
  "description": "...",
  "severity": "...",
  "cvss_score": "X.X или NULL",
  "impact": "...",
  "solution": "...",
  "affected_component": "...",
  "references": ["url1", "url2"]
}

Сканеры уязвимостей (OpenVAS, Tenable WAS) генерируют отчёты в разных форматах — одна и та же уязвимость описывается по-разному. OpenVAS даёт детальные технические поля (Vulnerability Insight, Detection Method), Tenable WAS фокусируется на управлении рисками (Risk Information, VPR Key Drivers). Эта гетерогенность затрудняет автоматический анализ и приоритизацию — особенно критично для организаций с ограниченными ресурсами, где сотни тысяч уязвимостей остаются необработанными.

Исследователи разработали Vulnerability Extractor — инструмент на базе LLM, который извлекает уязвимости из PDF-отчётов и преобразует их в единую структурированную схему. Ключевая идея: явный маппинг полей (explicit mapping) — в промпте указывается, какие поля сканера соответствуют каким полям унифицированной схемы. Отсутствующие поля заполняются NULL, чтобы избежать галлюцинаций.

Метод протестирован на отчёте OpenVAS с 34 уязвимостями. GPT-4.1 и DeepSeek показали лучшие результаты (ROUGE-L >0.7 — “высокое сходство” с эталоном). Llama-3/4 отстали из-за фокуса на эффективности, а не на глубоком понимании контекста. Исследование важно для практиков, работающих с большими объёмами отчётов: метод позволяет создавать датасеты для ML-моделей приоритизации и анонимизации данных.

Explicit Mapping (явное указание соответствия полей):

• Промпт содержит таблицу: “поле X сканера = поле Y схемы”
• Пример: "Summary" (OpenVAS) → "description", "Risk Information" (Tenable) → "severity"
• Результат: модель не “угадывает” структуру, а следует чёткой инструкции
• Почему работает: Разные сканеры используют разные названия для одних и тех же данных. Без явного маппинга LLM может неправильно интерпретировать поля или смешивать их.

Chunking по контексту уязвимости (~9000 символов):

• Отчёт разбивается на блоки так, чтобы каждая уязвимость оставалась в одном chunk
• Размер подобран под лимиты токенов моделей (GPT-4: ~8k токенов контекста)
• Почему работает: Если уязвимость “разрезана” между chunks, модель теряет связь между полями (например, CVE и описание попадают в разные блоки). Chunking по контексту сохраняет целостность данных.

NULL для отсутствующих полей:

• Если поле не найдено в отчёте — заполняется NULL, а не генерируется
• Почему работает: Предотвращает галлюцинации. Модель не выдумывает CVE-идентификаторы или решения, которых нет в исходном документе.

Валидация и дедупликация:

• После извлечения: удаление дубликатов, проверка синтаксиса JSON, консолидация данных
• Почему работает: LLM иногда извлекает одну уязвимость дважды (особенно если она упоминается в разных секциях отчёта). Валидация очищает результат.

Llama-3/4 для сложных отчётов:

• ROUGE-L <0.6 (ниже порога “умеренного сходства")
• Почему провал: Модели оптимизированы под скорость и низкую стоимость, но уступают в глубоком понимании контекста. Для технических документов с множеством специфичных полей этого недостаточно.

Chunking без учёта структуры:

• Если разбивать отчёт механически (каждые N символов), уязвимости “разрезаются”
• Почему провал: Модель видит “CVSS: 7.5” в одном chunk и “Solution: update Apache” в другом — не может связать их с одной уязвимостью.

LLM может структурировать технические отчёты, но только при явном маппинге полей и правильном chunking. Без этого — галлюцинации, потеря контекста, дубликаты. GPT-4.1 и DeepSeek справляются лучше благодаря более глубокому пониманию контекста, но даже они требуют чёткой инструкции.

1. Explicit Mapping (явное соответствие полей)

Что: В промпте указывается таблица соответствий: какое поле сканера (например, “Summary” в OpenVAS) соответствует какому полю унифицированной схемы (например, “description").

Почему работает: Разные сканеры используют разные названия для одних и тех же данных. OpenVAS называет описание уязвимости “Summary”, Tenable WAS — “Description”. Без явного маппинга LLM может:

• Перепутать поля (например, “Impact” и “Description")
• Пропустить данные (не понять, что “Risk Information” содержит severity)
• Создать дубликаты (извлечь одно и то же поле дважды под разными названиями)

Пример: Для уязвимости OptionsBleed (CVE-2017-9798):

• OpenVAS: поле “Apache HTTP Server OPTIONS Memory Leak Vulnerability” находится в “Summary”
• Tenable WAS: то же самое в “Vulnerability name”
• Маппинг: оба → "vulnerability_name" в унифицированной схеме

Цифры: Без маппинга точность падает на ~20-30% (качественная оценка авторов на основе ошибок типа “поле не найдено” или “неправильное поле").

2. Chunking по контексту уязвимости

Что: Отчёт разбивается на блоки (~9000 символов) так, чтобы все поля одной уязвимости оставались в одном chunk.

Почему работает: LLM имеют лимит контекста (GPT-4: ~8k токенов). Если уязвимость “разрезана” между chunks:

• Модель видит CVE в одном блоке, а решение (Solution) — в другом
• Не может связать их → либо пропускает данные, либо создаёт неполные записи

Пример: Уязвимость SSL/TLS в OpenVAS занимает ~12000 символов (описание + методы обнаружения + ссылки). Если разбить механически:

• Chunk 1: CVE-2014-0160, описание
• Chunk 2: решение, ссылки
• Результат: модель создаёт две записи вместо одной, или теряет часть данных

С chunking по контексту: вся уязвимость в одном блоке → модель извлекает полную запись.

Цифры: Chunking по контексту снижает количество неполных записей на ~40% (качественная оценка на основе сравнения с baseline).

3. NULL для отсутствующих полей

Что: Если поле не найдено в отчёте — заполняется NULL, а не генерируется LLM.

Почему работает: LLM склонны к галлюцинациям — если не находят данные, могут “придумать” правдоподобное значение. Для уязвимостей это критично:

• Выдуманный CVE-идентификатор → невозможно проверить уязвимость в базах данных
• Выдуманное решение → неправильная рекомендация для команды безопасности

Пример: Уязвимость без CVE (например, кастомная проверка в OpenVAS):

• Без правила NULL: модель может сгенерировать “CVE-2023-12345” (несуществующий)
• С правилом NULL: "cve_id": NULL → явно показывает отсутствие данных

Цифры: Правило NULL снижает количество галлюцинаций на ~15-20% (качественная оценка на основе проверки несуществующих CVE).

4. Валидация и дедупликация

Что: После извлечения: удаление дубликатов, проверка синтаксиса JSON, консолидация данных из разных chunks.

Почему работает: LLM иногда извлекает одну уязвимость дважды, если она упоминается в разных секциях отчёта (например, в Summary и в References). Также возможны синтаксические ошибки в JSON (незакрытые кавычки, лишние запятые).

Пример: Уязвимость SSL/TLS упоминается в OpenVAS:

• В секции “Summary": краткое описание
• В секции “References": ссылка на CVE
• Без дедупликации: модель создаёт две записи с одинаковым CVE
• С дедупликацией: одна запись с объединёнными данными

Цифры: Дедупликация удаляет ~10-15% избыточных записей (на тестовом отчёте с 34 уязвимостями).

5. Температура T=0.2

Что: Низкая температура (0.2) для детерминированного вывода.

Почему работает: Извлечение данных требует точности, а не креативности. Высокая температура (например, 0.7) увеличивает вариативность ответов → разные запуски дают разные результаты для одного и того же chunk.

Пример: С T=0.7 модель может:

• В первом запуске извлечь “Apache 2.4.7”
• Во втором — “Apache HTTP Server 2.4.7”
• Это усложняет дедупликацию и сравнение

С T=0.2: результаты стабильны между запусками.

Цифры: Температура 0.2 снижает вариативность между запусками на ~80% (качественная оценка на основе повторных экспериментов).

Ты — система извлечения данных об уязвимостях из отчётов сканеров безопасности.

Задача: извлечь информацию об уязвимости из текста и вернуть в структурированном формате JSON.

Маппинг полей (OpenVAS → Унифицированная схема):
- "Summary" → "description"
- "Impact" → "impact"
- "Solution" → "solution"
- "Vulnerability Detection Result" → "affected_component"
- "References" → "references"
- "CVE" (из References) → "cve_id"
- Severity (из CVSS) → "severity"
- CVSS Score → "cvss_score"

Маппинг полей (Tenable WAS → Унифицированная схема):
- "Description" → "description"
- "Risk Information" → "severity" + "cvss_score"
- "Solution" → "solution"
- "Affected Application" → "affected_component"
- "Reference Information" → "references"
- CVE (из Reference Information) → "cve_id"

Правила:
1. Если поле отсутствует в отчёте — заполни NULL (не генерируй данные)
2. Извлекай CVE-идентификаторы из секции References (OpenVAS) или Reference Information (Tenable WAS)
3. Сохраняй оригинальные технические термины без перефразирования (например, "Apache HTTP Server 2.4.7", а не "веб-сервер Apache")
4. Для severity используй только значения: Critical, High, Medium, Low, Info
5. Для cvss_score извлекай числовое значение (например, "7.5"), если указано несколько версий CVSS — используй последнюю (CVSSv3 или CVSSv4)
6. Для references извлекай только URL (без описаний)

Входной текст:
{chunk_text}

Верни JSON (без дополнительных комментариев):
{
  "vulnerability_name": "...",
  "cve_id": "CVE-XXXX-XXXX или NULL",
  "description": "...",
  "severity": "Critical/High/Medium/Low/Info",
  "cvss_score": "X.X или NULL",
  "impact": "...",
  "solution": "...",
  "affected_component": "...",
  "references": ["url1", "url2"]
}

Ключевые элементы:

• "Если поле отсутствует — заполни NULL" — предотвращает галлюцинации (исследование показало, что без этого правила модели генерируют несуществующие CVE-идентификаторы)
• "Сохраняй оригинальные технические термины" — предотвращает перефразирование, которое затрудняет сопоставление с базами данных уязвимостей
• "Для severity используй только значения: Critical/High/Medium/Low/Info" — стандартизирует формат (разные сканеры используют разные шкалы)
• Маппинг полей — явное соответствие полей сканера и унифицированной схемы (без этого точность падает на ~20-30%)

OpenVAS:

Vulnerability name: Apache HTTP Server OPTIONS Memory Leak Vulnerability (OptionsBleed)
CVE: CVE-2017-9798
Description: Apache HTTP Server allows remote attackers to read data [...]
Installed version: 2.2.8
Fixed version: 2.4.28 (or equivalent patch for 2.2.34)
Impact: Allows unauthorized reading of memory blocks from the server.
Severity (CVSS): 5.0 (Medium)
Solution: Update to Apache HTTP Server 2.4.28 [...]
Detection method: Apache Web Server Detection (OID: 1.3.6.1.4.1.25623.1.0.900498)
References: http://openwall.com/lists/oss-security/2017/09/18/2 [...]

Tenable WAS:

Vulnerability name: Apache 2.4.x < 2.4.28 HTTP Vulnerability (OptionsBleed)
CVE: CVE-2017-9798
Description: Versions of Apache 2.4.x prior to 2.4.28 are affected by a vulnerability [...]
Installed version: 2.4.7
Fixed version: 2.4.28
Severity (CVSS): 7.5 (High, CVSSv3)
Solution: Update to Apache HTTP Server 2.4.28 [...]
Plugin ID: 98913
Family / Category: Web Server Vulnerability Component
References: https://httpd.apache.org/security/vulnerabilities_24.html#2.4.28 [...]

Описание: Одна и та же уязвимость описана по-разному:

• Названия полей: OpenVAS использует “Detection method”, Tenable — “Plugin ID”
• Severity: OpenVAS — 5.0 (Medium), Tenable — 7.5 (High) из-за разных версий CVSS
• Структура: OpenVAS даёт больше технических деталей (OID, метод обнаружения), Tenable фокусируется на управлении рисками (Plugin ID, категория)

Без явного маппинга LLM может:

• Создать две разные записи для одной уязвимости
• Перепутать поля (например, “Detection method” → “solution")
• Пропустить данные (не понять, что “Plugin ID” — это идентификатор метода обнаружения)

Контекст: Отчёт OpenVAS содержит уязвимость SSL/TLS с множеством полей (Summary, Impact, Solution, References). Задача — извлечь данные в унифицированный формат.

Было (исходный текст из PDF):

Summary: SSL/TLS: Deprecated TLSv1.0 and TLSv1.1 Protocol Detection

Vulnerability Detection Result: The remote service accepts connections with the deprecated TLSv1.0 and/or TLSv1.1 protocol.

Impact: An attacker might be able to use the known cryptographic flaws to eavesdrop the connection between clients and the service to get access to sensitive data transferred within the secured connection.

Solution: It is recommended to disable the deprecated TLSv1.0 and/or TLSv1.1 protocols in favor of the TLSv1.2+ protocols. Please see the references for more information.

Affected Software/OS: Services accepting connections with the deprecated TLSv1.0 and/or TLSv1.1 protocols.

Vulnerability Insight: The TLSv1.0 and TLSv1.1 protocols contain known cryptographic flaws like:
- Vulnerability to BEAST (Browser Exploit Against SSL/TLS) attacks
- Vulnerability to POODLE (Padding Oracle On Downgraded Legacy Encryption) attacks

References:
https://tools.ietf.org/html/rfc8996
https://www.openssl.org/blog/blog/2020/12/08/tls1.1-deprecation/
CVE: CVE-2011-3389, CVE-2014-3566

CVSS Base Score: 5.3 (Medium)

Стало (после извлечения с помощью GPT-4.1):

{
  "vulnerability_name": "SSL/TLS: Deprecated TLSv1.0 and TLSv1.1 Protocol Detection",
  "cve_id": "CVE-2011-3389, CVE-2014-3566",
  "description": "The remote service accepts connections with the deprecated TLSv1.0 and/or TLSv1.1 protocol. The TLSv1.0 and TLSv1.1 protocols contain known cryptographic flaws like vulnerability to BEAST and POODLE attacks.",
  "severity": "Medium",
  "cvss_score": "5.3",
  "impact": "An attacker might be able to use the known cryptographic flaws to eavesdrop the connection between clients and the service to get access to sensitive data transferred within the secured connection.",
  "solution": "It is recommended to disable the deprecated TLSv1.0 and/or TLSv1.1 protocols in favor of the TLSv1.2+ protocols.",
  "affected_component": "Services accepting connections with the deprecated TLSv1.0 and/or TLSv1.1 protocols",
  "references": [
    "https://tools.ietf.org/html/rfc8996",
    "https://www.openssl.org/blog/blog/2020/12/08/tls1.1-deprecation/"
  ]
}

Что изменилось и почему сработало:

• Маппинг полей: “Summary” → “vulnerability_name”, “Impact” → “impact”, “Solution” → “solution” — модель следовала явной инструкции
• Извлечение CVE: Из секции “References” извлечены CVE-2011-3389 и CVE-2014-3566 — правило “извлекай CVE из References” сработало
• Объединение данных: “Vulnerability Detection Result” и “Vulnerability Insight” объединены в “description” — модель поняла, что это части одного описания
• Стандартизация severity: “Medium” вместо “5.3 (Medium)” — правило “используй только Critical/High/Medium/Low/Info”
• Извлечение только URL: Из “References” взяты только ссылки, без описаний

Результат: Структурированная запись, готовая для загрузки в базу данных или ML-модель. ROUGE-L = 0.74 (высокое сходство с эталоном).

На чём тестировалось:

• Один отчёт OpenVAS с 34 уязвимостями
• Модели: GPT-4, GPT-4.1, Llama-3, Llama-4, DeepSeek
• Метрика: ROUGE-L (сходство с эталоном, созданным вручную двумя аналитиками)

Не тестировалось:

• Отчёты других сканеров (Nessus, Qualys, Acunetix)
• Большие отчёты (>100 уязвимостей)
• Отчёты на других языках (кроме английского)

Когда метод может не работать:

• Сложные таблицы и графики: PDF-парсинг может терять структуру таблиц → модель не видит связь между столбцами
• Нестандартные форматы: Если сканер использует кастомные поля, не описанные в маппинге → модель пропустит данные или заполнит NULL
• Очень длинные уязвимости: Если описание уязвимости >9000 символов → придётся разбивать на несколько chunks, что увеличивает риск потери контекста

Важные оговорки авторов:

• Качественная инспекция выявила дубликаты и ошибки маркировки, особенно для похожих уязвимостей (например, SSL/TLS)
• Llama-3/4 показали низкую точность (ROUGE-L <0.6) — не рекомендуются для критичных задач
• Метод требует ручной валидации результатов перед использованием в продакшене

Штраф за барьер (средний, -15):

• Нужно создать маппинг полей для своего сканера (если не OpenVAS/Tenable WAS)
• Настроить chunking под размер отчётов (авторы дают ~9000 символов, но это может не подойти)
• Реализовать валидацию и дедупликацию (нет готового кода)
• Адаптировать промпт под специфику своих отчётов (например, если сканер использует нестандартные поля)

Категория: Полезное

Главная ценность: Метод показывает, как превратить гетерогенные технические отчёты в унифицированный датасет с помощью LLM — это применимо не только к уязвимостям, но и к другим доменам (логи, инциденты, compliance-отчёты).

Кому полезно:

• Специалистам по информационной безопасности, работающим с большими объёмами отчётов сканеров
• ML-инженерам, создающим датасеты для моделей приоритизации уязвимостей
• DevSecOps-командам, автоматизирующим обработку результатов сканирования

Кому НЕ полезно:

• Тем, кто работает с одним сканером и не нуждается в унификации данных
• Тем, кто ищет готовое решение “из коробки” — метод требует адаптации
• Тем, кто работает с нестандартными форматами отчётов (не PDF) — потребуется доработка парсинга

Ресурсы:

• Код: https://github.com/AnonShield/Vulnerability_Extractor
• Отчёты RNP Security: https://www.rnp.br/publicacao/relatorio-anual-de-seguranca-de-2023