Цели 23-го процесса ГОСТ Р 56939-2024:
Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.
Основная суть — быстро и адекватно реагировать на информацию об уязвимостях, полученную от пользователей или из иных источников.
Конечно, иногда информация об угрозе не будет соответствовать действительности, и многие замеченные дефекты безопасности невозможно в реальности эксплуатировать как уязвимость. Однако требуется построить систематическую обработку такой информации и её анализ, чтобы не пропустить действительно критичные моменты.
Часто этот процесс отсутствует. Вернее, к полученной информации о угрозах относятся точно так же, как и к сообщениям об ошибках. Дефекты безопасности попадают в багтрекеры наравне с другими багами и ждут своей очереди… и иногда очень долго. Другими словами, часто в компаниях выстроен 22-й процесс "Обеспечение поддержки программного обеспечения при эксплуатации пользователями", но не выстроен 23-й.
На практике это может выглядеть следующим образом. Я открываю задачу в багтрекере проекта о том, что в некоторых функциях не происходит очистка приватных данных. Компилятор в процессе оптимизации удалит вызов функции
memset для зануления буфера, т.к. затем этот буфер более не используется. В общем, речь про CWE-14: Compiler Removal of Code to Clear Buffers.Я не утверждаю, что это прям ужас-ужас какая ошибка. Она может ни на что не влиять и, скорее всего, эти незатёртые данные невозможно как-то заполучить и использовать. И тем не менее это вполне себе дефект безопасности, который, согласно ГОСТ Р 71207-2024, можно классифицировать как критическую ошибку (6.3.г — Ошибки некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.)). Если речь идёт о РБПО, то такую ошибку следует просто на всякий случай сразу исправить и жить дальше спокойно. Тем более, что правка несложная.
Однако отсутствие процесса реагирования потенциальные уязвимости приводит к тому, что эта ошибка прождала своего исправления 9 лет. Это не придуманная история, а реальный случай — 1000 глаз, которые не хотят проверять код открытых проектов.
Или, например, я месяц ждал реакции от разработчиков на информацию о дефектах, которые я затем описал в статье "Релиз PVS-Studio для macOS: 64 weaknesses в Apple XNU Kernel". Так ничего не дождался и опубликовал статью. Моё письмо или потеряли, или оно в спам попало, или пылится среди других. И подобных случаев на нашей практике много.
Чтобы такого не происходило, согласно ГОСТ Р 56939-2024, следует разработать и внедрить регламент (п.5.23.3.1):
- обязанности сотрудников и их роли при реагировании на информацию об уязвимостях ПО;
- правила реагирования на информацию об уязвимостях;
- правила оценки актуальности и критичности уязвимости с точки зрения безопасности ПО;
- периодичность проведения поиска известных (подтвержденных) уязвимостей в общедоступных источниках информации об уязвимостях ПО.
Рассматриваемый процесс также пересекается c композиционным анализом (см. РБПО-061), если речь идёт о нахождении уязвимостей в сторонних используемых компонентах.
По каждому случаю должна быть проведена работа по оценке актуальности и критичности. Т.е. должен появится артефакт, подтверждающий выполнение оценки актуальности и критичности уязвимости с точки зрения безопасности. Он должен содержать (п.5.23.3.4):
- информацию об оценке актуальности уязвимости;
- информацию об оценке уровня критичности уязвимости ПО;
- решение по результатам анализа актуальности и критичности уязвимости.
Дополнительные ссылки:
1. Терминология. Уязвимость нулевого дня.
2. Станислав Мриль. Всё об управлении уязвимостями в 2025: Vulnerability Management.
3. Positive Technologies: раскрытие уязвимостей и опыт взаимодействия исследователей и вендоров в 2022–2023 годах.
4. Руслан Рахметов. Поиск и предотвращение уязвимостей в ПО: эффективные методики.
5. Порядок подачи уязвимости в базу ФСТЭК России: пошаговая инструкция.