По Lin­ux Patch Wednes­day можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

Напомню текущую логику: я беру таймстемпы бюллетеней из OVAL-контента Lin­ux вендоров. Какой таймстемп самый старый, тот и считаю временем первого исправления уязвимости.

Но вот незадача: первыми обычно выпускают исправления Debian и они же, частенько, не указывают дату бюллетеня в OVAL (и в листах рассылки тоже не всегда). 😣 Вот и получается как на картинке. Debian выпустил патч непонятно когда, а RedOS в апреле 2024. Делаем вывод, что уязвимость апрельская, ага. Хотя "2023" в CVE намекает на то, что это, мягко говоря, не совсем так и первое исправление уязвимости вышло значительно раньше.

Что с этим делать? Можно сделать радикальный шаг: если для CVE в источнике дата Unknown, то тупо выставлять текущую дату. "Если вижу исправление и не знаю когда конкретно уязвимость была исправлена, значит она была исправлена сегодня". 🙂 И проводить такую "раздачу дат" для Unkown более-менее регулярно (не реже раза в месяц).

К чему приведет введение такого правила со следующего Lin­ux Patch Wednes­day? К тому, что огромная масса уязвимостей, которые непонятно когда были исправлены, станут "исправлены" в мае 2024 года. Мы на них посмотрим, ужаснёмся разок, но зато в следующих месяцах всплывающих внезапно старых уязвимостей будет минимальное количество. Там будет в основном свежачок. Но зато я попорчу статистику внезапным пиком в мае 2024. Дилемма. 🤷‍♂️

Как считаете, проводим операцию "Введение правила по Unknown датам с Мая 2024?".

Кит 🐳, если да (ввести правило, получить пик в статистике ради будущих красивых отчётов без старья).

Палец вниз 👎, если нет (оставить как есть в надежде, что в будущем появится хороший источник данных по таймстемпам исправления и статистика автоматом пересчитается правильным образом).

Сам я считаю, что ввести такое правило стоит.