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

1. Социальная инженерия: человек как постоянная уязвимость

Червь Морриса использовал простейшую атаку на доверие — подбор паролей из словаря на 432 слова. Системные администраторы ставили пароли вроде password или собственное имя пользователя.

Сегодня 81% взломов в финансовом секторе начинаются с компрометации учетных данных. Трансформация атак выглядит так: вместо примитивного подбора паролей злоумышленники используют целый арсенал психологических манипуляций — фишинг через электронную почту и мессенджеры, вишинг (голосовой фишинг), дипфейк-технологии для имитации голосов руководителей.

Почему это работает, несмотря на постоянные предупреждения в СМИ, инструкции и тренинги? Потому что основы человеческой психологии неизменны, она не обновляется, как софт. Доверчивость, любопытство, страх, стремление к удобству — это биологические константы. А в стрессовой ситуации человек пропускает признаки фишинга в 68% случаев. Компании ежегодно тратят на обучение персонала большие деньги, но эффект от него падает уже через 3–6 месяцев.

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

Отдельная боль последних лет — подстановка учетных данных (credential stuffing). Это когда аккаунт не взламывают в привычном смысле, а применяют ранее утекший из какого-либо сервиса пароль. Это работает, так как 84% пользователей переиспользуют пароли в разных приложениях и аккаунтах, часто имея один пароль на все. Злоумышленникам ничего не надо придумывать: они берут те же пароли из утечек и запускают автоматическую проверку по банкам, маркетплейсам, почтовым сервисам и платежным системам. Масштаб реально «промышленный» — в год фиксируется более 193 млрд таких попыток подбора, 95% из которых выполняются ботами. Показательно, что 54% паролей, скомпрометированных в 2025 году, уже всплывали в прошлых утечках — то есть люди годами не меняют доступы, даже когда «ключи» были давно похищены.

У нас в стране ситуация усугубляется массовыми утечками данных из самых разных сервисов. В хакерских базах — миллионы записей логинов и паролей российских пользователей. Эти данные активно используются для credential stuffing-атак на банковские приложения и платежные системы. По сути, утечка из какого-то магазина может стать входным билетом в куда более чувствительные сервисы — просто потому, что пароль один и тот же.

2. Программные уязвимости: переполнение буфера в эпоху ИИ

Если подстановка учетных данных — это история о привычках людей, то переполнение буфера — про привычки кода.

Червь Морриса эксплуатировал переполнение буфера в службах fingerd и sendmail на Unix-системах. Эта уязвимость позволяла выполнить произвольный код на целевой машине.

Казалось бы, прошло почти 40 лет, но переполнение буфера и его вариации стабильно держатся среди самых опасных уязвимостей ПО — в 2024–2025 годах они заняли сразу несколько позиций (5, 11, 14 и 16) в CWE Top-25 Most Dangerous Software Weaknesses. А NSA и CISA официально признали, что 70% всех уязвимостей CVE¹ возникает из-за проблем с доступом к памяти устройства. Причем решение известно более 10 лет — это memory-safe-языки программирования (например, Rust или Go). Однако C и C++ остаются стандартом в критической инфраструктуре.

Идея просто перейти изменить архитектуру звучит логично, но сложна в исполнении. Миграция на безопасные языки требует переписывания миллионов строк кода. Например, банковское ПО содержит 50–100 млн строк кода, а обновление базовых банковских систем обходится в 50–200 млн долларов и может занять годы. Перевод такого массива на memory-safe-стек эквивалентен замене фундамента здания во время его эксплуатации. Поэтому вместо радикальных изменений команды добавляют патчи и временные решения, накапливая технический долг.

Многие отечественные банки используют АБС, написанные еще в 90-х и 2000-х годах. Их ядро часто базируется на языках вроде C, Delphi или даже устаревших версиях Oracle Forms. Переписать эти системы практически невозможно — они содержат десятилетиями накопленные бизнес-логику, интеграции, ручные доработки. В результате банки продолжают эксплуатировать потенциально уязвимый код, прикрывая его дополнительными слоями защиты.

Сложность есть и с API. С 2020 года количество уязвимостей в API выросло на 400%. Современные финтех-приложения интегрируются с десятками внешних сервисов, каждый из которых — потенциальная точка входа. 50% компаний никогда не удаляют устаревшие версии API из-за страха нарушить обратную совместимость.

3. Технический долг: замкнутый круг небезопасности

Технический долг безопасности возникает, когда устранение уязвимостей откладывается, а их количество растет. По данным Veracode, у 50% организаций по всему миру уже накоплен критический технический долг в ИБ. При этому среднее время исправления уязвимости выросло со 171 дня в 2020 году до 252 дней в 2025-м — увеличение на 47% всего за пять лет. За 15 лет время исправления выросло на 327%.

Все это подтверждается катастрофической статистикой: 80% организаций не устраняют уязвимости в течение 18 месяцев. В государственном секторе 60% уязвимостей в сторонних библиотеках остаются неисправленными спустя два года — вдвое больше среднего по индустрии. При этом 92% уязвимостей в библиотеках можно закрыть простым обновлением версии, причем 69% обновлений затрагивают только минорные версии и практически никогда не ломают совместимость.

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

Чтобы соответствовать новым угрозам и требованиям, 90% организаций проводят тренинги по безопасной разработке. При этом 74% все равно сталкивались с утечками данных. Это не значит, что обучение бесполезно — это означает, что одних знаний недостаточно. Без культуры безопасности, инструментов и выделенного на изучение времени знания не превратятся в устойчивую практику.

4. Небезопасные настройки по умолчанию: удобство против защиты

История повторяется. В 1988 году Unix-сервисы работали с правами root по умолчанию. Fingerd транслировал данные пользователей без какой-либо аутентификации. Это было удобно для администрирования, но фатально для безопасности.

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

• 43% банкоматов работают на Windows 7 без обновлений безопасности;
• 89% финтех-стартапов используют облачную инфраструктуру с дефолтными настройками;
• слабые пароли admin/admin остаются «фишкой» IoT-устройств и сетевого оборудования;
• 50%+ систем никогда не удаляют устаревшие API из-за страха нарушить зависимости.

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

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

Почему это происходит? Потому что дефолты почти всегда — про удобство и скорость. Включение двухфакторной аутентификации снижает число пользователей сервиса на 15–30%. Настройка Zero Trust-архитектуры требует 6–18 месяцев. Бизнес выбирает скорость запуска продукта, а не принцип security by design. Администраторы и разработчики идут по пути наименьшего сопротивления, особенно под давлением дедлайнов.

5. Экономика киберугроз: атака дешевле защиты

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

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

Отдельная категория риска — legacy-системы. Атомные станции, системы ЖКХ, аэропорты, медицинское оборудование работают на операционных системах, не обновлявшихся 20–30 лет. Эти системы нельзя обновить без остановки критических процессов. Они уязвимы к атакам девяностых по определению.

Как я уже упоминал, многие российские банки до сих пор используют системы, разработанные 30–40 лет назад. Их архитектура не предусматривала современных угроз, а обновление потребует многих лет и миллиарды рублей. Банк России неоднократно указывал на проблему устаревшей инфраструктуры, но экономика вопроса не позволяет провести быструю модернизацию.

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

В России особая уязвимость связана с централизацией платежной инфраструктуры. НСПК, СБП, платформа ЦФА — все это критически важные узлы. Успешная атака на любой из них может парализовать значительную часть финансовых операций в стране.

6. Человеческий фактор в разработке: образовательный провал

Большая часть уязвимостей появляется не из злого умысла, а вследствие привычек и пробелов в подготовке. В российских вузах кибербезопасность преподается преимущественно на специализированных факультетах информационной безопасности. А «обычные» программисты, обучающиеся на направлениях «программная инженерия» или «прикладная информатика», получают минимальные знания о безопасной разработке. Даже в ведущих технических вузах — МФТИ, МГТУ им. Баумана, СПбГУ — курсы по безопасному программированию не являются обязательными для большинства IТ-специальностей. В результате выпускники пишут код, воспроизводя небезопасные паттерны из учебных материалов.

Для сравнения, в Сингапуре Национальный университет (NUS) включил кибербезопасность в обязательную программу всех IТ-специальностей еще в 2019 году. В Южной Корее KAIST (Корейский институт передовых технологий) требует от студентов инженерных направлений прохождения базового курса по информационной безопасности. 38% вопросов о безопасности на Stack Overflow содержат упоминания технического долга — разработчики знают о проблемах, но не знают, как их решить.

Большинство программистов учатся на реальных кодовых базах, копируя как хорошие, так и плохие практики. Без формального обучения безопасности небезопасные паттерны распространяются через команды и проекты, становясь «стандартом де-факто». 80% библиотек никогда не обновляются после включения в проект — не потому, что разработчики не знают об обновлениях, а потому что обновление требует тестирования, времени и денег.

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

В России дефицит кадров в области ИБ ощущается особенно остро. По оценкам экспертов, в стране не хватает десятков тысяч специалистов по информационной безопасности. При этом зарплаты в этой сфере выросли на 30–50% за последние два года, но спрос все равно превышает предложение.

Почему ничего не меняется: системный тупик

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

1. архитектурный lock-in — в критических системах по-прежнему доминируют C/C++. Это огромные кодовые базы, писавшиеся десятилетиями, с высокой ценой ошибки и крайне дорогой миграцией;
2. организационный технический долг — значительная часть IT-бюджета уходит не на развитие, а на поддержку наследия (около 40%);
3. образовательный разрыв — безопасной разработке учат не везде и не всегда;
4. экономические стимулы — в краткосрочной перспективе цена взлома часто выглядит ниже, чем цена защиты;
5. культурные приоритеты — скорость выпуска софта почти всегда важнее его безопасности. Рынок вознаграждает тех, кто раньше запустился и быстрее итеративно улучшает продукт, а не тех, кто дольше выстраивает идеальную защиту.

Какие можно сделать выводы?

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

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

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

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

Решение — не в новых технологиях (они уже существуют), а в системном подходе:

• принять, что абсолютная защита невозможна, поэтому фокус должен быть на минимизации последствий;
• внедрять безопасность с первого дня разработки продукта;
• автоматизировать обновления и мониторинг, потому что человек не справляется с объемом угроз;
• считать киберриски как финансовые: ROI, вероятность, размер ущерба;
• инвестировать в устранение технического долга, а не в накопление «заплаток».

Цифровой мир стал опаснее не потому, что появились новые атаки, а потому что цена успешной атаки, использующей старые методы, выросла с тысяч до миллиардов долларов. Финтех 2026 года решает те же проблемы, что Unix 1988-го. Просто ставки стали несопоставимо выше.

1. Международная система выявления известных уязвимостей ПО, использующая уникальные идентификаторы (например, CVE-2024-1234) для стандартизации отчетов.