Доверенное ПО: какие требования безопасности и совместимости предлагает Минцифры осенью 2026 года

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

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

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

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

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

1. Реестр российского ПО, доверенный статус и дополнительные характеристики

Почему обычная реестровая запись не заменяет доверенный статус

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

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

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

Если компания использует в коммерческих материалах слово «доверенный», необходимо понимать основание такого утверждения. Формулировки на сайте и в предложениях должны соответствовать фактическому статусу программы.

Какие уровни нужно различать

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

Что важно в статусе октябрьского проекта

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

Это особенно важно для бюджетирования. Разработчик может заранее улучшать процессы работы с компонентами и документацией, но не должен закупать произвольные услуги под обещание «нового обязательного сертификата», если применимость такого требования не установлена.

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

Дополнительные требования предложены как добровольный блок

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

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

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

2. Какие вопросы безопасности разработчику стоит проверить заранее

Состав программы должен быть известен самому правообладателю

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

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

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

Не нужно заранее объявлять собственную таблицу единственной обязательной формой. Формат выбирается под задачу, а его соответствие официальной процедуре проверяется отдельно. Главное на начальном этапе — получить достоверное представление о составе продукта.

Прямые и косвенные зависимости

Команда обычно знает библиотеки, которые подключила непосредственно. Но они могут использовать другие компоненты, а те — собственные зависимости. Если учитывать только первый уровень, картина остаётся неполной.

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

Без такого учёта обсуждение безопасности превращается в поиск по разным репозиториям и сборочным файлам. Систематизированный состав помогает быстрее принимать решения и готовить объяснения для заказчиков.

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

Работа с уязвимостями должна иметь понятный порядок

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

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

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

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

Исходный код и возможность собрать продукт

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

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

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

При этом контролируемое окружение нельзя сводить к одному признаку, например расположению сервера. Нужно рассматривать доступ, управление изменениями, используемые инструменты и другие условия, предусмотренные применимыми требованиями.

Доступы и ответственность за изменения

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

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

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

Права на компоненты и безопасность нельзя рассматривать отдельно

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

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

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

Сертификаты необходимо читать по предмету подтверждения

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

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

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

3. Дополнительные характеристики: процессоры, браузеры, интеграции и сопровождение

Совместимость с отечественными процессорами

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

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

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

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

Поддержка российских браузеров

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

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

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

Само наличие слова «веб» в описании продукта не подтверждает одинаковую работу во всех браузерах. Также результат для одной версии не следует без проверки распространять на любое будущее обновление.

Программные интерфейсы для интеграции

В проекте дополнительного блока рассматриваются интерфейсы для взаимодействия с внешними системами. Для бизнеса это связано с практической задачей: заказчик редко использует корпоративную программу изолированно.

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

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

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

Техническая поддержка и выпуск обновлений

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

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

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

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

Требования к отдельным классам программ

Проект дополнительного блока предусматривает особенности для ряда классов системного и офисного ПО, а также для PLM-систем. Поэтому продукт нужно оценивать с учётом его назначения и классификации.

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

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

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

Что даёт дополнительное подтверждение

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

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

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

4. Как подготовить продукт и документы к возможным изменениям

Определите цель и границы подготовки

Работу стоит начать с короткого описания задачи. Какой продукт рассматривается? Какая версия поставляется? Есть ли действующая реестровая запись? Для какого статуса готовятся документы? Какие заказчики предъявляют дополнительные требования?

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

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

Соберите единое досье продукта

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

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

Сопоставьте документы с фактической системой

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

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

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

Разделите замечания по важности

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

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

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

Подготовьте сотрудников к ответам на вопросы

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

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

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

Сохраняйте конфиденциальность без потери доказательности

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

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

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

Пример: корпоративная платформа с открытыми компонентами

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

В такой ситуации первым шагом становится восстановление фактического состава текущего выпуска. Затем можно связать компоненты с лицензионными условиями, процессом обновления и результатами проверок.

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

Пример: промышленное ПО с оборудованием

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

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

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

Как не потерять результат после выпуска новой версии

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

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

Это не означает автоматической необходимости заново проходить всю процедуру при любом изменении. Конкретные действия определяются применимыми правилами и характером обновления. Внутренняя задача — вовремя заметить изменение, которое влияет на ранее подготовленные сведения.

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

5. Ответы на вопросы и порядок дальнейших действий

Любая программа из реестра Минцифры считается доверенной?

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

Все дополнительные требования из проекта станут обязательными?

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

Нужно ли уже сейчас покупать услуги сертификации?

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

Достаточно ли хранить исходный код на сервере в России?

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

Гарантирует ли доверенный статус победу в закупке?

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

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

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

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

Как помогает МинпромХелп

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

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

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