Поиск и предотвращение уязвимостей в ПО: эффективные методики

Уязвимости стабильно остаются одной из наиболее популярных техник первичного проникновения: так, по данным отчета Verizon (2025 Data Breach Investigations Report), эксплуатация уязвимостей использовалась в 20% успешных кибератак, при этом особое внимание злоумышленники уделяли уязвимостям в пограничных сетевых устройствах.

По-прежнему активно используются 0-Day уязвимости: по данным исследования компании F6 (бывшая F.A.C.C.T., бывшая Group-IB), стоимость эксплойтов и уязвимостей нулевого дня в Darknet составляет до $250000, а по данным отчета IBM (Cost of a Data Breach Report 2024), сдерживание 0-Day кибератак занимает в среднем 69 дней — это максимальный показатель по сравнению с другими векторами первичного проникновения. Проблема обнаружения, устранения и предотвращения эксплуатации уязвимостей до сих пор актуальна, особенно в свете ставшей широко популярной внутренней разработки и перехода на Open Source, ухода зарубежных вендоров и недоступности официальных каналов получения обновлений, использования атакующими ИИ для разработки эксплойтов и различных организационных сложностей в работе реестров уязвимостей.

Необходимость повышения уровня цифровизации бизнеса приводит к увеличению потребности в средствах автоматизации, но если среди доступных коммерческих или Open Source решений нет подходящего, то компании выбирают либо заказную разработку ПО, либо — особенно в случае крупных корпораций — стремятся глубоко кастомизировать или разрабатывать «с нуля» нужный софт силами внутренней ИТ-команды.

В этом случае важно соблюдать лучшие практики и рекомендации по разработке ПО, управлять процессом разработки и обеспечивать его необходимыми ресурсами, но тут появляется соблазн расценивать внутреннюю разработку ПО как некую опциональную активность, особенно в организациях, для которых разработка ПО – непрофильное направление. В этом случае процессам разработки будет уделено меньше внимания, чем следует — это и станет корневой причиной возникновения уязвимостей в ПО, которые могут в дальнейшем привести к существенным потерям для компании. Для того, чтобы структурировать процесс внутренней разработки ПО, важно выбрать подходящий стандарт или фреймворк для создания безопасного ПО, например:

• Стандарт ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;
• Стандарт ГОСТ Р 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»;
• Серия стандартов ISO/IEC 27034 «Information technology — Security techniques — Application security»;
• Серия стандартов ISO/IEC 24772 «Programming languages — Avoiding vulnerabilities in programming languages»;
• Фреймворк NIST «Secure Software Development Framework (SSDF)»;
• Фреймворк BSA «Framework for Secure Software».

Важную роль играет и планомерное внедрение методологии AppSec, которая включает в себя набор процессов, практик и инструментов для выявления, устранения и защиты от уязвимостей и недостатков в рамках жизненного цикла разработки ПО. Среди AppSec-процессов и практик могут быть:

• Построение жизненного цикла разработки безопасного ПО (SSDLC, Secure Software Development Lifecycle);
• Внедрение стратегии «Shifting Left» («сдвиг влево»), которая подразумевает максимально ранее включение вопросов безопасности в жизненный цикл разработки продуктов;
• Внедрение подходов DevSecOps (включая использование лучших практик, например, от MITRE), Security-as-code, Policy-as-code с интеграцией в CI/CD/CS-пайплайны;
• Использование инструментов автоматизации, например, анализаторов кода (SAST, DAST, IAST), решений для тестирования безопасности API (API Security Testing) и поиска «секретов» в коде (API-ключей, паролей, токенов), продуктов для управления поверхностью атаки (DRP — Digital Risk Protection, ASM — Attack Surface Management), а также решений для управления безопасностью ПО на всех этапах жизненного цикла (ASPM — Application Security Posture Management, ASOC — Application Security Orchestration and Correlation, CNAPP — Cloud-Native Application Protection Platforms);
• Управление инцидентами AppSec: обработка сообщений об уязвимостях, анализ и устранение уязвимостей, повышение безопасности разработки;
• Запуск программ Bug Bounty, проведение пентестов и киберучений, непрерывное обучение разработчиков и инженеров правилам безопасной разработки и внедрения ПО.

Кроме средств автоматизации и современных подходов, не следует забывать и про классические каталоги уязвимостей и угроз от организации MITRE, которые позволяют проследить взаимосвязь между уязвимостями, их причинами (ошибками программирования) и методами их эксплуатации:

1) Реестр уязвимостей MITRE CVE, несмотря на определенные организационные сложности, о которых мы поговорим ниже, продолжает оставаться главным международным источником данных о зарегистрированных уязвимостях. Каталог MITRE CVE тесно связан с реестрами MITRE CWE и MITRE CAPEC: для уязвимостей в процессе их анализа добавляется информация о причинах их возникновения (CWE ID) и методы возможной эксплуатации (CAPEC ID);

2) Реестр недостатков программирования MITRE CWE (Common Weakness Enumeration, общий классификатор недостатков) содержит классификатор ошибок (дефектов, недостатков), допускаемых при разработке программного и аппаратного обеспечения, которые в итоге приводят к возникновению уязвимостей, а по итогам года формируется список наиболее опасных ошибок «CWE Top 25«. Ошибки программирования, описанные в реестре CWE, подчиняются строгой иерархии:

1. Pillar — наиболее высокоуровневый, абстрактный тип ошибок;
2. Class — более специфичное описание ошибок, но независимое от языка программирования или используемой технологии;
3. Base — описание ошибки с указанием конкретных методов её выявления и предотвращения;
4. Variant — ошибка, связанная с определенным типом программного продукта, языком программирования, используемой технологией.

3) Реестр методов эксплуатации недостатков и уязвимостей MITRE CAPEC (Common Attack Pattern Enumeration and Classification, общая система перечисления и классификации шаблонов атак) содержит описание используемых злоумышленниками шаблонов атак с эксплуатацией уязвимостей в ПО. Данный реестр также подчиняется определенной иерархии, в которой схемы атак классифицированы по механизмам и доменам и содержат следующие уровни абстракции:

1. Category — набор шаблонов атак, объединенных одной целью и последствиями для жертвы;
2. Meta Attack Pattern — абстрактное описание методологии или техники атаки;
3. Standard Attack Pattern — описание конкретной методологии или техники атаки, дающее понимание шагов злоумышленника для достижения цели;
4. Detailed Attack Pattern — детальное описание конкретной техники атаки и эксплуатируемой технологии с указанием последовательности шагов, выполняемых злоумышленником для реализации атаки (Explore – Experiment – Exploit).

Описанные в MITRE CAPEC методы эксплуатации связаны типами ошибок из реестра CWE, а также с описаниями техник и подтехник из матрицы MITRE ATT&CK, из проекта OWASP, из проекта WASC. Например, описание атаки отравления кэша DNS (CAPEC-142: DNS Cache Poisoning) на уровне абстракции «Detailed» связано с описанной в ATT&CK подтехникой компрометации DNS-сервера (T1584.002 Compromise Infrastructure: DNS Server) и с рядом ошибок при разработке — например, с ошибкой типа «Недостаточной верификацией подлинности данных» (CWE-345: Insufficient Verification of Data Authenticity), которая привела к возникновению ряда уязвимостей, например, CVE-2022-30272. Более высокоуровневое описание атаки отравления кэша без привязки к конкретной технологии (CAPEC-141: Cache Poisoning) на уровне абстракции «Standard» связано с описанной в проекте OWASP атакой отравления кэша (Cache Poisoning). Если же подниматься по иерархии CAPEC ещё выше, то на «родительском» уровне Meta описана атака через манипуляцию инфраструктурой (CAPEC-161: Infrastructure Manipulation), которая в свою очередь является дочерней для описанной на уровне Category атаки манипуляции системными ресурсами (CAPEC-262: Manipulate System Resources).

Аналогичная иерархия выстроена и для записей в реестре CWE: например, уязвимость с идентификатором CVE-2020-10987 появилась из-за ошибки программирования типа «Инъекция команд ОС» (CWE-78: OS Command Injection, уровень абстракции «Base») является дочерней для ошибки более общего типа «Инъекция команд» (CWE-77: Command Injection, уровень абстракции «Class»), которая в свою очередь является дочерней для более общего типа ошибок с идентификаторами CWE-74 («Инъекция») и CWE-707 («Некорректная нейтрализация»). Кроме описания ошибок программирования, проект MITRE CWE также поддерживает фреймворк анализа рисков и оценки опасности недостатков ПО с привязкой к бизнес-контексту приложений (CWRAF, Common Weakness Risk Analysis Framework), который можно использовать совместно с системой приоритизации недостатков ПО (CWSS, Common Weakness Scoring System). Еще один фреймворк MITRE SAF (Security Automation Framework) можно использовать для выбора и применения средств автоматизации при формировании и проверке выполнения требований по безопасности создаваемого ПО с поддержкой DevSecOps-пайплайнов. Таким образом, используя данные проектов MITRE CVE, CWE, CAPEC, ATT&CK и методологии CWRAF, CWSS, SAF, можно систематизировать процесс приоритизации уязвимостей и недостатков при разработке ПО, увязав его с моделированием угроз (например, по методике MITRE) и управлением рисками разработки информационных систем (например, по методике MITRE).

Если же вендор не сумел выявить потенциальную уязвимость на этапах разработки, сборки или тестирования ПО, то она может быть обнаружена в дальнейшем или самим разработчиком, или пользователями, или ИБ-компаниями, или злоумышленниками, которые могут разработать для неё 0-Day эксплойт и использовать его для атак либо продать в Darknet. Однако, даже обнаружение уязвимости не гарантирует её классификацию и учёт: например, наблюдения показали, что в реестре MITRE CVE не учитываются в среднем 33% уязвимостей по сравнению с альтернативными системами классификации, а сам реестр недавно подвергся риску нарушения функционирования из-за возможных перерывов в финансировании (однако, в последний момент проблем с бюджетом удалось избежать). Реестр NIST NVD, в котором учтенные в классификаторе CVE уязвимости проверяются, обогащаются и оцениваются по системе CVSS, также не лишён недостатков — например, прослеживается отставание между полученными и проанализированными командой NVD уязвимостями (на момент написания статьи лаг составлял около 20% с начала 2025 года). В сложившихся условиях можно порекомендовать использовать альтернативные каталоги уязвимостей, например:

• БДУ ФСТЭК России https://bdu.fstec.ru/vul
• European Union Vulnerability Database EUVD https://euvd.enisa.europa.eu/
• China National Vulnerability Database CNNVD https://www.cnnvd.org.cn/
• Open Source Vulnerability Database https://osv.dev/
• GitHub Advisory Database https://github.com/advisories

Мониторинг попыток эксплуатации уязвимостей также важен для анализа кибератак, атрибутирования злоумышленников и определения дальнейших шагов по противодействию. Данные киберразведки содержат в том числе информацию об уязвимостях, которые характерны для почерка тех или иных кибергрупп, и перечень «трендовых» уязвимостей, которые используются в реальных атаках, а также сведения о разрабатываемых или приобретаемых эксплойтах. Информация о популярных уязвимостях и публичных PoC-эксплойтах должна быть проверена на применимость в конкретной инфраструктуре с использованием методов контролируемого пентеста.

Таким образом, обработка данных киберразведки помогает приоритизировать уязвимости и в первую очередь обработать те, которые будут эксплуатироваться с высокой вероятностью, а также скорректировать порядок действий при реагировании на киберинцидент — например, выявить и пресечь характерные для кибергруппы техники закрепления, повышения привилегий, сокрытия следов присутствия и дальнейшего горизонтального перемещения.

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

С учетом описанных вызовов, наше решение Security Vision NG VM выполняет агрегацию данных об уязвимостях из официальных реестров (включая БДУ ФСТЭК России, NIST NVD, MITRE CVE, Microsoft, различные Linux-дистрибутивы) и получает дополнительную аналитическую информацию о характеристиках и возможности эксплуатации уязвимости (например, с ресурсов AttackerKB, OpenCVE, VulDB, Vulners). Поддерживается приоритизация уязвимостей в соответствии с рекомендациями документа «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств» ФСТЭК России, с учетом опасности и распространенности конкретной уязвимости (список трендовых уязвимостей формируется в том числе аналитиками Security Vision), поддерживается также использование логики деревьев принятия решений с учетом CVSS-метрик уязвимостей и свойств уязвимого актива.

Для проверки эксплуатируемости уязвимости можно применять режим контролируемого пентеста, использовать ретро-сканирование (для сокращения времени обнаружения уязвимостей) и функционал мульти-сканера с возможностью импортировать данные из внешних сканеров уязвимостей. Для эффективного устранения уязвимостей можно использовать функционал автопатчинга (автоматическая установка обновлений), автоматически применять или восстанавливать безопасные конфигурации систем, синхронизировать заявки на устранение уязвимостей с внешними таск-трекерами и HelpDesk-продуктами.

Совместное применение решений Security Vision NG VM с продуктами Security Vision TIP, Security Vision UEBA, Security Vision AD+ML и Security Vision NG SOAR, объединенными на единой low-code/no-code платформе, позволяет обогащать информацию по уязвимостям данными киберразведки, анализировать поведение сущностей и выявлять аномалии в инфраструктуре за счет применения методов машинного обучения, а также централизованно управлять киберинцидентами с учетом данных об активах, уязвимостях и активно применяемых эксплойтах, индикаторов компрометации и атак, сведений о событиях и аномалиях в защищаемой сети.

Автор: Руслан Рахметов, Security Vision.