Кажется абсурдом: компания годами разрабатывает сложное ПО, инвестирует в R&D и маркетинг, а через несколько лет после релиза обнаруживает, что её система имеет фундаментальные уязвимости, о которых разработчики, возможно, догадывались. Но бизнес продолжает продавать и поддерживать эти продукты. В этом нет злого умысла, это закономерный результат сходящихся трендов: давления рынка, устаревающих парадигм безопасности и экономических расчётов, где стоимость исправления проигрывает стоимости возможных потерь от взлома. Понимание этих механизмов — ключ к выбору инструментов не по красивым обещаниям, а по оценке реального риска. https://seberd.ru/5641
Совершенство в вакууме против требований рынка
Представьте проект, который стартует с идеального с точки зрения безопасности технического задания. Архитектура — zero trust, все компоненты верифицированы формальными методами, код проходит статический и динамический анализ с высочайшим уровнем покрытия. Разработка такого продукта займёт годы и потребует бюджета, несопоставимого с ожиданиями рынка по срокам и цене. К моменту релиза технологический ландшафт уже изменится, а конкуренты, выпустившие более простые, но функциональные решения, захватят долю.
Поэтому вендоры изначально принимают компромиссное решение: выпускать продукт с приемлемым, по их внутренней оценке, уровнем риска. Эта оценка основана не на абстрактной «неуязвимости», а на анализе угроз на момент проектирования. Уязвимости, которые проявятся позже — будь то новые классы атак (например, спекулятивное выполнение в процессорах) или ошибки в сторонних библиотеках, — изначально не входят в модель угроз. Продаётся не «невзламываемый замок», а «замок, достаточно надёжный для большинства известных отмычек».
Экономика исправления: когда патч дороже ущерба
Обнаружение серьёзной уязвимости в уже развёрнутом и проданном продукте ставит вендора перед сложным выбором. Полное исправление может потребовать:
- Кардинального изменения архитектуры, что делает несовместимыми обновления.
- Переписывания значительных частей кодовой базы, что останавливает разработку новых функций.
- Организации масштабной программы обновления для тысяч клиентов.
Вендор проводит холодный расчёт: сравнивает совокупную стоимость этих действий (включая репутационные потери) с потенциальными убытками от эксплуатации уязвимости. Если убытки вероятны, но не гарантированы, а затраты на исправление огромны и могут подорвать финансовую устойчивость компании, решение может быть не в пользу немедленного патча. Вместо этого вендор может выпустить workaround — рекомендацию по конфигурации, снижающую риск, или добавить обнаружение такой атаки в свои системы мониторинга, фактически перекладывая часть ответственности по реагированию на клиента.
Это особенно характерно для legacy-систем в критической инфраструктуре, где простое «обновление до последней версии» невозможно из-за требований к бесперебойной работе и сертификации.
Сложность как враг безопасности и друг продаж
Современное корпоративное ПО, это колоссальная сложность: миллионы строк кода, сотни зависимостей, интеграция с десятками внешних сервисов. Ни одна команда не в состоянии полностью проанализировать все возможные векторы атаки в такой системе. Уязвимости становятся неизбежным следствием этой сложности.
Парадоксально, но та же самая сложность становится маркетинговым преимуществом. Вендор продаёт не просто набор функций, а «единую платформу», «экосистему», «цифровую среду». Клиент покупает возможность решить бизнес-задачу одним комплексным решением, а не собирать пазл из десятков узкоспециализированных инструментов. Принимая такое решение, клиент неявно соглашается с присущим ему уровнем риска, компенсируемым, по мнению вендора, удобством и интеграцией.
Более того, сложность позволяет вендору выстраивать многоуровневую систему ответственности. Когда происходит инцидент, всегда можно указать на неправильную конфигурацию со стороны клиента, использование нерекомендованных компонентов или действия злоумышленника, использовавшего неизвестную (zero-day) уязвимость. Это размывает понятие вины.
Цикл поддержки и политика устаревания
Практически каждый коммерческий продукт имеет чётко определённый жизненный цикл (product lifecycle). Активная фаза разработки и полноценной поддержки с выпуском патчей безопасности ограничена несколькими годами. После этого продукт переходит в фазу «расширенной поддержки», где исправляются только критические уязвимости, а затем и вовсе в фазу прекращения поддержки.
Вендор, продавая решение, знает этот график. Он знает, что через определённое время ресурсы на поддержку безопасности будут перераспределены на новое поколение продуктов. Клиент, покупая лицензию, фактически приобретает не вечную гарантию, а «срок службы» продукта с точки зрения безопасности. Вопрос «будет ли оно взломано?» трансформируется в «когда это произойдёт и попадёт ли это в период активной поддержки?». Для вендора экономически выгоднее стимулировать переход клиентов на новые версии, чем бесконечно латать старые.
Регуляторное давление и сертификация как щит
В таких регулируемых отраслях, как банковская сфера или государственный сектор, ключевым фактором при выборе решения часто является наличие сертификатов — ФСТЭК, ФСБ, Минцифры. Процесс сертификации — длительный и дорогой. Он подтверждает соответствие продукта определённым стандартам защиты информации на конкретную дату в контролируемых условиях.
Для вендора получение сертификата, это мощный маркетинговый и юридический аргумент. Фактически он говорит: «На момент проверки государственными экспертами продукт соответствовал требованиям». Это снимает с производителя часть будущей ответственности. Если через год после сертификации будет обнаружена уязвимость, вендор может сослаться на то, что атака использует метод, не описанный в методиках оценки на момент сертификации, или что конфигурация у клиента отличалась от тестовой. Таким образом, сертификация становится не гарантией неуязвимости, а формализованным распределением рисков между вендором, регулятором и потребителем.
Клиент, полагаясь на сертификат, часто снижает собственную бдительность, считая вопрос безопасности решённым, что в корне неверно.
Страхование и передача риска
Крупные ИТ-вендоры всё чаще рассматривают киберриски через призму страховых моделей. Они могут выстраивать свою политику обновлений и реагирования на инциденты, исходя из анализа вероятности наступления страхового случая и размера возможных выплат по судебным искам или гарантийным обязательствам.
Наличие у компании-клиента собственной киберстраховки также косвенно влияет на поведение вендора. Если клиент застрахован, его стимулы к предъявлению претензий к поставщику ПО после взлома могут быть ниже — убытки покроет страховая. Это создаёт своеобразный буфер, позволяющий вендору быть менее агрессивным в выпуске дорогостоящих исправлений для всех, сосредоточившись только на самых громких случаях.
Что делать потребителю: смещение фокуса с продукта на процесс
Понимание описанных механизмов приводит к важному выводу: нельзя полагаться на безопасность как на inherent property (неотъемлемое свойство) купленного продукта. Безопасность, это процесс, за который в конечном итоге несёт ответственность сам потребитель.
При выборе и эксплуатации коммерческого ПО необходимо:
- Оценивать не обещания, а практику. Изучать историю исправлений уязвимостей (CVE) для продукта: как часто они обнаруживаются, как быстро вендор выпускает патчи, насколько они критические. Прозрачность security bulletin — важный индикатор.
- Требовать понятные SLA по безопасности. В договор должны быть включены не только общие фразы, но и конкретные сроки реагирования на критические уязвимости, условия предоставления временных мер защиты (workaround) и политика уведомлений.
- Планировать жизненный цикл. Заранее знать график поддержки продукта и планировать миграцию на новые версии или аналоги до наступления фазы end-of-life.
- Не ограничиваться «коробкой». Внедрять дополнительные слои защиты (сегментацию сети, WAF, EDR) даже для сертифицированных продуктов, исходя из принципа глубины обороны (defense in depth).
- Участвовать в отраслевых ISAC. Обмен информацией об угрозах и уязвимостях с другими потребителями похожих решений помогает быстрее получать информацию, в обход формальных каналов вендора.
Вендоры будут продолжать продавать решения, зная об их потенциальных слабостях, потому что эта модель экономически и технологически устойчива. Задача специалиста по безопасности — не искать мифический «невзламываемый» продукт, а выстраивать такие процессы управления рисками, где уязвимость вендорского ПО становится лишь одним из многих управляемых факторов, а не фатальной угрозой.