Продукт уже в реестре: что нужно для доверенного статуса

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

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

Реестр и доверенный статус: в чём разница

Главная проблема: реестровая запись может быть устаревшей

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

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

Что нужно проверить в реестровой записи перед подачей

Соответствие описания функциональности текущей версии — сравнить описание в ФГИС с реальным состоянием продукта: новые модули, изменённые ключевые функции или убранная функциональность нужно отразить в записи до экспертизы, поскольку центр тестирования проверяет именно то, что заявлено. Актуальность сведений о правообладателе — правообладатель в записи должен совпадать с тем, кто подаёт заявление на доверенный статус; изменения корпоративной структуры, передача прав или реорганизация должны быть отражены заранее, иначе несоответствие станет основанием для вопросов при регистрации. Соответствие класса ПО по классификатору — классификатор Минцифры обновлялся с момента введения реестра, и класс, указанный несколько лет назад, может не совпадать с актуальной классификацией, а именно класс ПО определяет дедлайн по постановлению №1937, так что ошибка в классификации создаёт риск неверного планирования сроков. Статус записи — действующая или приостановленная — реестровая запись может быть приостановлена, если правообладатель не предоставлял актуализирующие сведения, на основании приостановленной записи заявление на доверенный статус подать нельзя.

Дополнительные требования, которых не было при включении в реестр

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

Типичные ситуации и что делать в каждой

Если реестровая запись актуальна и продукт кросс-платформенный — работает на Linux, права оформлены корректно, — это наилучший сценарий: остаётся развернуть стенд с доверенными ОС и провести внутреннее тестирование, подготовить документацию по безопасности (обычно отсутствующую), инвентаризировать компонентный стек на CVE. Если запись устарела, а продукт с момента включения в реестр два-три года назад существенно изменился — самый распространённый сценарий, — нужно немедленно начать актуализацию реестровой записи, вести техническую и юридическую подготовку параллельно, но не подавать заявление на доверенный статус до завершения актуализации. Если запись в порядке, но продукт разработан под Windows и требует доработки для совместимости с доверенными ОС, стоит провести технический аудит для оценки объёма доработки, составить реалистичный план и вести юридическую подготовку параллельно с самой разработкой.

Преимущества разработчика с действующей реестровой записью

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

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: реестровая запись как обязательное условие подачи заявления по постановлению №1937.
• Реестр российского программного обеспечения, Минцифры России: проверка актуальности и статуса реестровой записи.