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

Методика от 12.05.2026 плотнее при- вязана к ГОСТ Р 56939–2024 и точнее распределяет работу между разработ- чиком и испытательной лабораторией. Сертификация перестает быть этапом доведения продукта до безопасного состояния. Разработчик приходит в лабо- раторию с готовым ПО и результатами процессов разработки по ГОСТ Р 56939– 2024. Среди артефактов п. 2.3 Методи- ки – результаты анализа архитектуры и поверхности атаки, композиционного анализа, анализа конфигураций, стати- ческого анализа, фаззинга, тестирования на проникновение, модульного, функ- ционального и интеграционного тести- рования, а также, впервые, программы баг-баунти, если она проводилась. Нужны также тесты и фаззинг-тесты, конфигу- рации инструментов и перечень про- граммных компонентов (ППК) в формате CycloneDX 1.6 или 1.7 (JSON). Результаты безопасной разработки входили в исходные данные и в 2020 г., но тогда их получали "в соответствии с принятыми у разработчика процедура- ми". Теперь их сверяют со стандартом, а разработчикам прямо рекомендовано строить по методике внутренние про- цессы жизненного цикла. Недостатки по-прежнему можно устранять в ходе исследований, но все, что затронуто исправлением, исследуется повторно. Роль лаборатории Лаборатория верифицирует достовер- ность, полноту, актуальность и согласо- ванность исходных данных, затем выбо- рочно проверяет результаты. При большой доле недостоверной информации она может прекратить испытания. Методика также закрепляет собственные работы лаборатории: например, статический ана- лиз не менее пяти модулей поверхности атаки и не менее десяти предупреждений на каждый язык, фаззинг-тестирование не менее двух новых фаззинг-целей или серьезную доработку не менее трех суще- ствующих комплектов фаззинг-тестов. ПОД. Поверхность атаки Требования ПОД.1 к поверхности атаки стали строже. Нарушитель – любой штатный пользователь; поверхность атаки должна включать также служеб- ные, отладочные, периодические интер- фейсы и интерфейсы обновления. Впер- вые методика задает графическую нота- цию для схемы поверхности атаки. Еще одно новшество – документаль- ное обоснование выбора критичных уча- стков кода: парсеров и сложного кода, обрабатывающего данные нарушителя. Оно включает метрику цикломатической сложности исходного кода, описание обработки недоверенных данных и пути их поступления к выбранному участку. В нашей лаборатории мы экспери- ментируем со статическим анализатором Svace для подготовки таких обоснова- ний. Он сводит выгрузки анализа кода в таблицу функций с графом вызовов и цикломатической сложностью. Критич- ность участков можно соотнести с кри- тичностью детекторов анализатора: она может различаться по ЯП. Потенциально taint-детекторы также могут маркировать обработку недоверенных данных. КАО и ЭКО Методика требует выделять код, испол- няемый в браузере пользователя, а не на сервере (JavaScript, WebAssembly и т. п.). На уровнях 5 и 4 лаборатория проверяет его учет в ППК и проведение разработ- чиком композиционного анализа. Если продукт подгружает в браузер код вне дистрибутива ОО, лаборатория может потребовать включить его в ОО или пре- кратить исследования. Взаимодействия интерфейса ОО с браузером пользова- теля – обращения к камере, микрофону, геопозиции или буферу обмена – необхо- димо документировать; иначе они счи- таются недостатком безопасности. САО. Проверка разметки Основное нововведение в статическом анализе – требование классифицировать критические ошибки по ГОСТ Р 71207– 2024. В редакции 2020 г. разметку тре- бовали для предупреждений критического и высокого уровня, но уровень определял анализатор. Лаборатория выборочно про- веряет разметку: сначала предупрежде- ния "истинные, не требующие исправле- ния", затем ложноположительные. Мето- дика отдельно оговаривает качество раз- метки: комментарий должен объяснять решение другому участнику испытаний без разбора кода. Некачественными прямо названы пояснения "не эксплуати- руемо", "не применимо" и групповая раз- метка несходных срабатываний. Для Rust и других языков с неочевид- ной поддержкой я советую заранее сопо- ставить детекторы анализатора с типами критических ошибок ГОСТ. ДАО.1 и ДАО.2 Тестирование модулей теперь обяза- тельно с 6-го уровня контроля вместо 4-го. Разработчик тестирует все модули, реа- лизующие функции безопасности, на каждой процессорной архитектуре стен- да, собирает покрытие по функциям и разбирает журналы, включая срабаты- вания датчиков ошибок. Тесты, не вызы- вающие функций тестируемых модулей, не засчитываются. На уровне 5 добав- ляются модули непосредственной поверхности атаки, на уровне 4 – модули, обеспечивающие реализацию функций безопасности. На уровне 4 покрытие каждого модуля по строкам или базовым блокам должно быть не ниже 25%. Лабо- ратория проверяет выборку не менее 50 тестов со сбоями из пяти и более моду- лей, включая все тесты на неисправлен- ные регрессии безопасности. Требования к фаззингу изменились меньше, чем в САО и ДАО.1. Главное новшество на уровне 4 – связь с ПОД.1: для выделенных там критичных участков кода готовят синтетические цели с функ- циями-обертками, переводящими мути- рованные данные во входные параметры тестируемых функций. В заключение Еще при разработке к испытаниям нужно готовить описание поверхности атаки с критичными участками кода, ППК, резуль- таты статического анализа с разметкой по ГОСТ Р 71207–2024 и ясными коммен- тариями, тесты с покрытием, фаззинг- цели с коллекциями и журналами. Лабо- ратория выборочно проверит их и проведет свои исследования. Если ошибок в раз- метке тестов или фаззинга более 10% либо превышен допуск по несоответ- ствиям, испытания остановятся, а не про- должат силами лаборатории. l 66 • СПЕЦПРОЕКТ Разработчик и лаборатория: что меняется? Андрей Кузнецов, директор департамента внедрения и развития практик, НТЦ “Фобос-НТ”, сотрудник ИСП РАН Фото: НТЦ "Фобос-НТ"