Минцифры собирается проверить российский софт на доверие и потребовать доказательств его безопасности

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

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

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

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

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

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

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

• архитектуру продукта;
• программные зависимости;
• сборку и тестирование;
• исправление найденных дефектов.

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

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

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

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

Операционная система, СУБД, офисный пакет и мессенджер решают разные задачи, поэтому для каждого класса в проекте прописаны собственные критерии, и фокус у каждого свой:

• операционные системы проверят по архитектуре, механизмам обновления и взаимодействию с аппаратной платформой;
• СУБД по условиям хранения и обработки информации;
• средства коммуникации по защите передаваемых сведений и взаимодействию с другими сервисами.

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

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

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

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

Эксперты CISOCLUB отметили, что отметка в реестре закрывает вопрос происхождения, но не отменяет необходимость самим проверять продукт перед внедрением. Экспертиза проводится на конкретной версии, а код меняется с каждым релизом, поэтому доверие к вендору держится на скорости патчей, а не на разовой бумаге. Список компонентов приближает рынок к управлению рисками цепочки поставок, но польза от него появится только при регулярном обновлении и сверке с базами уязвимостей. Контролируемая сборка в России снимает вопросы юрисдикции, при этом она не заменяет анализ кода и тестирование на проникновение. Заказчикам стоит закладывать в контракты сроки исправления уязвимостей и доступ к составу компонентов. Если механизм получит реальный вес в закупках, вендорам придётся выстроить зрелые процессы разработки, и рынок от этого выиграет.

Ранее сообщалось, что Минцифры выступило против инициативы Минфина изменить порядок расчёта налоговых льгот для аккредитованных ИТ-компаний. Минфин предлагает не учитывать сделки между взаимозависимыми лицами при определении обязательной доли профильной выручки, которая должна составлять не менее 70%. Как следует из письма главы Минцифры Максута Шадаева от 30 сентября, ведомство готово обсуждать законопроект только после исключения спорного положения.