Доверенное ПО: Минцифры наконец опубликовало требования

—

от автора

13 октября Минцифры опубликовало проект постановления с требованиями к доверенному ПО. Впервые ИТ-рынок узнал, что ведомство хочет увидеть в доверенном ПО: без известных уязвимостей, со сборкой в контролируемом окружении, с актуальным перечнем компонентов и без обновлений через зарубежные серверы. Проект изменяет сразу три постановления: о реестре российского ПО (№ 1236), о перечне доверенного ПО (№ 1931) и о сроках новых требований к реестру (№ 1937).

Вам нужно знать эти требования, если ваше ПО включено в реестр российского ПО и вы продаете его госзаказчикам на конкурентном рынке и если ваше ПО участвует в КИИ (транспорт, банки, энергетика и т.д.). Читайте дальше, почему это для вас важно.

Я IT-юрист, веду проекты по включению ПО в реестр. Ниже разбираю, что такое доверенное ПО, кому оно нужно и что поменяется, если проект примут.

Сразу оговорюсь: это проект. Он не принят, не вступил в силу и до принятия может поменяться как угодно. Обсуждение идёт на regulation.gov.ru (проект № 171820). Кстати, можно через кнопку «Ваши предложения» внести свои комментарии к тексту, но для этого необходимо будет авторизоваться через Госуслуги.

Что такое доверенное ПО

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

Если проводить аналогию с разработкой, то реестр российского ПО — это базовая проверка происхождения, а доверенный статус — это аудит безопасности поверх неё.

Отдельного реестра доверенного ПО не будет — это будет дополнительный статус в текущем реестре, то есть вам нужно будет:

  • Получить базовый статус — включить ПО в реестр российского ПО;

  • Заявить о необходимости получения статуса «доверенного ПО» — потребуется отдельная заявка, платная экспертиза в аттестованном центре тестирования и положительное решение комиссии.

  • Подтверждать этот статус — статус будет даваться на 3 года, потом потребуется подтверждение.

  • Также проект вводит и дополнительные требования — пока что получается вот такая картина:

Уровень

Что проверяют

Состояние сейчас

Реестр российского ПО

Права у российского лица, код и инфраструктура в РФ, нет зависимости от иностранных сервисов

Работает, больше 30 тыс. записей

Доверенное ПО

Реестр плюс требования по безопасности

Порядок утверждён, требований не было, перечень пуст

Дополнительные требования

Доверенное плюс российские процессоры, поддержка, API, требования по классам ПО

Только в проекте

Кому это нужно

  1. Тем, кто продаёт в госзакупки. С 1 марта 2026 года действует правило: если в закупке ПО участвует заявка с доверенным продуктом, заявка с обычным реестровым ПО приравнивается к иностранной. Пока перечень доверенного ПО был пуст — правило не работало. Как только в вашем классе появятся первые доверенные продукты, обычная реестровая запись в таких закупках перестанет быть конкурентным преимуществом. Так что вам необходимо оценить, есть ли у вас крупные конкуренты — и если да, то поставить себе в план задачи по получению признака «доверенного» ПО.

  2. Тем, кто поставляет ПО в критическую информационную инфраструктуру: банкам, энергетике, транспорту, связи, госорганам. Механизм доверенного ПО появился именно из законодательства о КИИ.

  3. Косвенно всем, кто в реестре или собирается туда. Если у вас десктопное ПО, то две ОС, на которых оно работает, должны быть доверенными (но пока что их нет, а когда появятся — необходимо будет обеспечить совместимость). Срок исполнения зависит от класса ПО, это будет разобрано ниже.

Обратите внимание. Если у вас продукт для малого и среднего бизнеса, вы не работаете с госзаказчиками, а запись в реестре вам нужна ради освобождения от НДС и упрощенной ИТ-аккредитации (без необходимости подтверждения зарплат), то доверенный статус вам ничего не даст. Платить за экспертизу незачем.

Откуда это вообще все взялось?

Коротко: понятие доверенного ПО ввели в закон о безопасности КИИ. ПО признают доверенным, если одновременно выполнены четыре условия:

  1. Исключительное право принадлежит российскому лицу. Условия жёстче, чем для реестра: например, правообладатель-гражданин не должен иметь второго гражданства.

  2. ПО уже включено в реестр российского ПО или в перечень ПО для собственных нужд.

  3. ПО соответствует требованиям по информационной безопасности. Их устанавливает Правительство по согласованию с ФСБ и ФСТЭК.

  4. Сведения о ПО не составляют гостайну.

Правительство может вводить для доверенного ПО ещё и дополнительные требования (именно поэтому и был разработан проект, о котором идет речь). Процедура присвоения статуса доверенного ПО такая:

  • заявление подаётся на сайте реестра, указывается номер реестровой записи;

  • за 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 года.

Снять её могут не только по истечении срока. Любое лицо может обратиться в реестр с документами, подтверждающими несоответствие (так что нужно будет следить за соответствием требованиям не только на срок рассмотрения заявки, но и все время).

Что ещё поменяется для всех в реестре

  • Если продукт исключат из реестра, на следующий рабочий день его исключат и из перечня доверенного ПО.

  • Из правил реестра убирают формулировку о проверках «не реже одного раза в год». Проверять будут по методике Минцифры, без привязки к годовому циклу.

Что делать сейчас

Сначала нужно определить, насколько вас затронут эти изменения.

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

  2. У вас SaaS/устанавливаемое ПО для коммерческого сектора или B2C. Я бы рекомендовала вам подать заявку на включение в реестр РПО сейчас, пока еще мы живем по старым правилам и без доверенного ПО.

  3. Если вы продаёте в госсектор или КИИ. Уже можно проанализировать требования, дорабатывать свое ПО (и быть готовым к изменениям финального текста).

Когда проект примут или изменят, я обновлю статью.

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

ссылка на оригинал статьи https://habr.com/ru/articles/1095362/