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

Именно такое распределение уязвимостей изучила международная команда из Гётеборгского университета и Технологического университета Чалмерса. В статье, опубликованной 12 сентября 2026 года в рецензируемом журнале Software Quality Journal, Сриджита Басу и её коллеги проанализировали 413 опубликованных уязвимостей автомобильного программного обеспечения за период с января 2022 года по сентябрь 2024 года. Полный текст работы открыт на сайте Springer Nature.

Автомобиль как сеть связанных компонентов

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

Для формирования выборки авторы искали записи в Национальной базе уязвимостей США по 175 ключевым словам, а затем сверяли результаты с шестью другими источниками, включая каталог известных эксплуатируемых уязвимостей CISA. После удаления повторов найденные записи классифицировали по компонентам экосистемы, серьёзности и предполагаемым механизмам атаки. Отдельно пять инструментов проверили 20 открытых репозиториев, связанных с автомобильным программным обеспечением. В них исследователи обнаружили 827 уязвимых библиотек.

Крупнейшей категорией в выборке оказались внешние приложения: на них пришлось 36,2% записей. Доля систем на кристалле и встроенного программного обеспечения составила 23,5%, телематических систем, 14,8%. Авторы сопоставили эти данные с более ранним анализом уязвимостей за 2010–2019 годы и описали смещение внимания от компонентов внутри автомобиля к внешнему программному обеспечению. При этом почти трёхкратный рост доли уязвимостей приложений и облачных сервисов, о котором говорится в пресс-релизе, в доступном тексте статьи точно не подтверждён. Поэтому считать эту цифру установленной количественной оценкой нельзя.

Что означает рост внешних уязвимостей

Внешние сервисы работают через интерфейсы программирования приложений, или API, хранят и передают сведения об автомобиле и владельце, а иногда участвуют в удалённом обслуживании и обновлении программ. Поэтому здесь встречаются знакомые для веб-систем проблемы: ошибки контроля доступа, SQL-инъекции и межсайтовый скриптинг, известный как XSS. В исследованной выборке 50 уязвимостей сопоставили с SQL-инъекциями, 43, с XSS, ещё 26, с повышением привилегий.

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

Авторы также оценили серьёзность записей по системе CVSS, которая присваивает уязвимостям баллы и уровни риска. Высокий уровень получили 44,8% записей, критический, 16,3%. При сравнении с более ранней работой исследователи отмечают изменение распределения, однако периоды и процедуры сбора данных различались. Поэтому эти цифры описывают тревожный состав опубликованных сообщений, но не доказывают напрямую, что автомобили в целом стали легче взламывать.

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

Уязвимость приложения сама по себе не означает, что злоумышленник сможет управлять рулём или тормозами. Риск зависит от того, какие данные и функции доступны через этот компонент и насколько надёжно он отделён от критических систем. Значение такой изоляции показывает отдельный, более ранний пример. Во время исследовательского испытания Jeep Cherokee 2015 года специалисты получили доступ к другим системам машины через мультимедийную систему. Это не результат нового обзора и не доказательство уязвимости всех современных автомобилей.

Что может сделать владелец

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

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

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

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

Источники

  1. Srijita Basu, Miroslaw Staron, Magnus Almgren, Jennifer Horkoff, Christian Berger. Mapping the landscape of software vulnerabilities in connected vehicles. Software Quality Journal, 2026, 34:52. DOI: 10.1007/s11219-026-09787-y. Открытый полный текст и PDF.
  2. Репликационные данные авторов: перечень уязвимостей и сопоставлений за 2022–сентябрь 2024 года.
  3. Материал University of Gothenburg, опубликованный Tech Xplore: Your car’s weakest spot may not be in the car, 19 октября 2026 года. Это редакционный пересказ, а не первичная научная работа.

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

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

Фото: Puwadon Sang-ngern / Pexels