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

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

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

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

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

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

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

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

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

Дополнительная сложность связана с иностранными операционными системами. В Windows, macOS и мобильных платформах зарубежных поставщиков российские «корни доверия» не встроены по умолчанию. Поэтому проверка отечественных сертификатов может потребовать отдельных решений и дополнительных процедур со стороны ИТ- и ИБ-команд.

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

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

Это одна из главных проблем современных SOC и ИТ-команд. Инфраструктура стала слишком связанной, чтобы разбирать события изолированно. Один алерт из EDR, одно срабатывание SIEM, один скачок нагрузки, один отказ сервиса или одно обращение пользователя редко объясняют ситуацию целиком. Инцидент становится понятен только тогда, когда события связываются между собой: какой актив затронут, какой сервис зависит от него, какие пользователи пострадали, какие действия уже были выполнены и есть ли признаки атаки.

Мы в UDV Group видим, что компании часто начинают с накопления инструментов. Есть мониторинг инфраструктуры, SIEM, EDR, NTA, ServiceDesk, сканер уязвимостей, журналы приложений, облачные консоли, средства контроля доступов. Каждый инструмент полезен в своей зоне, но проблема появляется на стыке. Когда событие приходит из одного источника, а контекст лежит в другом, команда тратит время не на реакцию, а на ручную сборку картины.

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

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

На самом деле вопрос не в том, кто важнее. Вопрос в том, хватает ли данных для правильного решения. Можно ли безопасно перезапустить сервис? Нужно ли сначала снять образ или собрать дамп памяти? Связан ли сбой с атакой? Затронут ли только один узел или есть движение по сети? Какие бизнес-процессы зависят от системы? Кто владелец актива? Без ответов на эти вопросы реакция становится либо слишком медленной, либо слишком рискованной.

Мы в UDV Group считаем, что зрелая работа с инцидентами начинается не с большего числа алертов, а с нормального контекста. Событие должно сразу связываться с активом, владельцем, критичностью сервиса, уязвимостями, учетными записями, сетевыми взаимодействиями, историей изменений и обращениями в ServiceDesk. Тогда команда видит не отдельный сигнал, а его место в инфраструктуре.

Например, одно и то же срабатывание на рабочей станции может иметь разный приоритет. Если это обычный пользовательский ноутбук без доступа к критичным системам, сценарий один. Если это инженерная станция, администраторский узел, сервер с доступом к резервным копиям или машина подрядчика с VPN-доступом, реакция должна быть другой. Алерт один, риск разный.

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

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

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

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

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

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

Технически такую модель можно собирать разными способами: через интеграцию SIEM, NTA, EDR, ServiceDesk, CMDB, сканеров уязвимостей, IAM и систем мониторинга. Но цель не в интеграции ради интеграции. Цель — чтобы событие сразу становилось управляемым объектом: с приоритетом, владельцем, контекстом, историей и понятным следующим действием.

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

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

Для нас в UDV Group практический вывод такой: ИТ и ИБ должны смотреть не на набор алертов, а на связанную картину события. Пока каждая команда видит только свой слой, компания теряет время и рискует принять неправильное решение. Когда события связаны с активами, сервисами, пользователями, уязвимостями и бизнес-контекстом, реакция становится быстрее, точнее и безопаснее для бизнеса.