Архив метки: CVE

Итоговое количество CVE уязвимостей, которые были добавлены в 2025 году - 48185

Добавить комментарий

Итоговое количество CVE уязвимостей, которые были добавлены в 2025 году - 48185

Итоговое количество CVE уязвимостей, которые были добавлены в 2025 году - 48185. Об этом пишет Jerry Gamblin, разработчик CVE.icu, и я ему доверяю. 👌

Здесь возникает соблазн сказать, что этот набор CVEшек является каким-то осмысленным. Например, что это ВСЕ уязвимости, которые были обнаружены за прошлый год. А далее схватиться за голову: "Ах, как много!" 😱 И начать продвигать идеи, что их все невозможно устранять безусловным патчингом, необходимо выделять и патчить ТОЛЬКО самые критичные ИЗ НИХ. А в этом вам помогут наши решения… СТОП!

Беда в том, что это НЕ все уязвимости, найденные за прошлый год. Это уязвимости, заведённые некоторым клубом CNA организаций. Огромная разница! Почему именно эти организации в клубе? Почему одни заводят очень много CVEшек, а другие ничего? Как эти CVEшки соотносятся с инфраструктурой конкретной организации в локации X?

Нам до необходимого описания ВСЕХ уязвимостей, как до луны пёхом. А 48185? Просто цифирь. 😉

Американский аналитик уязвимостей Jerry Gamblin подсветил интересную аномалию: несмотря на общую многолетнюю тенденцию к ускорению прироста количества CVE идентификаторов, в ноябре 2025 года их было опубликовано рекордно мало!

Добавить комментарий

Американский аналитик уязвимостей Jerry Gamblin подсветил интересную аномалию: несмотря на общую многолетнюю тенденцию к ускорению прироста количества CVE идентификаторов, в ноябре 2025 года их было опубликовано рекордно мало!

Американский аналитик уязвимостей Jerry Gamblin подсветил интересную аномалию: несмотря на общую многолетнюю тенденцию к ускорению прироста количества CVE идентификаторов, в ноябре 2025 года их было опубликовано рекордно мало!

Мы упали с 4 086 публикаций в ноябре 2024 года до 2 900 в ноябре 2025 года. Это колоссальное снижение на 1 186 CVE (-29% год к году)!

Откуда взялось это падение? Почти 800 из этих «пропавших» CVE пришлись всего на три источника, которые замедлились по сравнению с прошлым годом:
1️⃣ Patchstack: - 444 CVE (падение примерно на 67%)
2️⃣ MITRE: - 175 CVE
3️⃣ Linux Kernel: - 174 CVE

Эти данные отлично демонстрируют, что "Global CVE Counts" часто определяется административными процессами всего в нескольких ключевых игроках (CNA).

Что явилось причиной такого замедления пока непонятно. Возможно в этом году какой-то особенный Thanksgiving. 🙂🦃 Также в кулуарах упоминают "retooling" в компании Patchstack.

KEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживую

Добавить комментарий

KEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживую
KEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживуюKEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживуюKEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживуюKEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживуюKEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживую

KEVintel - новый агрегатор уязвимостей с признаками эксплуатации вживую. Анализируют 50 публичных источников, включая CISA KEV и фиды люксембургского CERT CIRCL, а также данные собственных сенсоров. Помимо признаков эксплуатации вживую, на странице уязвимости отображаются данные из CVE Org, EPSS, упоминания в Интернете, правила детектирования в сканерах (например, nuclei), потенциальные публичные эксплоиты и прочее.

Фид KEVintel можно выгрузить в виде JSON или CSV. Удобно для интеграций, планирую приделать к Vulristics. 😉 Но, к сожалению, в выгрузках сейчас доступны не все данные, отображающиеся на странице уязвимости. 🤷‍♂️ На сайте они намекают на "pro features". Возможно расширенный фид и будет такой платной фичей.

Почему это нас беспокоит?

Добавить комментарий

Почему это нас беспокоит?

Почему это нас беспокоит? Ситуация с финансированием MITRE и NIST исключительно внутриамериканская. И она так или иначе разрешится. В этой сфере крутятся миллиарды долларов, работают сотни компаний и многие тысячи специалистов. Они без нас найдут тех, кто будет вести и обогащать базу CVE, и кто будет это финансировать (CISA уже отсыпали MITRE денежек на 11 месяцев 😏).

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

Ответ очевиден: в России всё ещё широко используется западный коммерческий софт, уязвимости которого собираются в эти базы. Как и уязвимости западного опенсурсного софта/библиотек, составляющих основу практически всего "отечественного ПО". Из технологической зависимости растёт и зависимость от американских баз уязвимостей. 🤷‍♂️

Поэтому следует:

🔹 усиливать настоящее импортозамещение
🔹 избавляться от западных продуктов
🔹 наращивать контроль над опенсурсными проектами

CVE без NIST и MITRE?

Добавить комментарий

CVE без NIST и MITRE?

CVE без NIST и MITRE? Кучно пошли новости о проблемах с поддержанием баз CVE уязвимостей от NIST и MITRE:

🔻 NIST может уволить 500 сотрудников. 👋
🔻 ~100к уязвимостей опубликованных до 1 января 2018 в NIST NVD перевили в статус "deffered" ("отложенный") и перестали обновлять. 🤷‍♂️
🔻 MITRE CVE Program может потерять финансирование. 💸

Процитирую свой прошлогодний пост на 25 лет CVE: "Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону."

Похоже американская система управления настолько деграднула, что и с поддержанием этого мусорного полигона не справляется. 🤷‍♂️

Что будет дальше?

🔹 80% - зальют проблему деньгами и клоунада продолжится. 🤡

🔹 20% - американские CVE-богадельни в NIST и MITRE схлопнутся и CVE Program уйдёт в свободное плавание (всё и так держится на одних CNA-организациях). 🛳️

В целом, довольно пофиг на них. Имхо, нас в России должно волновать не это.

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

Добавить комментарий

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся

25 лет CVE: кто базу CVEшек анализировал, тот в цирке не смеётся. В январе 1999 года Дэвид Э. Манн и Стивен М. Кристи опубликовали статью "К единому перечислению уязвимостей" ("Towards a Common Enumeration of Vulnerabilities"), в которой предлагалось создать лист Common Vulnerability Enumeration, CVE (заметьте, в оригинале никаких "экспозиций" 😉), целью которого было бы:

🔻 нумеровать и различать все известные уязвимости
🔻 назначать стандартное уникальное имя каждой уязвимости
🔻 существовать независимо от множественных точек зрения на то, что такое уязвимость
🔻 являться публично "открытым", распространяемым без ограничений

В октябре 1999 года корпорация MITRE представила первый CVE лист, в котором была 321 запись. За 25 лет их количество перевалило за 250 000 идентификаторов (без Rejected). Количество новых CVE каждый год ставит рекорды, в этом году ожидается больше 35 000. В основном такой бешеный прирост обеспечивают организации со статусом CNA, которых уже 221. Они, получив заветный статус, могут заводить CVE на любую дичь. Хоть весь свой багтреккер пихать, как Linux Kernel. 😏

Во многом из-за такого прироста (ну и из-за приколов американской бюрократии) процесс по анализу уязвимостей в NIST NVD в 2024 году дал масштабный сбой, фактически остановился. Несмотря на все меры (включая финансовые), он так толком и не восстановился. NVD месяц от месяца анализирует значительно меньше CVE, чем получает от CVEorg. Бэклог на анализ растёт, и составляет 19 174 CVE. 🫣

Не такая беда, что база замусорена и не анализируется в должной степени. Настоящая беда в том, что она при этом ещё и неполна. Серьёзные уязвимости, обнаруженные российскими или китайскими исследователями могут не приниматься из-за каких-то геополитических соображений и они фиксируются только в национальных базах уязвимостей. 🤷‍♂️

Вот такой итог 25 лет. Вместо единой нейтральной базы пришли к стремительно растущему недоанализированному огороженному западному мусорному полигону. В котором приходится всем миром копаться, потому что ничего лучше всё равно нет. 🙄 Круто, чё. С юбилеем!

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

Добавить комментарий

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

CVE-идентификаторы с пробелом в OVAL-контенте RedOS. В ходе подготовки отчёта по октябрьскому Linux Patch Wednesday обнаружил, что у меня откуда-то лезут невалидные CVE-идентификаторы с пробелом в конце. Источником оказался OVAL-контент RedOS (7.6 мб). По находится 115 таких проблемных ссылок на CVE. Вряд ли это ошибки при ручном заполнении, видимо ошибка в последних версиях генератора OVAL-контента.

Если вы используете OVAL-контент RedOS, обратите внимание, что такое может быть и потенциально может аффектить Vulnerability Management процесс.

Просьба коллегам из РЕД СОФТ пофиксить проблему и накрутить тесты, что используемые CVE-идентификаторы матчатся регуляркой.

Upd. Коллеги из РЕД СОФТ быстро отреагировали и проблему исправили. 🙂👍