7 сентября Equifax – одно из трёх крупнейших бюро кредитных историй США – раскрыла утечку данных 143 миллионов человек: имена, даты рождения, номера социального страхования, адреса, в части случаев номера водительских прав и кредитных карт. Это не точечный взлом VIP-аккаунта и не фишинг сотрудника. Это компрометация публичного веб-приложения через уязвимость в стороннем компоненте. И именно поэтому случай Equifax – урок не столько про конкретную компанию, сколько про дисциплину работы с зависимостями.

Уязвимость была известна и закрыта заранее

По текущим данным расследования, точкой входа стала уязвимость в Apache Struts – популярном Java-фреймворке для веб-приложений. Речь, по всей видимости, о CVE-2017-5638: ошибка в парсере многокомпонентных запросов позволяет выполнить произвольный код на сервере через подделанный заголовок Content-Type. Никакой аутентификации не требуется – достаточно отправить HTTP-запрос.

Ключевой факт: патч и бюллетень Apache вышли в марте 2017 года. У организации были месяцы на обновление. Атака же, по сообщениям самой Equifax, началась в середине мая. То есть проблема не в неизвестной «уязвимости нулевого дня», а в том, что известная и публично исправленная дыра осталась открытой в боевой системе с персональными данными десятков миллионов людей.

Это типичная картина. Современное приложение на 80–90% состоит из чужого кода: фреймворки, библиотеки логирования, парсеры, ORM, криптомодули. Каждая такая зависимость – часть вашей поверхности атаки, даже если вы не написали ни строки её кода. Безопасность собственной бизнес-логики не спасает, если уязвим фреймворк под ней.

Обновление зависимостей – это процесс, а не разовая акция

Главная ошибка – относиться к обновлениям как к необязательному техническому долгу, который можно отложить «до следующего релиза». Между публикацией CVE и началом массового сканирования сети на эту уязвимость проходят часы, в худшем случае дни. Окно реагирования короткое, и закрывать его авралом не выйдет – нужен налаженный процесс.

Что мы выстраиваем в проектах:

  • Инвентаризация зависимостей. Вы не защитите то, о чём не знаете. Список компонентов и их версий (SBOM) должен формироваться автоматически на этапе сборки.
  • Сканирование на известные уязвимости. Проверка зависимостей по базам CVE встроена в CI/CD, сборка с критичной уязвимостью не уходит в прод.
  • Регулярный цикл обновлений. Патчи безопасности накатываются по расписанию, а критичные – вне очереди, по отдельному ускоренному регламенту.
  • Возможность быстро выкатить фикс. Если развёртывание занимает недели, любой патч теряет смысл. Здесь помогает зрелая инфраструктура – об оркестрации контейнеров мы писали в материале про Kubernetes в продакшене.

Отдельно отмечу: критичность системы определяется не нагрузкой, а данными внутри неё. Реестр с персональными данными граждан или с юридически значимым ЭДО и электронной подписью требует более жёсткого регламента патчинга, чем витрина каталога.

Что это значит для российского бизнеса и госсектора

Для систем, обрабатывающих персональные данные, требования 152-ФЗ и приказов ФСТЭК прямо предполагают управление уязвимостями и своевременное устранение недостатков защиты. Устаревшая библиотека с публичным CVE – это не абстрактный риск, а конкретное несоответствие требованиям, которое всплывёт при проверке или, что хуже, при инциденте.

Устойчивость системы складывается из мелочей: резервирования, отказоустойчивости (мы разбирали это на примере масштабного сбоя AWS S3) и дисциплины обновлений. Equifax напоминает, что слабым звеном оказывается самое незаметное – версия фреймворка в pom.xml.

Вывод

Утечка Equifax – это не история про изощрённую хакерскую группу. Это история про незакрытый за полгода патч. Управление зависимостями нужно встроить в разработку и эксплуатацию как постоянный процесс, а не вспоминать о нём после инцидента: выстроить регулярный цикл патчинга и провести аудит уязвимостей в боевых системах проще до того, как известная дыра обернётся утечкой.