Почему российскому ПО нужна своя цепочка доверия

Softline

Jul 17, 2026 • 10:30

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

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

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

В России начали тестировать технологический удостоверяющий центр, который должен выдавать отечественным разработчикам сертификаты подписи кода вместо западных. Над решением работает отраслевая рабочая группа «Единое пространство доверия». С конца 2025 года систему проверяли российские разработчики средств защиты, операционных систем и инфраструктурного ПО.

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

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

Подпись кода стала частью безопасности поставки

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

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

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

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

Особенно чувствительны к этому организации с требованиями по информационной безопасности и КИИ: им важно не просто запустить программу, а подтвердить происхождение, неизменность и управляемость всего жизненного цикла продукта», — отметила Ольга Луценко, ведущий эксперт UDV Group.

Проблема не заканчивается на разработчике

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

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

«Переход к российским механизмам подписи кода должен сопровождаться не только технической настройкой, но и пересмотром внутренних процессов у заказчиков. Компаниям нужно понимать, какие программные продукты используются в инфраструктуре, как они обновляются, кто отвечает за проверку дистрибутивов и какие действия предусмотрены при недоверенной или отозванной подписи», — подчеркнула Ольга Луценко, ведущий эксперт UDV Group.

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

Иностранные ОС добавляют сложности

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

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

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

Российское ПО должно быть не только отечественным, но и проверяемым

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

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

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

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

Цепочка доверия становится частью технологической независимости

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

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

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