13 октября Минцифры опубликовало проект постановления с требованиями к доверенному ПО. Впервые ИТ-рынок узнал, что ведомство хочет увидеть в доверенном ПО: без известных уязвимостей, со сборкой в контролируемом окружении, с актуальным перечнем компонентов и без обновлений через зарубежные серверы. Проект изменяет сразу три постановления: о реестре российского ПО (№ 1236), о перечне доверенного ПО (№ 1931) и о сроках новых требований к реестру (№ 1937).
Вам нужно знать эти требования, если ваше ПО включено в реестр российского ПО и вы продаете его госзаказчикам на конкурентном рынке и если ваше ПО участвует в КИИ (транспорт, банки, энергетика и т.д.). Читайте дальше, почему это для вас важно.
Я IT-юрист, веду проекты по включению ПО в реестр. Ниже разбираю, что такое доверенное ПО, кому оно нужно и что поменяется, если проект примут.
Сразу оговорюсь: это проект. Он не принят, не вступил в силу и до принятия может поменяться как угодно. Обсуждение идёт на regulation.gov.ru (проект № 171820). Кстати, можно через кнопку «Ваши предложения» внести свои комментарии к тексту, но для этого необходимо будет авторизоваться через Госуслуги.
Что такое доверенное ПО
Сейчас при включении в реестр российского ПО происходит только базовая проверка на соответствие требованиям. Однако некоторое время назад Минцифры приняло решение о присвоении ПО статуса доверенного тому ПО, которое прошло дополнительную проверку на безопасность и получило в реестровой записи такую отметку.
Если проводить аналогию с разработкой, то реестр российского ПО — это базовая проверка происхождения, а доверенный статус — это аудит безопасности поверх неё.
Отдельного реестра доверенного ПО не будет — это будет дополнительный статус в текущем реестре, то есть вам нужно будет:
-
Получить базовый статус — включить ПО в реестр российского ПО;
-
Заявить о необходимости получения статуса «доверенного ПО» — потребуется отдельная заявка, платная экспертиза в аттестованном центре тестирования и положительное решение комиссии.
-
Подтверждать этот статус — статус будет даваться на 3 года, потом потребуется подтверждение.
-
Также проект вводит и дополнительные требования — пока что получается вот такая картина:

|
Уровень |
Что проверяют |
Состояние сейчас |
|---|---|---|
|
Реестр российского ПО |
Права у российского лица, код и инфраструктура в РФ, нет зависимости от иностранных сервисов |
Работает, больше 30 тыс. записей |
|
Доверенное ПО |
Реестр плюс требования по безопасности |
Порядок утверждён, требований не было, перечень пуст |
|
Дополнительные требования |
Доверенное плюс российские процессоры, поддержка, API, требования по классам ПО |
Только в проекте |
Кому это нужно
-
Тем, кто продаёт в госзакупки. С 1 марта 2026 года действует правило: если в закупке ПО участвует заявка с доверенным продуктом, заявка с обычным реестровым ПО приравнивается к иностранной. Пока перечень доверенного ПО был пуст — правило не работало. Как только в вашем классе появятся первые доверенные продукты, обычная реестровая запись в таких закупках перестанет быть конкурентным преимуществом. Так что вам необходимо оценить, есть ли у вас крупные конкуренты — и если да, то поставить себе в план задачи по получению признака «доверенного» ПО.
-
Тем, кто поставляет ПО в критическую информационную инфраструктуру: банкам, энергетике, транспорту, связи, госорганам. Механизм доверенного ПО появился именно из законодательства о КИИ.
-
Косвенно всем, кто в реестре или собирается туда. Если у вас десктопное ПО, то две ОС, на которых оно работает, должны быть доверенными (но пока что их нет, а когда появятся — необходимо будет обеспечить совместимость). Срок исполнения зависит от класса ПО, это будет разобрано ниже.
Обратите внимание. Если у вас продукт для малого и среднего бизнеса, вы не работаете с госзаказчиками, а запись в реестре вам нужна ради освобождения от НДС и упрощенной ИТ-аккредитации (без необходимости подтверждения зарплат), то доверенный статус вам ничего не даст. Платить за экспертизу незачем.
Откуда это вообще все взялось?
Коротко: понятие доверенного ПО ввели в закон о безопасности КИИ. ПО признают доверенным, если одновременно выполнены четыре условия:
-
Исключительное право принадлежит российскому лицу. Условия жёстче, чем для реестра: например, правообладатель-гражданин не должен иметь второго гражданства.
-
ПО уже включено в реестр российского ПО или в перечень ПО для собственных нужд.
-
ПО соответствует требованиям по информационной безопасности. Их устанавливает Правительство по согласованию с ФСБ и ФСТЭК.
-
Сведения о ПО не составляют гостайну.
Правительство может вводить для доверенного ПО ещё и дополнительные требования (именно поэтому и был разработан проект, о котором идет речь). Процедура присвоения статуса доверенного ПО такая:
-
заявление подаётся на сайте реестра, указывается номер реестровой записи;
-
за 30 рабочих дней нужно выбрать аттестованный центр тестирования, заключить с ним договор и загрузить копию. Если не успели, то заявку аннулируют;
-
центр проводит экспертизу за 30 рабочих дней (экспертиза будет платная, цену назначает центр);
-
при положительном заключении Минцифры за 15 рабочих дней передаёт заключение в правительственную комиссию (срок принятия решения не установлен);
-
статус действует 3 года, на продление можно подаваться не раньше чем за 3 месяца до конца срока.
Центром тестирования сможет стать не каждая компания. Нужны ИТ-аккредитация, не меньше 10 профильных специалистов в штате, 3 года на рынке, чистые активы и страхование ответственности от 10 млн. руб. На данный момент известно, что в качестве центров тестирования аккредитован интегратор «Гринатом» (у них на сайте есть информация об этом, но стоимость неизвестна, заинтересованным компаниям предлагается направить заявки на почту).
Если у вас есть информация о компаниях, которые также будут аккредитованы — напишите в комментариях.
Почему пока что это не работает
Постановление № 1931 ссылается на требования по безопасности, а их никто не утвердил. У центров тестирования нет критериев, по которым они должны проверять продукт, поэтому за семь с половиной месяцев перечень так и не заработал.
Требование о доверенных ОС из-за этого превратилось в замкнутый круг:

На текущий момент отказов по включению в реестр российского ПО из-за невыполнения требований о двух доверенных ОС нет ни в моей личной практике, ни в базе отказных заключений экспертизы, которые я постоянно анализирую (спасибо им хотя бы на этом).
Получается, что требование есть в правилах, но экспертиза его пока что не проверяет (это мое предположение, официальной позиции Минцифры на этот счёт нет).
Что меняет проект постановления
Сроки по двум доверенным ОС сдвигаются на год
|
Классы ПО |
Сейчас |
По проекту |
|---|---|---|
|
Офисное ПО |
01.09.2026 |
01.09.2027 |
|
Системное и серверное: СУБД, виртуализация, контейнеры, средства разработки, анализ данных |
01.01.2027 |
01.01.2028 |
|
Прикладное, отраслевое, средства ИБ |
01.06.2027 |
01.06.2028 |
|
Промышленное ПО, управление процессами |
01.01.2028 |
01.01.2029 |
Для офисного ПО перенос получается задним числом: требование уже полтора месяца в силе.
Но тут нужно понять последовательность: сначала проект должны принять; потом вендорам ОС нужно будет пройти экспертизу и получить статус доверенных (в лучшем случае это 4-5 месяцев).
Только после этого вы, как разработчик, сможете показать совместимость с доверенной ОС.
Для SaaS хватит одной ОС
Сейчас совместимости с одной доверенной ОС достаточно в двух случаях: правообладатель ПО и ОС в одной группе компаний или ПО работает только внутри программно-аппаратного комплекса.
Проект добавляет ещё два случая: средства защиты информации и ПО, которое предоставляется через облако.
Для SaaS, на мой взгляд, это главная новость проекта. Серверная часть облачного сервиса крутится на одной ОС в вашей же инфраструктуре. Клиенту безразлично, запустится ли она на второй, а тестировать и поддерживать вторую сборку только ради реестра бессмысленно.
Требования безопасности к доверенному ПО
Напомню, что для базового включения в реестр российского ПО никаких специфических требований по инфобезу не было (кроме средств защиты информации). А для доверенного ПО предусмотрено следующее, независимо от функционала:
|
Требования для доверенного ПО (обязательные) |
Что это значит на практике |
|---|---|
|
Нет неустранённых уязвимостей из банка данных угроз ФСТЭК (БДУ), а найденные закрываются в порядке и сроки ФСТЭК |
Необходимо будет обеспечить постоянный мониторинг БДУ по своим зависимостям и сроки устранения (т.е. корректировка процессов разработки) |
|
Исходники, инфраструктура разработки и сборочная среда в контролируемом окружении, требования к нему определит ФСТЭК |
Репозиторий, CI/CD и раннеры под вашим контролем. GitHub и облачные раннеры за рубежом не подходят (но они уже и сейчас не проходят) |
|
Обновления только с разрешения пользователя, в том числе через принятие лицензионного соглашения |
Автоапдейт допустим только если он прямо прописан в ваших документах |
|
Для обновлений нельзя использовать зарубежную инфраструктуру и её копии в РФ |
Зеркало Docker Hub или npm в российском ЦОДе тоже не годится |
|
Правообладатель ведёт актуальный перечень модулей и компонентов и выдаёт его пользователю по запросу |
По сути SBOM (Software Bill of Materials, полный список компонентов программы с версиями и лицензиями), который обновляется с каждым релизом |
|
Лицензии открытого ПО соблюдаются, пользователь о них проинформирован |
Аудит лицензий зависимостей, раздел с лицензиями в документации |
|
Если доступ к ПО только через браузер, оно должно работать хотя бы в одном доверенном браузере |
Прогнать продукт в российском браузере |
Для средств защиты информации с сертификатом ФСТЭК или сертификатом безопасной разработки первые четыре пункта считаются выполненными автоматически.
Про обновления. Формулировка разрешает получить согласие через лицензионное соглашение (для SaaS и продуктов с непрерывными релизами и автоматическими обновлениями желательно сразу вносить это в оферту с пользователем).
Часть «новых» требований для реестра на самом деле не новая. В нашей базе отказов есть отказ за несоблюдение AGPL при использовании MinIO и отказ ОС на ядре Linux, где не выполнялись условия GPL. Хранение кода на GitHub уже сейчас основание для отказа, потому что код должен храниться в России.
Что за второй уровень «дополнительных требований»
Сверх доверенного статуса проект вводит добровольные дополнительные требования со своей отметкой в реестровой записи. Общие для всех:
-
совместимость с российским процессором (интегральная схема первого или второго уровня) по плану-графику. Минцифры и Минпромторг должны утвердить его в течение полугода после принятия постановления;
-
техподдержка по всей России, контакты и режим работы на сайте;
-
информация об обновлениях на сайте или по запросу;
-
документация публичного API на сайте или по запросу;
-
материалы или инфраструктура для обучения пользователей.
Дальше идут требования по классам ПО: ОС, СУБД, офисные пакеты, редакторы, почта, мессенджеры, браузеры, СЭД, PLM. Несколько примеров, чтобы оценить глубину:
-
ОС нужен собственный репозиторий в России под контролем правообладателя. Компоненты собираются из исходников в своей сборочной среде, ставить ОС из зарубежного репозитория или его российской копии нельзя.
-
СУБД должна хранить контрольные суммы для всех данных и резервных копий, журналировать операции пользователей с фиксированным набором полей (пользователь, тип операции, объект, время, сессия, адрес клиента) и работать в отказоустойчивом кластере с переключением без администратора.
-
Браузер должен поддерживать сертификаты национального удостоверяющего центра и работать с плагином электронной подписи для Госуслуг.
Процедура подтверждения соответствия дополнительным требованиям такая же, как для доверенного статуса, но короче на последнем шаге: после экспертизы решение за 10 рабочих дней принимает само Минцифры, без правительственной комиссии. Отметка действует 3 года.
Снять её могут не только по истечении срока. Любое лицо может обратиться в реестр с документами, подтверждающими несоответствие (так что нужно будет следить за соответствием требованиям не только на срок рассмотрения заявки, но и все время).
Что ещё поменяется для всех в реестре
-
Если продукт исключат из реестра, на следующий рабочий день его исключат и из перечня доверенного ПО.
-
Из правил реестра убирают формулировку о проверках «не реже одного раза в год». Проверять будут по методике Минцифры, без привязки к годовому циклу.
Что делать сейчас
Сначала нужно определить, насколько вас затронут эти изменения.
-
У вас вообще нет продуктов в реестре российского ПО и вы не собираетесь их туда включать в обозримом будущем — спасибо за внимание, можете заниматься своими делами:)
-
У вас SaaS/устанавливаемое ПО для коммерческого сектора или B2C. Я бы рекомендовала вам подать заявку на включение в реестр РПО сейчас, пока еще мы живем по старым правилам и без доверенного ПО.
-
Если вы продаёте в госсектор или КИИ. Уже можно проанализировать требования, дорабатывать свое ПО (и быть готовым к изменениям финального текста).
Когда проект примут или изменят, я обновлю статью.
Если вы уже общались с центрами тестирования или готовитесь получать для своего ПО статус доверенного, то расскажите в комментариях, как это было.
ссылка на оригинал статьи https://habr.com/ru/articles/1095362/