Цели 24-го процесса ГОСТ Р 56939-2024:
Организация систематического и углубленного поиска ошибок и уязвимостей в ПО при его эксплуатации в целях упреждающего реагирования: обработки ошибок кода ПО и его конфигураций (настроек) до того, как они будут выявлены сторонними лицами и повлекут инциденты информационной безопасности.
С выпуском очередной версии ПО работы, направленные на обеспечение безопасности, не заканчиваются. Необходимо постоянно актуализировать информацию об уязвимостях созданного ПО из открытых источников на регулярной основе на всем протяжении срока действия его технической поддержки. Для этого выстраивается процесс регулярного поиск в открытых источниках информации об уязвимостях самого ПО и его сторонних компонентов.
Контроль уязвимостей в сторонних компонентах может показаться избыточным, ведь для этого есть процесс 16 — композиционный анализ (см. РБПО-061). Как я понимаю, здесь речь о следующем:
1. SCA инструменты могут быть ещё не в курсе выявления и эксплуатации какой-то уязвимости. И если вдруг удалось выяснить, например, на форуме хакеров, что некий компонент уязвим, то можно предпринять действия, не дожидаясь появления соответствующей CVE. Собственно, можно стать инициатором пополнения базы CVE новой уязвимостью и тем самым обезопасить не только свой проект, но и помочь другим.
2. В процессе разработки сменяются версии используемых библиотек. Однако важно следить не только за уязвимостями в библиотеках, используемых на данный момент. У клиентов могут функционировать приложения предыдущих версий, построенные на более ранних версиях библиотек. Нужно отслеживать обнаружение уязвимостей и в этих старых версиях библиотек, чтобы выпустить соответствующие пакеты обновления для старых версий продукта или уведомить пользователей о необходимости срочно перейти на новые версии ПО.
Параллельно с отслаиванием информации об уязвимостях можно проводить более глубокий анализ кода с целью выявления новых ошибок и потенциальных уязвимостей. Для этого, например, можно изменить настройки статических анализаторов, чтобы они выдавали большее количество предупреждений, пусть и менее достоверных.
Проверки реализуются другими инструментами анализа или теми же инструментами, но с другими настройками конфигурации, с целью обеспечения анализа с меньшей долей пропусков ошибок за счет применения специализированных алгоритмов, привлечения больших вычислительных и временных ресурсов.
Ещё одним способом упреждения уязвимостей являются публичные программы поиска уязвимостей за вознаграждение:
Проверки кода ПО и настроек конфигураций ПО при его эксплуатации могут выполняться как собственными силами разработчика, так и с привлечением сторонних организаций и исследователей, в том числе в рамках публичных программ поиска уязвимостей за вознаграждение (программ багбаунти).
К сожалению, пока Госдума отклонила законопроект о легализации "белых" хакеров:
На заседании во вторник, 8 июля 2025, Госдума отклонила законопроект, который должен был легализовать в России деятельность «белых» хакеров. Решение было принято после соответствующей рекомендации профильного комитета Госдумы по государственному строительству и законодательству.
Речь идет о хакерах, которых компании самостоятельно привлекают к тестированию своих информсистем на уязвимости. Вопрос легализации их деятельности в России публично обсуждается с лета 2022 года, когда Минцифры занялось проработкой возможности ввести в правовое поле понятие bug bounty — поиск уязвимостей в софте за вознаграждение.
Так что учитывайте, что сейчас этот метод, к сожалению, не регламентируется и не оформлен юридически.
Дополнительные ссылки:
1. Елена Дмитриева. Обзор программ и площадок баг-баунти в России: практика, кейсы, суммы гонораров.
2. TAdviser. Подборка: Белые хакеры в России.
3. Круглые столы: Взгляд разработчиков, пользователей, хакеров, Багбаунти: опыт hh.ru и Rambler&Co, Багбаунти: опыт Ozon и Wildberries на Standoff Bug Bounty.
4. Как пентестеры помогают бизнесу найти уязвимости в IT-системах.