Минцифры подготовило требования по информационной безопасности для «доверенного» ПО

16 октября, 2026, 09:30

Минцифры опубликовало проект постановления с требованиями по информационной безопасности к российскому ПО из перечня «доверенного». Среди новаций: отсутствие уязвимостей, зафиксированных в банке данных угроз безопасности информации ФСТЭК, а обновляться оно должно только с разрешения пользователя и через средства, расположенные в России. Эксперты отмечают, что для компаний без выстроенных процессов безопасной разработки новые требования могут стать проблемой: им придётся организовать контролируемую сборочную среду и вести перечень компонентов.

Минцифры опубликовало требования по информационной безопасности к российскому программному обеспечению, внесенному в перечень «доверенного». От ПО будут ожидать отсутствия уязвимостей, зафиксированных в банке данных угроз безопасности информации ФСТЭК, а установка обновлений должна происходить только с разрешения пользователя и с помощью средств, расположенных в России. Это следует из проекта постановления, опубликованного на федеральном портале проектов нормативных актов 13 октября.

«Доверенное ПО» — это категория внутри реестра российского ПО. Эту группу программного обеспечения могут использовать субъекты критической информационной инфраструктуры на значимых объектах.

Среди требований к безопасности, упомянутых в проекте постановления, указано следующее:

Продолжение ниже

  • В ПО не должно быть уязвимостей, опубликованных в Банке данных угроз безопасности информации ФСТЭК. Уязвимости должны устраняться в порядке и сроки, установленные ФСТЭК;
  • Исходный код ПО, технологическая инфраструктура разработки и сборочная среда для разработки и установки должны находиться в контролируемом окружении. Требования к окружению также определяет ФСТЭК;
  • Обновления ПО могут происходить только с разрешения пользователя, для обновления не должны использоваться технические и программные средства, расположенные за пределами РФ;
  • Правообладатель ПО обязан актуализировать перечень программных модулей и компонентов, из которых состоит разработка, и предоставлять его по запросу лица, использующего ПО;
  • Если ПО работает как средство защиты информации, то часть требований считается выполненной при наличии у правообладателя ПО сертификата соответствия процессов безопасной разработки ФСТЭК.

Руководитель направления развития продуктов кибербезопасности Cloud.ru Максим Долгинин обращает внимание и на другую новацию: исключение требования об обязательном наличии сразу двух доверенных ОС для облачного ПО и средств защиты информации. «Это важный момент, так как поддержка двух доверенных ОС — это избыточное требование для облачного ПО, которое по своей задумке не предназначено для самостоятельной установки пользователями», — отмечает эксперт.

При этом разработчик такого ПО фактически использует только одну операционную систему, и поддержка второй для них — это дополнительные расходы, не добавляющие ценности ни разработчику, ни пользователям ПО, считает Долгинин.

Это изменение, как считает Долгинин, однозначно положительно повлияет на заказчиков: у большего количества разработчиков облачного ПО появится возможность попасть в реестр отечественного ПО, что сыграет и в пользу клиентов.

Однако для тех разработчиков, у которых нет выстроенных процессов безопасной разработки, новые требования могут оказаться проблемными.

«Им придётся организовать контролируемую сборочную среду, устранять уязвимости из БДУ во всех компонентах и вести их перечень, — говорит Долгинин. — По сути это требование толкает разработчиков на внедрение в компании процессов безопасной разработки, что позволит снизить количество уязвимостей в доверенном ПО».

По мнению аналитика угроз GSOC компании «Газинформсервис» Владислава Шелепова, особенно заметными изменения могут оказаться для тех компаний, у которых сборочная инфраструктура или механизмы доставки обновлений завязаны на зарубежные сервисы. Также обращают на себя внимание «дополнительные требования», вводимые проектом, — такие как совместимость с отечественными микропроцессорами и поддержка российских браузеров.

«Для этого нужно подать отдельное заявление, заключить договор с центром тестирования и пройти экспертизу. Решение действует три года, после чего соответствие нужно подтверждать заново», — обращает внимание Шелепов.

По словам эксперта «Газинформсервиса», одна из сложностей проекта заключается в том, что часть важных условий вынесена за пределы самого проекта. Например, требования к «контролируемому окружению» должны определяться документами ФСТЭК России, порядок и сроки устранения уязвимостей тоже привязаны к требованиям ФСТЭК России.

«Я бы также уточнил формулировку про обновления. Сейчас проект запрещает использовать при обновлении средства, расположенные за пределами России, а также копии таких средств, размещенные в России. Здесь было бы полезно более точно описать, какие именно элементы инфраструктуры имеются в виду», — отмечает эксперт.

Требование в части отсутствия необработанных уязвимостей из БДУ ФСТЭК также обращает на себя внимание: текст проекта не раскрывает различия по критичности или применимости конкретной уязвимости к конфигурации продукта.

«На практике именно эти детали могут сильно влиять на то, насколько выполнимым окажется требование», — говорит Шелепов.