Алексей Пашков

За первое полугодие 2026 года медианные зарплатные предложения в сфере информационной безопасности в России выросли на 40% — с 82,8 до 115,6 тыс. рублей в месяц. Одновременно две трети работодателей сообщили о нехватке ИБ-специалистов. Это не временный перегрев рынка, а следствие более глубокого процесса: цифровая инфраструктура усложняется, цена ошибки растёт, а безопасность становится частью практически любой инженерной и бизнес-задачи.

Рост зарплат — только один из признаков удорожания ИБ-экспертизы. Компании платят больше не за формальное наличие подразделения безопасности, а за способность специалистов снижать конкретные бизнес-риски: предотвращать простои, быстро локализовать инциденты и учитывать требования безопасности ещё на этапе проектирования продукта.

Алексей Пашков, руководитель отдела разработки компании МУЛЬТИФАКТОР, объясняет, почему ИБ-экспертиза дорожает, каких специалистов не хватает рынку и как ИИ, импортозамещение и усложнение ИТ-инфраструктуры меняют требования к безопасности.

Цена цифровой зависимости

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

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

Масштаб проблемы показывают данные Threat Intelligence F6: в 2025 году на форумах и в тематических Телеграм-каналах было опубликовано более 767 млн строк с данными российских пользователей против 457 млн годом ранее. Эта цифра не означает сопоставимое количество пострадавших: одна и та же информация могла попасть в несколько баз. В таких условиях безопасность перестаёт быть вспомогательной ИТ-функцией и становится частью управления рисками. Компании уже недостаточно приобрести защитное решение и установить его в инфраструктуре. Необходимо понимать, какие данные и процессы критичны, кто имеет к ним доступ, как устроены интеграции, где находятся резервные копии и что произойдёт, если отдельная система окажется недоступной.

Чем сложнее компания, тем выше риски

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

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

Безопасность начинается до кода

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

Уязвимость может появиться ещё на этапе требований или проектирования архитектуры:

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

Отсюда появляются подход Shift Left и практика DevSecOps: чем раньше команда обнаружит проблему, тем дешевле и безопаснее её исправить. Ошибка, найденная на этапе проектирования, обычно требует пересмотра решения. После выпуска продукта та же проблема может привести к отказу, незапланированному обновлению, простою, расследованию инцидента и репутационным потерям. В МУЛЬТИФАКТОР подход Shift Left встроен в процессы разработки: требования безопасности учитываются уже при постановке задачи, а код проходит автоматизированную проверку зависимостей и секретов до попадания в репозиторий. Это позволяет выявлять архитектурные риски до того, как они перерастут в инциденты.

Изменения затрагивают не только сотрудников, отвечающих за безопасность. Современный специалист по ИБ в продуктовой компании должен разбираться в архитектуре, разработке, инфраструктуре, CI/CD, облачных технологиях и бизнес-логике продукта. Именно пересечение этих компетенций делает опытных специалистов одновременно дорогими и дефицитными. От разработчиков также всё чаще ожидают понимания базовых принципов AppSec: безопасной авторизации, управления секретами, работы с зависимостями, защиты API и инфраструктуры. Хороший разработчик думает не только о том, работает ли его код, но и о том, как его могут атаковать.

ИИ ускоряет разработку и атаки

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

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

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

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

Дефицит связан с опытом

Когда говорят о кадровом голоде в ИБ, обычно имеют в виду не отсутствие людей с профильным дипломом, а нехватку специалистов с практическим опытом — особенно на стыке нескольких областей. Информационная безопасность давно перестала быть профессией с узким набором задач. В отрасли развиваются AppSec, SOC, пентест, Cloud Security, IAM, PKI, безопасная разработка, реагирование на инциденты, комплаенс и другие направления. Специалист, который одновременно умеет оценивать архитектурные риски, понимать ограничения разработки и выстраивать процессы защиты, накапливает такой опыт годами. Одного курса или нескольких месяцев практики для этого недостаточно.

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

  • конкурировать за готовых специалистов;
  • развивать экспертизу внутри команды;
  • дообучать разработчиков, тестировщиков и DevOps-инженеров;
  • выстраивать карьерные треки для начинающих сотрудников;
  • сотрудничать с вузами и образовательными проектами.

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

Импортозамещение добавляет задач

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

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

Что будет дальше

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

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

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

Используемые термины

  • CI/CD (Continuous Integration/Continuous Delivery) — конвейер непрерывной интеграции и поставки или развёртывания.
  • Shift Left — подход раннего внедрения мер безопасности.
  • DevSecOps (Development, Security, Operations) — разработка, безопасность и эксплуатация.
  • AppSec (Application Security) — безопасность приложений.
  • API (Application Programming Interface) — интерфейс прикладного программирования.
  • SOC (Security Operations Center) — центр мониторинга и реагирования на события информационной безопасности.
  • Пентест — сокращение от «тестирование на проникновение».
  • Cloud Security — безопасность облачных сред.
  • IAM (Identity and Access Management) — управление идентификацией и доступом.
  • PKI (Public Key Infrastructure) — инфраструктура открытых ключей.
  • DevOps-инженер — специалист, который объединяет задачи разработки и эксплуатации программных систем.
  • Тестировщик — специалист, который проверяет программное обеспечение на соответствие требованиям, выявляет ошибки и оценивает корректность работы продукта в различных сценариях.
  • Неиспользуемая (учётная запись) — учётная запись пользователя или сервиса, которая больше не нужна для работы, но остаётся активной.
  • Дообучать — дополнительно обучать уже подготовленных сотрудников, чтобы расширить или обновить их знания и навыки.

Источник:
Иллюстрация предоставлена пресс-службой компании