CVE

CVE — система уникальных идентификаторов для публично известных уязвимостей информационной безопасности. Она позволяет разработчикам, администраторам, исследователям и Security Tools однозначно понимать, о какой именно уязвимости идет речь.

Вместо длинного описания проблемы используется компактный идентификатор вида CVE-YYYY-NNNN, где YYYY обычно отражает год присвоения или публикационного цикла идентификатора, а последующая цифровая часть уникально отличает запись.

CVE не является оценкой опасности, эксплойтом или патчем. Это прежде всего стандартизированное имя конкретной уязвимости, к которому могут привязываться дополнительные сведения: описание, ссылки на Advisories, CVSS Score, информация о затронутых продуктах и исправлениях.

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

Что такое CVE простыми словами

Представим, что в популярном Server Software обнаружена уязвимость.

Vendor описывает ее в Security Advisory, Scanner показывает предупреждение, а SOC получает информацию из Threat Intelligence.

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

CVE решает эту задачу:

Vendor advisory
Scanner
SIEM
Threat Intelligence
Patch management
↓
CVE-YYYY-NNNNN

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

Расшифровка CVE

CVE расшифровывается как Common Vulnerabilities and Exposures.

Система создавалась как общий каталог имен для публично известных Security Problems.

Как выглядит CVE

Типичный идентификатор выглядит так:

CVE-2026-12345

Он состоит из:

Количество цифр в последней части не обязательно ограничивается четырьмя.

Что описывает CVE

Запись обычно позволяет определить:

• уязвимый продукт или компонент;
• характер Security Problem;
• публичные References;
• Vendor Advisory;
• связанные данные других Security Databases.

Более подробный технический анализ часто находится не в самой CVE-записи, а в документации Vendor, исследовательских публикациях и Vulnerability Databases.

CVE и уязвимость

Уязвимость — это реальная слабость в Software, Hardware или Configuration.

CVE — идентификатор, присвоенный конкретной публично известной проблеме.

Есть ли CVE у каждой уязвимости

Нет. Не каждая Security Problem обязательно получает публичный CVE Identifier.

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

CVE и Zero-day

Zero-day Vulnerability может существовать до появления публичной CVE-записи.

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

CVE и эксплойт

Наличие CVE не означает, что для уязвимости существует публичный рабочий Exploit.

Возможны разные состояния:

CVE exists
↓
No public exploit
or
PoC available
or
Exploit publicly available
or
Active exploitation observed

Для приоритизации Patch важно понимать, какой из сценариев относится к конкретной проблеме.

CVE и Proof of Concept

PoC может демонстрировать, что уязвимость действительно воспроизводится.

Но CVE Identifier может существовать и без опубликованного Proof of Concept.

CVE и Malware

CVE описывает уязвимость, а Malware — вредоносное программное обеспечение.

Malware может использовать Exploit для определенного CVE, но эти понятия не являются взаимозаменяемыми.

CVE и CVSS

CVSS — система оценки технической критичности Vulnerability.

CVE отвечает на вопрос:

Какая это уязвимость?

CVSS помогает ответить:

Насколько технически серьезной может быть эта уязвимость?

CVE не имеет встроенного уровня критичности

Сам идентификатор вида CVE-2026-12345 ничего не говорит о Severity.

Для оценки нужно смотреть дополнительные данные, включая CVSS, Vendor Advisory и Business Context.

Что такое CVSS Score

CVSS может формировать числовой Score на основании характеристик эксплуатации и последствий.

Однако Score нельзя использовать как единственный критерий Patch Priority.

Почему CVSS недостаточно

Две уязвимости с одинаковой технической оценкой могут иметь совершенно разный риск для компании.

Например:

Даже при похожем CVSS приоритет первой проблемы будет выше.

CVE и CWE

CWE, или Common Weakness Enumeration, описывает классы и типы программных слабостей.

CVE относится к конкретной уязвимости в конкретном продукте, а CWE — к более общей категории проблемы.

Пример связи CVE и CWE

CWE: class of weakness
↓
Specific implementation error
↓
CVE: concrete vulnerability

Например, разные продукты могут иметь отдельные CVE, но относиться к одному классу CWE.

CVE и CPE

CPE используется для стандартизированного описания продуктов и платформ.

Vulnerability Databases могут связывать CVE с конкретными Product Names и Versions через подобные идентификаторы.

CVE и Vendor Advisory

Security Advisory производителя часто является одним из наиболее важных источников информации о конкретной Vulnerability.

Vendor может указать:

• затронутые версии;
• исправленные версии;
• Workaround;
• условия эксплуатации;
• рекомендации по обновлению.

Почему Vendor Advisory важнее одного номера CVE

CVE дает ссылочную точку, но для эксплуатации инфраструктуры нужна конкретика.

Например, один Product может содержать исправление через Backport без очевидного изменения Major Version.

Поэтому вывод только по номеру версии иногда бывает ошибочным.

CVE и Patch

Patch устраняет или снижает риск конкретной уязвимости.

Одна Update может исправлять сразу несколько CVE.

Security update
↓
CVE-A fixed
CVE-B fixed
CVE-C fixed

И наоборот, один CVE может требовать разных Patches для разных Branches продукта.

CVE и Patch Management

Patch Management Systems используют CVE для сопоставления Installed Software с известными Vulnerabilities.

Это позволяет формировать список Assets, требующих обновления.

Типичный процесс работы с CVE

1. Получить информацию о новом CVE.
2. Определить затронутые продукты.
3. Найти соответствующие Assets.
4. Оценить Exposure и Business Criticality.
5. Проверить наличие Exploitation.
6. Установить Patch или применить компенсирующую меру.
7. Проверить результат.

Asset Inventory

Без инвентаризации CVE Catalog имеет ограниченную пользу.

Компания должна понимать, какие продукты и версии реально используются.

Иначе невозможно быстро ответить:

У нас есть эта уязвимость?

CMDB и CVE

CMDB может хранить информацию о Servers, Applications и Owners.

При появлении критичного CVE Security Team связывает Vulnerability с конкретным Business Service и ответственным сотрудником.

Software Inventory

Для полноценного Vulnerability Management полезно знать не только операционные системы, но и:

• Libraries;
• Containers;
• Web Servers;
• Database Systems;
• VPN Gateways;
• Network Appliances;
• Agents;
• Firmware.

SBOM и CVE

Software Bill of Materials содержит перечень компонентов продукта.

При публикации нового CVE компания может быстрее проверить, входит ли затронутая Library в ее Applications.

Транзитивные зависимости

Приложение может не использовать уязвимую библиотеку напрямую.

Она может быть зависимостью другой Dependency.

Application
↓
Library A
↓
Library B vulnerable

Поэтому Dependency Analysis должен учитывать всю цепочку.

CVE и Dependency Scanner

Software Composition Analysis сравнивает используемые Packages с Vulnerability Databases и сообщает связанные CVE.

Это удобно для CI/CD и разработки.

False Positive при CVE Scanner

Scanner может определить Vulnerability по версии Package, хотя исправление уже было Backported Vendor.

Или уязвимый Component может присутствовать, но фактически не использоваться.

Поэтому автоматический результат требует контекста.

False Negative

Scanner также может не обнаружить Vulnerability, если Software установлено нестандартно, компонент не идентифицирован или информация о CVE отсутствует в используемой базе.

Authenticated Vulnerability Scanning

Authenticated Scanner получает доступ к информации об установленных Packages и Patches непосредственно из OS.

Это часто дает более точный результат, чем анализ только Network Banner.

Network Vulnerability Scanner

Network Scanner определяет открытые Services и пытается сопоставить их с известными Vulnerabilities.

Он особенно полезен для поиска Internet-facing и сетевых Assets.

CVE и Vulnerability Management

Vulnerability Management шире простого списка CVE.

Он включает:

• Discovery;
• Assessment;
• Prioritization;
• Remediation;
• Verification;
• Reporting.

Почему список CVE не является управлением уязвимостями

Компания может иметь 20 000 Findings, но без Owners, сроков устранения и приоритетов этот список мало влияет на Security.

Risk-based Vulnerability Management

Приоритет формируется с учетом:

• Severity;
• Exploitability;
• Active Exploitation;
• Asset Criticality;
• Internet Exposure;
• Data Sensitivity;
• доступных защитных мер.

CVE и Internet-facing Assets

Уязвимость на публичном Web Server обычно требует более быстрой реакции, чем аналогичная проблема на выключенной Test VM.

Exposure является важной частью Risk.

CVE и Active Exploitation

Если есть надежные данные о реальных атаках с использованием Vulnerability, это существенно повышает приоритет.

Security Team должна отличать теоретический PoC от подтвержденной эксплуатации.

CVE и Threat Intelligence

Threat Intelligence дополняет техническое описание информацией о том, как Vulnerability используется в реальных атаках.

Можно получить сведения о:

• Threat Actors;
• Malware;
• Exploit Availability;
• Target Industries;
• Indicators of Compromise.

CVE и SOC

SOC использует CVE Context при расследовании.

Если на Web Server обнаружена Vulnerability, SOC может проверить, были ли в Logs признаки ее эксплуатации.

CVE и SIEM

SIEM может обогащать Security Events информацией о Vulnerabilities Assets.

Например:

Suspicious network request
+
Host has critical CVE
↓
Higher incident priority

CVE и EDR

EDR может не заниматься каталогизацией всех CVE напрямую, но предоставляет Telemetry о возможных последствиях Exploitation.

Например, после атаки на уязвимый Web Server появляется необычный дочерний Process.

CVE и XDR

XDR способен объединить Vulnerability Context с Endpoint, Identity и Network Signals.

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

CVE и WAF

Для некоторых Web Vulnerabilities WAF может предоставлять временную компенсирующую защиту.

Но наличие WAF не означает, что CVE можно никогда не исправлять.

Virtual Patching

Virtual Patch — временное правило на WAF, IPS или другом Security Control, которое блокирует известный Exploit Pattern.

Это полезно, если официальный Patch нельзя установить немедленно.

Причина Vulnerability при этом остается в Software.

CVE и Firewall

Firewall может снизить Exposure.

Например, уязвимый Management Interface доступен только из Administrative Network.

Это уменьшает вероятность Remote Exploitation, но не устраняет Vulnerability.

CVE и Zero Trust

Zero Trust помогает ограничить последствия успешной эксплуатации.

Если Vulnerable Server скомпрометирован, его Identity не должна автоматически иметь доступ ко всей инфраструктуре.

CVE и Least Privilege

Уязвимый Service, запущенный от непривилегированного Account, обычно предоставляет атакующему меньший начальный уровень доступа.

Это пример Defense in Depth.

CVE и сегментация

Network Segmentation ограничивает Lateral Movement после компрометации.

Публичный Web Server не должен иметь административный доступ ко всем внутренним Servers.

CVE и Cloud

Cloud Environment также содержит уязвимые компоненты:

• Virtual Machines;
• Container Images;
• Libraries;
• Kubernetes Components;
• Network Appliances;
• Self-managed Databases.

Managed Service может перераспределять ответственность за Patch, но не отменяет необходимость следить за Security Advisories.

CVE и контейнеры

Container Image может содержать множество Packages с известными CVE.

Container Scanner сравнивает их версии с Vulnerability Database.

Наличие CVE в Container Image не всегда означает одинаковый риск

Важно учитывать, используется ли уязвимый компонент во время Runtime, доступен ли соответствующий Code Path и какие Permissions имеет Container.

Base Image

Устаревший Base Image может постепенно накапливать известные Vulnerabilities.

Поэтому Images необходимо регулярно пересобирать на актуальной базе.

CVE и Kubernetes

В Kubernetes Vulnerability может находиться в:

• Cluster Component;
• Container Runtime;
• Application Image;
• Ingress Controller;
• Operator;
• стороннем Plugin.

Asset Inventory должен охватывать весь Stack.

CVE и CI/CD

Dependency и Container Scanning можно встроить в Pipeline.

Source code
↓ build
Dependency scan
↓
Container scan
↓
Deploy

Так уязвимые Components обнаруживаются еще до Production.

Нужно ли блокировать Build при любом CVE

Полный запрет на любой Vulnerability Finding может сделать Pipeline непрактичным.

Обычно политика учитывает Severity, Exploitability, наличие Fix и исключения с ограниченным сроком.

CVE и Open Source

Open Source Library может использоваться тысячами продуктов.

Один CVE в популярной Dependency способен затронуть большое количество компаний, даже если они не знали о прямом использовании компонента.

CVE и коммерческий Software

Commercial Vendor также публикует Security Advisories и Updates для своих продуктов.

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

CVE и End-of-Life Software

Особенно опасна ситуация, когда Vulnerability обнаружена в продукте, который больше не поддерживается.

Patch может вообще не появиться.

Тогда требуется:

• Upgrade;
• Migration;
• изоляция;
• дополнительные компенсирующие меры.

Legacy System

Старое приложение часто невозможно быстро обновить из-за совместимости с бизнес-процессом.

Это не делает CVE менее опасным.

Риск необходимо формально принять, снизить или устранить через Migration.

CVE и SLA на исправление

Организации часто устанавливают внутренние сроки устранения Vulnerabilities.

Например, Critical Internet-facing Findings исправляются быстрее, чем Low Severity проблемы во внутренних Test Environments.

Exception Process

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

Исключение должно иметь Owner и Expiration Date.

Почему бессрочные исключения опасны

В противном случае временное решение превращается в постоянную Vulnerability Debt.

Vulnerability Debt

Если организация постоянно откладывает Patches, количество известных проблем растет.

Со временем обновление становится сложнее и рискованнее.

CVE и Change Management

Security Update может влиять на бизнес-приложение, поэтому Patch часто проходит через Test и Change Process.

Но слишком медленная процедура также увеличивает окно Exposure.

Emergency Patch

Если Vulnerability активно эксплуатируется, организация может использовать ускоренную процедуру изменения.

Для этого Emergency Process лучше разработать заранее.

CVE и Backport

Vendor может перенести Security Fix в старую поддерживаемую версию, не меняя ее на последнюю основную ветку.

Поэтому простое сравнение версии с публичным списком иногда дает неправильный вывод.

Почему Banner Version может вводить в заблуждение

Web Server может показывать старый Version String, хотя Distribution Vendor уже применил необходимый Security Patch.

Нужно учитывать Package Revision и Vendor Advisory.

CVE и Configuration Vulnerability

Не каждая проблема конфигурации получает CVE.

Например, публично доступная Database из-за неправильного Firewall Rule может быть критичным Security Finding, хотя никакой программной Vulnerability нет.

Почему нельзя ограничивать безопасность только CVE

Реальные атаки используют не только Software Bugs, но и:

• слабые Passwords;
• ошибочные Permissions;
• утечки Tokens;
• Phishing;
• Misconfiguration;
• Social Engineering.

Поэтому CVE Management — только один компонент Cybersecurity.

CVE и Supply Chain

Если уязвимый Component входит в большое число продуктов через Dependency, она превращается в Software Supply Chain Risk.

SBOM и Dependency Inventory помогают быстрее определить Exposure.

CVE и Firmware

Уязвимости могут существовать не только в обычных Applications, но и в Firmware Router, Storage, Server Controllers и других устройств.

Такие Assets также требуют обновлений.

CVE и сетевое оборудование

Firewall, VPN Gateway и Load Balancer сами являются Software Systems.

Особенно опасны Vulnerabilities в устройствах, доступных непосредственно из Internet.

CVE в Security Product

Антивирус, EDR или Firewall тоже могут иметь Vulnerabilities.

Наличие Security-функции не делает продукт автоматически неуязвимым.

Как читать информацию о CVE

При анализе полезно последовательно ответить на вопросы:

1. Какой продукт затронут?
2. Какие Versions уязвимы?
3. Какие условия нужны для Exploitation?
4. Какой потенциальный Impact?
5. Есть ли рабочий Exploit?
6. Наблюдается ли Active Exploitation?
7. Есть ли Patch?
8. Используем ли мы этот продукт?

Приоритет CVE для бизнеса

Практический Priority можно представить логически:

Technical severity
+
Exploitability
+
Exposure
+
Asset criticality
+
Threat intelligence
=
Business priority

Это полезнее сортировки только по CVSS.

Пример низкого практического риска

Critical CVE найден на выключенной Test VM, которая не имеет Network Access и будет удалена завтра.

Технический Score может оставаться высоким, но Business Risk ограничен.

Пример высокого практического риска

High Severity CVE находится на публичном VPN Gateway, существует известная эксплуатация, а через систему проходят удаленные подключения сотрудников.

Такой Finding требует существенно более быстрой реакции.

CVE и Incident Response

Если Vulnerability уже эксплуатируется, Patch Management превращается в Incident Response.

Недостаточно просто установить Update.

Что делать при подозрении на эксплуатацию CVE

Необходимо:

1. ограничить Exposure;
2. сохранить необходимые Logs;
3. проверить EDR и Network Telemetry;
4. искать Persistence;
5. отозвать потенциально скомпрометированные Credentials;
6. установить исправление;
7. проверить другие Assets.

Patch после компрометации

Обновление закрывает Vulnerability, но не удаляет автоматически Backdoor, созданный ранее атакующим.

Поэтому при подтвержденной Exploitation требуется восстановление доверенного состояния системы.

CVE и Threat Hunting

После появления информации о новой активно эксплуатируемой Vulnerability SOC может выполнить ретроспективный поиск.

Проверяется Telemetry за период до установки Patch.

CVE и IoC

Security Advisory может содержать Indicators of Compromise, связанные с эксплуатацией:

• IP;
• Domain;
• File Hash;
• Process;
• File Path.

Но отсутствие совпадения с известными IOC не гарантирует отсутствие атаки.

CVE и Behavioral Detection

Поведенческие признаки часто полезнее одного IOC.

Например, Web Server неожиданно создает Command Interpreter после входящего HTTP Request.

Типичные ошибки при работе с CVE

1. Считать любой CVE критичным без контекста.
2. Считать высокий CVSS достаточным для приоритизации.
3. Игнорировать Active Exploitation.
4. Не вести Asset Inventory.
5. Определять Vulnerability только по Version Banner.
6. Не учитывать Backported Patches.
7. Считать отсутствие Public Exploit гарантией безопасности.
8. Оставлять исправления без проверки установки.
9. Считать WAF полной заменой Patch.
10. Игнорировать Vulnerabilities в Dependencies и Firmware.

Как построить процесс работы с CVE

Шаг 1. Создать Asset Inventory

Нужно понимать, какое Software работает в инфраструктуре.

Шаг 2. Получать Vulnerability Data

Используйте Vendor Advisories, Vulnerability Scanner и другие доверенные Sources.

Шаг 3. Сопоставлять CVE с Assets

Определяйте конкретные Servers, Containers и Applications.

Шаг 4. Оценивать реальный риск

Учитывайте Exposure, Exploitability и Business Criticality.

Шаг 5. Назначать Owner

У каждого Finding должен быть ответственный за Remediation.

Шаг 6. Устранять Vulnerability

Установите Patch, Upgrade или примените временную защиту.

Шаг 7. Проверять результат

Повторное сканирование подтверждает, что проблема действительно устранена.

Шаг 8. Анализировать метрики

Следите за сроками исправления и количеством просроченных Findings.

Полезные метрики

CVE и бизнес-процессы

Vulnerability Management становится эффективным только тогда, когда связан с Owners и Business Services.

Security Team должна понимать не только IP Address уязвимого Server, но и какой процесс он поддерживает: CRM, производство, бухгалтерию или клиентский портал.

CVE и 1С-инфраструктура

При эксплуатации 1С следует учитывать Vulnerabilities не только самой платформы, но и всей связанной инфраструктуры.

В нее могут входить:

• операционная система;
• Database Server;
• Web Server;
• Remote Access;
• Virtualization Platform;
• Backup Software;
• сетевые устройства.

Без комплексной инвентаризации отдельное обновление 1С не гарантирует отсутствие известных Vulnerabilities вокруг нее.

Практический пример

Security Scanner обнаруживает новый CVE на трех Servers компании.

Все Findings имеют одинаковую техническую Severity.

Первый Server — публичный VPN Gateway.

Второй — внутренний File Server.

Третий — выключенная Test VM.

Threat Intelligence сообщает, что соответствующая Vulnerability уже используется в реальных атаках против Internet-facing систем.

Компания устанавливает следующий приоритет:

VPN Gateway → emergency remediation
File Server → scheduled urgent patch
Test VM → decommission

После обновления VPN Gateway SOC дополнительно проверяет исторические Authentication и Network Logs на признаки Exploitation.

Таким образом, один и тот же CVE получил разный Business Priority в зависимости от Asset Context.

CVE для бизнеса

CVE дает компании единый язык для работы с уязвимостями. Один идентификатор можно использовать в Scanner, Change Request, Incident Ticket, Vendor Advisory и отчете SOC.

Но ценность системы появляется только вместе с Asset Inventory и процессом Remediation. Сам по себе список из тысяч CVE не улучшает Security.

Зрелый подход заключается в том, чтобы быстро определить, какие CVE действительно относятся к инфраструктуре, насколько Assets доступны атакующему и существует ли реальная Exploitation.

Преимущества CVE

• единые идентификаторы Vulnerabilities;
• удобное сопоставление разных Security Sources;
• интеграция с Scanner и SIEM;
• связь с Vendor Advisories;
• упрощение Patch Management;
• поддержка автоматизации Vulnerability Management;
• удобная коммуникация между командами.

Ограничения CVE

• идентификатор не показывает Business Risk;
• не каждая проблема имеет CVE;
• наличие CVE не означает наличие Exploit;
• CVE не заменяет Vendor Advisory;
• не описывает все Misconfigurations;
• автоматическое сопоставление Versions может ошибаться;
• не заменяет полноценный Vulnerability Management.

Когда использовать CVE

CVE следует использовать как стандартную ссылку на конкретную публично известную уязвимость при работе с Security Advisories, Scanner Findings, Patches, Incident Response и Threat Intelligence.

При принятии решения о срочности исправления номер CVE необходимо дополнять контекстом конкретного Asset и данными об актуальных угрозах.

Связанные термины

Краткий итог

CVE — Common Vulnerabilities and Exposures, система уникальных идентификаторов публично известных уязвимостей. Она позволяет разработчикам, администраторам, Scanner, SOC и Vendors однозначно ссылаться на одну и ту же Security Problem.

CVE не является оценкой опасности, Exploit или Patch. Для определения реального риска необходимо учитывать CVSS, наличие активной эксплуатации, доступность уязвимого Asset, критичность бизнес-системы и рекомендации производителя.

Эффективная работа с CVE требует Asset Inventory, Vulnerability Scanning, Patch Management, Threat Intelligence и проверки результата исправления. Главная задача бизнеса — не просто знать список CVE, а быстро определить, какие из них действительно создают риск для конкретной инфраструктуры.