Программа подписана, а SmartScreen всё равно предупреждает

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

Сохраните точное сообщение Windows

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

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

Подпись отвечает на один вопрос, репутация — на другой

В документации Microsoft о SmartScreen названы сигналы издателя и конкретного файла. Новый подписанный выпуск может по-прежнему вызывать предупреждение. Там же отмечено, что EV-сертификат больше не даёт автоматического обхода SmartScreen. Поэтому обещание «подпишем — и предупреждений точно не будет» не подходит как условие приёмки.

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

У SignTool есть проверка подписи, но документация отдельно различает политики проверки. Значение имеет не только слово «проверено» в отчёте, но и то, что проверяли, каким способом и с каким результатом. Не выдавайте проверку одного файла за заключение обо всём комплекте поставки.

Паспорт поставки: что сравнить у разработчика и пользователя

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

Если подпись отсутствует или не проходит проверку

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

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

Если подпись корректна, а предупреждение осталось

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

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

Прогон релиза и следующего обновления

1. Согласуйте канал распространения и перечень файлов, для которых требуется подпись. Проверьте право использовать указанное имя издателя.
2. Получите конечный комплект через этот канал в разрешённой тестовой среде. Запишите его версию и идентификатор артефакта.
3. Проверьте подписи применимых компонентов корректным способом и сохраните результат. Отдельно зафиксируйте сообщения системы.
4. Сопоставьте наблюдения с утверждённым комплектом. Любое отличие должно иметь объяснение до передачи заказчику.
5. В пределах согласованных испытаний проверьте обновление существующей установки. Не ограничивайтесь новой установкой на машине разработчика.
6. Составьте пользовательскую инструкцию по проверке источника и обращению за помощью. Она не должна требовать отключать защиту или менять корпоративные политики.

Что зафиксировать в задании и акте проверки

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

В результате проверки полезно разделить выполненные требования и наблюдения внешней системы. Например: конечный установщик проверен и соответствует релизу; сообщение SmartScreen сохранено и разобрано; особенности управляемой среды переданы заказчику. Это проверяемые утверждения. Формулировка «любая Windows больше ничего не спросит» остаётся неподтверждённым обещанием.

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