Как будет проверяться доверенное ПО: проект Минцифры вынесен на обсуждение

Российское ИТ-регулирование готовится к очередному повороту. Постановление № 1931 заложило основу института доверенного софта, а сейчас на общественное обсуждение вынесен проект изменений сразу в три акта: постановления № 1236 о реестре отечественного ПО, № 1931 о перечне доверенных программ и № 1937 о переходных сроках. Доверенное российское ПО остаётся главной темой повестки: новый документ впервые отвечает, какие бывают требования к ПО в новой модели и как именно они будут проверяться.

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

Дисклеймер: это пока только проект Минцифры

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

Именно этот пробел закрывает вынесенный на общественное обсуждение проект изменений: утверждаются требования к доверенному программному обеспечению – два самостоятельных приложения о требованиях к обеспечению информационной безопасности и о дополнительных функциональных требованиях. Всё, что описано в статье ниже, – это анализ именно этих новых требований и дополняющих процедурных новелл, а не действующих норм. Формулировки могут измениться до официального опубликования постановления, какие-то требования – смягчиться или исчезнуть, сроки – снова сдвинуться. Показательно, что и сам проект Минцифры по доверенному ПО уже содержит признание неготовности рынка: сроки поэтапного применения норм постановления № 1937 переносятся на год – с 1 сентября 2026-го на 1 сентября 2027-го и далее по цепочке до 2029 года.

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

• для ПО, основная функция которого защита ЗКИ;
• для SaaS-сервисов.

Проект выстраивает и понятную трёхуровневую модель:

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

Ниже разберём, чем уровни различаются по содержанию, процедуре и выгодам.

Требования к доверенному программному обеспечению

Главная новация проекта – впервые формализуется содержание двух уровней доверенности. Требования к доверенному программному обеспечению делятся на обязательные и дополнительные. Обязательные отделяют доверенный продукт от обычного реестрового, их выполнение позволяет получить отметку “доверенного ПО” в Реестре. Второй уровень доверенности предполагает выполнение особых дополнительных требований в добровольном порядке. Отметка об их выполнении также вносится в виде отметки в Реестре отечественного ПО.

База

Базовые требования короткие, но содержательно жёсткие:

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

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

Дополнительные функциональные требования

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

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

К общим относятся: совместимость с российскими процессорами первого или второго уровня, техподдержка на всей территории страны, публикация документации по API, наличие у правообладателя инфраструктуры и материалов для обучения пользователей. Классовые требования расписаны детально – от офисных пакетов и браузеров до PLM-систем и СУБД.

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

Дополнительные требования к доверенному ПО

Процессорное требование

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

У проекта есть встроенная «отсрочка»: совместимость подтверждается не сразу, а в соответствии с план-графиком, который Минцифры по согласованию с Минпромторгом должно утвердить в шестимесячный срок после опубликования изменяющего постановления. Именно график станет реальным регулятором жёсткости: если ведомство заложит в него длинные горизонты, у разработчиков будет время на портирование; если короткие – значительная часть реестра окажется под угрозой несоответствия. До появления плана-графика требование фактически не работает, и это одна из самых обсуждаемых точек проекта.

Механизм – «не менее чем один» по конкретным классам

Если доступ к ПО осуществляется только через браузер, его функции должны полностью работать не менее чем в одном браузере, который сам соответствует требованиям к доверенному ПО (поддержка HTML5, CSS3, JavaScript, сертификаты национального УЦ, интеграция со средствами ЭЦП). PLM-системы должны быть совместимы не менее чем с одной отечественной СУБД.

Логика единая: государство требует работоспособности в российской программной среде, но фиксирует минимальную планку – один совместимый продукт, а не веер интеграций.

Требования, которые предъявляются к самим ОС

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

Таким образом, реестр доверенного российского ПО в этой конструкции опирается не на список обязательных ОС, а на связку «отечественный процессор + отечественная программная среда». Практический вывод для разработчиков: несовместимость с конкретной ОС сама по себе не станет основанием для отказа, но отсутствие сборки под российские процессоры в сроки плана-графика – станет. А для покупателей статус доверенного – это косвенная гарантия, что софт реально заработает на отечественной инфраструктуре, а не только в лаборатории разработчика.

Как получить статус доверенного ПО с отметкой о выполнении доп требований

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

• Шаг 0. База. Начинать нужно всегда с получения общего базового статуса – включения в реестр отечественных программ. Здесь мы можем помочь уже сейчас.
• Шаг 1. Заявление. Действовать нужно через электронные формы в самом реестре. Заполняя форму, нужно указать в том числе номер действующей реестровой записи.
• Шаг 2. Выбор центра. В течение 30 рабочих дней заявитель выбирает центр тестирования, договаривается с ним о проведении экспертизы и передаёт копию договора в Минцифры. Не уложился – рассмотрение прекращается.
• Шаг 3. Экспертиза. Центр исследует софт на соответствие требованиям. По итогам формируется экспертное заключение, к нему прилагается протокол с датой, сведениями о продукте и правообладателях, перечнем проверенных требований. В случае несоответствия – обоснование даётся по каждому пункту.
• Шаг 4. Решение. При положительном выводе министерство принимает решение о соответствии в течение 10 рабочих дней и уведомляет заявителя. При отрицательном – решение о несоответствии.
• Шаг 5. Срок действия и продление. Решение о соответствии действует три года. Не ранее чем за три месяца до истечения срока подаётся новое заявление, и цикл повторяется. Это важный момент: подтверждение доверенного ПО – не разовое событие, а регулярная процедура, которую разработчику придётся закладывать в бюджет и календарь.

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

Центры тестирования доверенного ПО

Центр тестирования доверенного ПО – ключевой институт новой модели, и проект заметно достраивает его работу.

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

Проект вводит полноценный механизм гражданского контроля. Любое физическое или юридическое лицо может подать обращение о несоответствии софта из реестра дополнительным требованиям. Уполномоченный орган проверяет документы и регистрирует обращение в течение 5 рабочих дней (если подтверждений нет – отказ с указанием причин), после чего передаёт обращение в центр тестирования через официальный сайт. Центр рассматривает его в течение 30 рабочих дней, при этом разработчику предоставляется 20 рабочих дней на пояснения и дополнительные материалы – на этот период срок рассмотрения приостанавливается.

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

Реестр доверенного ПО Минцифры: исключительные преимущества

Зачем разработчику весь этот путь? Ответ – в преимуществах, которые даёт реестр доверенного ПО Минцифры.

• Во-первых, максимальный приоритет в госзакупках. Как мы писали ранее, при участии доверенного российского ПО в закупке все остальные предложения, включая обычный софт из реестра, приравниваются к иностранным. При этом вопрос о том, какие реальные бонусы будет давать отметка о соблюдении дополнительных требований, пока остаётся открытым.
• Во-вторых, статус становится маркером качества и безопасности, который понятен и закупщику, и конечному пользователю. Признак соответствия дополнительным требованиям прямо в реестровой записи избавляет от необходимости верить маркетинговым материалам – факт виден в реестре доверенного ПО.
• В-третьих, для продуктов из перечня открывается доступ к режиму, ради которого модель создавалась: формирование устойчивой экосистемы, где отечественные решения работают на отечественном железе с проверенными обновлениями и прозрачным составом компонентов. Реестр доверенного российского ПО в этом смысле становится ядром новой инфраструктуры российского софта.

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

Что в итоге?

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

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