Журнал "Information Security/ Информационная безопасность" #4, 2026

Публикация на сайте ФСТЭК России [2] выдержки из Методики – важный и очень своевременный шаг, способствующий популяризации методологии исследова- ния средств защиты информации среди компаний, ориентирующихся на выстраи- вание процессов разработки безопасного ПО (РБПО) в соответствии с лучшими отечественными практиками и требова- ниями. С момента ввода в действие пре- дыдущей версии Методики (в рабочей группе известной под кодовым названием Методика 2.0) прошло более пяти лет, из них работа над версией 3.0 заняла последние четыре года, с разной степе- нью интенсивности и частичным измене- нием (расширением) состава рабочей группы. Финальный текст документа впи- тал в себя опыт создания современных технологий и инструментов анализа, опыт создания, внедрения и оценки методо- логий РБПО в компаниях различного масштаба, а также многолетние полевые работы по обкатке перспективных под- ходов к проведению сертификационных испытаний для компаний различной сте- пени зрелости, вплоть до очевидных новичков [3], массово стремящихся выйти на рынок сертифицированных СЗИ, начи- ная с 2022 г. Огромное влияние на доку- мент оказала деятельность ТК362 по созданию и актуализации передовых стандартов в области РБПО [4], а также активность и заинтересованность веду- щих промышленностей и инженеров- энтузиастов – участников РБПО-сообще- ства ФСТЭК России и ИСП РАН [5, 6, 7]. Основная задача этой статьи – под- светить наиболее значимые проблемы организации и проведения сертифика- ционных испытаний СЗИ в части, касаю- щейся выявления уязвимостей и недек- ларированных возможностей, решение которых регулируется Методикой. Тра- диционно текст будет написан в доста- точно неформальном ключе, что, по задумке автора, позволит повысить его читаемость. Итак, рассмотрим ключевые проблемы и предложенные подходы к их решению. Нет РБПО – нет сертификационных испытаний Современная качественная разработка и сертификационные испытания ПО невозможны без принятия и имплемен - тации разработчиком РБПО-подхода в производственных процессах. Объем и глубина исследований, задаваемые Мето- дикой, невыполнимы силами одной толь- ко испытательной лаборатории за разум- ный срок. При этом большую часть затрат составит не столько даже выполнение инструментальных видов анализа, сколь- ко исправление найденных в ходе испы- таний продукта уязвимостей и критичных ошибок, и последующие циклы перете- стирования. Не говоря уже о критически важном процессе устранения уязвимо- стей, выявленных на этапе эксплуатации продукта – массовость и скорость обна- ружения новых уязвимостей (в эпоху применения искусственного интеллекта) не оставляют шансов на успешную борь- бу с ними в компаниях, не реализовавших процессы композиционного анализа и защиты цепочек поставок. Текст новой Методики наполнен пря- мыми и недвусмысленными указаниями на необходимость реализации процессов РБПО именно разработчиком (см. напри- мер: пп. 1.3, 2.3.д, 2.6, 5.3, 5.4, а также секции требований к проведению иссле- 64 • СПЕЦПРОЕКТ Методика 3.0. История создания и ключевые тезисы Дмитрий Пономарев, заместитель генерального директора “НТЦ Фобос-НТ”, сотрудник ИСП РАН, старший преподаватель МГТУ им. Н. Э. Баумана ИУ10 Амир Хафизов, главный редактор журнала “Информационная безопасность" Новый нормативный документ всегда ставит перед профессиональным сообществом два вопроса: что измени- лось и как теперь работать. Ответ на первый можно получить, сопоставив редакции. Второй требует внимательного разговора – о замысле изменений, связи между требованиями и их применении в повседневной практике. Такой разговор мы и предлагаем в этом спецпроекте. Статьи спецпроекта подготовлены по согласованию с ФСТЭК России с привлечением непосредственных участников рабочей группы, участво- вавшей в создании Методики выявле- ния уязвимостей и недекларирован- ных возможностей в программном обеспечении, утвержденной 12 мая 2026 г. [1]. Для редакции это принци- пиально: мы хотели дать читателю возможность познакомиться с доку- ментом при участии тех, кто работал над его содержанием, обсуждал под- ходы и формулировал требования. У такого знакомства есть особая ценность. За текстом Методики стоят задачи, которые предстоит решать разработчикам программного обес- печения и испытательным лаборато- риям. Чтобы понять отдельное требо- вание, часто необходимо увидеть его место в общей системе: с какими эта- пами разработки оно связано, на какие результаты опирается и что позволяет проверить. Участие создателей доку- мента помогает выстроить эти связи и объяснить логику принятых решений. Мы адресуем спецпроект тем, кто хочет составить о Методике целостное представление. При первом чтении вни- мание сосредоточивается на конкретных пунктах: что подготовить, какой анализ провести, какие материалы передать в лабораторию. Но для осмысленной работы важно понимать и задачу доку- мента, его роль в развитии процессов разработки безопасного программного обеспечения (РБПО) и организации сер- тификационных испытаний в системе сертификации ФСТЭК России. Поэтому мы постарались соединить в одном спецпроекте несколько ракур- сов: от предпосылок и ключевых изме- нений перейти к практическим вопро- сам применения Методики. Особое внимание уделено ее связи с ГОСТ Р 56939–2024: Методика рекомендуется для конкретизации требований к про- цессам безопасной разработки, реа- лизуемым по этому стандарту. Завер- шающая статья спецпроекта показы- вает, как разделы Методики соотно- сятся с разделами и требованиями ГОСТа. От редакции Фото: Антон Косицын 1 Приведены общие разделы, а также методология испытаний по 6–4 уровням контроля 2 Теперь анализу подлежит в том числе исходный код при испытаниях по 6 уровню контроля, см. п. 2.3.б