Событие, которое РБПО-сообщество ожидало уже несколько месяцев. 12 мая 2026 года ФСТЭК была утверждена "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (далее — Методика). Методика приведена в соответствие с ГОСТ Р 56939—2024.

Из информационного сообщения В. Лютикова от 28 мая № 240/24/3693:
Методика ориентирована на проведение исследований, выполняемых испытательными лабораториями и разработчиками в рамках сертификационных испытаний программных, программно-аппаратных средств защиты информации и защищённых программных, программно-технических средств, а также в рамках внесения изменений в ранее сертифицированные средства. Разработчикам программного обеспечения средств защиты информации рекомендуется использовать положения настоящей Методики для организации внутренних процессов жизненного цикла программного обеспечения в соответствии с ГОСТ Р 56939—2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования".
Если вы ещё не знакомы с обновлённым стандартом, то предлагаю взглянуть на подборку материалов "Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024". Подборка основана на 30 вебинарах, проведённых с экспертами из различных компаний, и будет хорошей отправной точкой для знакомства с РБПО и ГОСТ Р 56939—2024.
Соответственно, с выходом новой Методики старая более не применяется:
В связи с утверждением настоящей Методики положения методического документа "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении", утверждённого ФСТЭК России 25 декабря 2020 г., не применяются.
С рассуждением о вопросе "Как быть с уже идущими работами по старой методике?" можно познакомиться в здесь (Информационный канал сообщества ФСТЭК России и ИСП РАН).
Примечательно, что впервые выложена выписка из Методики (для 6-4 уровней доверия).
Теперь затрону некоторые моменты, которые так или иначе касаются близкой нам темы — статического анализа кода.
В выписке говорится (п.2.3.л), что при проведении исследования объектов оценки (далее — ОО) используются методики статического анализа заимствованных компонентов с открытым исходным кодом, опубликованные на сайте Центра исследований в разделе "Методика проведения статического анализа". Как я понимаю, имеются в виду следующие методические материалы:
Здесь речь идёт исключительно про работу с ядром Linux с помощью конкретно анализатора Svace. Однако суть этих материалов может быть легко перенесена на другие открытые библиотеки и анализаторы кода.
Примечание. Для разметки (выставления вердиктов, обмена комментариями и т. д.) в экосистеме PVS-Studio появился инструмент ATLAS в двух редакциях:
Статический анализ исходного кода объекта оценки требуется начиная с 5 уровня контроля (таблица 3 в разделе 4.2 выписки). Но для 5 уровня нет требований к анализаторам кода. Эти требования появляются начиная с 4 уровня доверия.
Задачей исследования является выявление недостатков безопасности кода методами и инструментами статического анализа кода в соответствии с ГОСТ 56939—2024. В стандарте этому посвящён раздел 5.10 — Статический анализ исходного кода.
В первую очередь исходными данными для проведения исследования является исходный код объекта оценки. Статический анализ выполняется разработчиком ОО в отношении исходного кода всех модулей, составляющих поверхность атаки.
Статический анализ выполняется разработчиком для всех высокоуровневых языков программирования, которые встречаются в исходном коде модулей. Здесь уместно напомнить, что согласно ГОСТ Р 71207—2024 (п. 5.2) необходимо выбрать один или несколько статических анализаторов. Не ставится задача выбрать только один инструмент сразу для всех языков.
Используемые статические анализаторы должны реализовывать автоматизированный анализ исходного кода на уровне синтаксического дерева. Это базовое с точки зрения технологий анализа требование служит для того, чтобы отсечь совсем простые инструменты (линтеры), где детекторы реализуются только с помощью регулярных выражений. Почему построение полноценного анализа возможно только на базе синтаксического дерева, см. в статье "Статический анализ и регулярные выражения".
Должна быть выполнена ручная разметка всех предупреждений о критических ошибках, выданных анализаторами. Обратите внимание, что речь идёт о фокусе на ошибках критического типа.
Анализаторы выдают разнообразнейшие предупреждения, многие из которые могут иметь стилистический характер: способ именования переменных, запрет приведения типов в стиле языка C, запрет на использование оператора goto и т. д. Попытка отрефакторить все места кода, где выданы подобные предупреждения, или разметить все предупреждения крайне трудоёмка и на практике слабо повлияет на безопасность. Возникает вопрос, какие предупреждения анализаторов обязательны к разбору, а какие нет?
Ответ на него даёт ГОСТ 71207—2024 "Статический анализ программного обеспечения", где введено понятие критическая ошибка. Именно предупреждения, указывающие на потенциальное наличие критической ошибки, и должны быть разобраны/размечены в обязательном порядке.
Анализатор PVS-Studio выявляет все типы критических ошибок и помечает их специальным маркёром. Подробнее про разметку критических ошибок и работу с ними можно прочитать в статье "Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207—2024)".
Разработчиками выполняется разметка всех предупреждений, предусмотренных планом поддержки безопасности заимствованных компонентов (в случае внесения изменения в сертификационный ОО).
Дополнительные требования к статическому анализатору начинаются с 4 уровня доверия. Испытательной лабораторией проверяется, что используемый статический анализатор отвечает требованиям ГОСТ 71207—2024 "Статический анализ программного обеспечения".
Информацию о требованиях к исследованию с помощью статического анализа кода для более высоких уровней доверия можно получить из полной версии методического документа.
Примером анализатора, совместимого с ГОСТ 71207—2024, является PVS-Studio:
Основные характеристики PVS-Studio:
Дополнительные ссылки
0