Доверенное ПО: зачем разработчику ещё один статус от Минцифры

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

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

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

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

Что даёт статус

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

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

Правило содержится в подпункте «х» пункта 4 Постановления Правительства РФ от 23 декабря 2024 года № 1875.

Механика напоминает «второй лишний», только на другом уровне: сперва российские программы получают преимущество перед иностранными, а затем доверенная программа получает преимущество перед обычными российскими.

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

Дело в новых требованиях к совместимости. Чтобы сохранить место в реестре, некоторым классам ПО придётся работать минимум с двумя операционными системами, соответствующими требованиям к доверенному ПО. Офисный софт должен выполнить это условие с 1 сентября 2026 года. Для серверного ПО, средств виртуализации, СУБД и инструментов разработки срок наступит 1 января 2027 года. Прикладное и отраслевое ПО ждёт 1 июня 2027 года, промышленное ПО 1 января 2028 года.

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

КИИ здесь ни при чём. По крайней мере, пока

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

Закон этого не говорит.

Обязанность для значимых объектов КИИ сформулирована через реестр российского ПО. Требование применять именно доверенное ПО может появиться в отдельном федеральном законе, указе Президента или акте Правительства. Сам по себе перечень такую обязанность не создаёт.

Рядом существует ещё одна конструкция: доверенные программно-аппаратные комплексы. Название почти то же, содержание другое. Перевод объектов КИИ на доверенные ПАК действительно предусмотрен, но программа внутри такого комплекса не обязана иметь статус доверенного ПО. Обратное тоже верно: отметка в реестре программ ничего не говорит о статусе всего комплекса.

Это два параллельных режима. Законодатель, похоже, решил проверить внимательность рынка на одинаковых прилагательных.

Второе гражданство может закрыть доступ к статусу

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

Гораздо интереснее устроены требования к правообладателю.

Исключительное право должно принадлежать российскому публичному образованию, российской организации под контролем разрешённых законом лиц либо гражданину России без иностранного гражданства. Для коммерческой компании проверяется и гражданство человека, который её контролирует.

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

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

Разработку придётся показать изнутри

Правила формирования перечня утверждены Постановлением Правительства РФ от 28 ноября 2025 года № 1931. Детальные требования к информационной безопасности пока проходят стадию проекта. Гарантировать, что итоговая редакция останется такой же, нельзя.

В нынешнем тексте проекта государство смотрит на весь жизненный цикл продукта.

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

На этом месте юридический текст начинает вмешиваться в архитектуру.

Обычный pipeline подтягивает зависимости из внешних репозиториев, запускает сборку в облаке, отправляет результаты тестирования в сторонние сервисы. Команда может хранить код на зарубежной платформе и даже не задумываться, в какой стране физически работает runner. Для коммерческой разработки всё это нормально, а для доверенного ПО каждый такой узел становится вопросом на экспертизе.

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

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

Сам по себе баг-трекер проблему не решает. Эксперту важна цепочка: как команда принимает сообщение об уязвимости, кто оценивает её опасность, где фиксируется решение, как выпускается патч и каким образом пользователь узнаёт об обновлении. Если процесс существует только в головах разработчиков и переписке в корпоративном чате, подтвердить его будет трудно.

Автообновления тоже попадают под проверку

По проекту обновление можно устанавливать только с разрешения пользователя. Такое разрешение допускается получить через лицензионное соглашение, поэтому полностью отказываться от автоматического обновления, вероятно, не придётся. Но привычная схема «мы сами всё обновили, пользователь ничего не заметил» потребует юридического основания и технического описания.

Серверы и программные средства, через которые распространяются обновления, должны находиться в России. Разместить в российском дата-центре копию зарубежного сервиса недостаточно, если сам сервис контролирует иностранный поставщик.

После обновления программа обязана по-прежнему соответствовать требованиям. Это звучит очевидно, пока команда не меняет библиотеку, механизм авторизации или поставщика инфраструктуры. Релиз, который прошёл обычные функциональные тесты, может затронуть условия доверенного статуса. Значит, проверку соответствия придётся встроить в выпуск версии, а не проводить раз в три года перед очередной экспертизой.

Информацию об обновлениях нужно публиковать на сайте или предоставлять пользователям по запросу. Там же размещаются контакты технической поддержки, режим её работы и порядок обращения. Поддержка должна быть доступна по всей России.

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

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

Что проверят по безопасности

В продукте не должно оставаться незакрытых уязвимостей из банка данных угроз ФСТЭК. Проект также ссылается на раздел 5 ГОСТ Р 56939-2024 о безопасной разработке.

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

С 1 марта 2028 года добавится требование о совместимости с российским процессором. Процессор должен соответствовать первому или второму уровню и находиться в реестре российской промышленной либо радиоэлектронной продукции.

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

У операционных систем, СУБД, офисного и промышленного ПО будут дополнительные требования — общей части им не хватит.

Три с половиной месяца только на формальную процедуру

Заявление подаётся через сайт реестра российского ПО. В нём указывают реестровую запись, название программы, прежние и альтернативные названия, коды ОКПД 2, класс ПО, правообладателей и контакты.

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

Далее решение комиссии становится основанием для отметки в реестре.

Если сложить все сроки, которые прямо указаны в правилах, получится около 77 рабочих дней (примерно три с половиной месяца). Это расчёт для продукта, который уже готов к экспертизе и не требует доработки.

Есть и неопределённость: правила не ограничивают время рассмотрения вопроса Правительственной комиссией. То есть, пока никто не может обещать, что процесс закончится ровно через 77 рабочих дней.

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

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

Подавать заявление или сначала переделывать инфраструктуру

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

Но перестраивать CI/CD по тексту проекта тоже рано. Итоговые требования могут измениться.

До их утверждения имеет смысл провести внутреннюю ревизию: проверить структуру контроля над компанией, восстановить цепочку исключительных прав, составить список open source-компонентов, описать выпуск обновлений и понять, какие внешние сервисы участвуют в разработке. Такая работа пригодится независимо от финальной редакции постановления.

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