Как и почему злоумышленники атакуют разработчиков ПО

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

Почему разработчики — интересная цель для атак

Начнем с того, что компрометация рабочего устройства программиста потенциально может дать злоумышленникам непосредственный доступ к его коду, учетным данным и токенам авторизации или даже ко всей инфраструктуре разработки. Если компания производит программное обеспечение, то злоумышленники получат возможность организовать масштабную атаку на цепочку поставок для атаки на пользователей разрабатываемого приложения. Если программист работает над внутренними сервисами — его смогут использовать как плацдарм для развития атаки внутри компании.

Даже в тех случаях, когда атакующие интересуются исключительно криптовалютой (а вероятность наличия криптоактивов у технического специалиста значительно выше, чем у среднестатистического пользователя), в атаке скорее всего будет использовано вредоносное ПО, способное не только подменять номера криптокошельков, но и «пылесосить» все ценные данные — те же учетные данные и токены авторизации. Пусть они и не являются основной целью атакующих — их всегда смогут продать брокерам удаленного доступа или другим, более специализированным злоумышленникам.

Почему разработчики — удобная цель для атак

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

Варианты атак на разработчиков ПО

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

Компрометация пакетов с открытым исходным кодом

Один из самых распространенных сценариев атаки на разработчика — компрометация программного обеспечения с открытым кодом. За последний год мы видели множество примеров таких атак. Например, в марте 2026 года злоумышленники смогли внедрить вредоносный код в Python-библиотеку LiteLLM, размещенную в репозитории PyPI. Эта библиотека служит многофункциональным шлюзом для подключения разнообразных ИИ-агентов и используется во множестве проектов. Троянизированные версии LiteLLM доставляли в систему жертвы вредоносные скрипты, которые охотились за различными учетными данными. Похищенная информация затем может использоваться для доступа к системам компаний, успевших скачать зараженные пакеты.

Вредоносный код в тестовых заданиях

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

Поддельные инструменты для разработки

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

Методы социальной инженерии

Впрочем, злоумышленники могут пытаться подсунуть вредоносное ПО разработчикам и более простыми способами. При расследовании недавнего инцидента с компрометацией npm-пакета Axios выяснилось, что злоумышленникам удалось получить доступ к системе мейнтейнера при помощи банальной уловки с «устаревшим ПО». Злоумышленники вышли на мейнтейнера репозитория Axios, выдав себя за основателя известной компании. После переписки его пригласили на видеоинтервью. При попытке присоединиться к встрече якобы в Microsoft Teams разработчик увидел поддельное уведомление об устаревшем ПО и предложение установить обновление. Однако под видом «обновления» на устройство был загружен и установлен троян удаленного доступа, который и обеспечил злоумышленникам удаленный доступ.

Узкоспециализированные рассылки

Иногда в атаках на разработчиков срабатывает даже спам рассылки фальшивых уведомлений — особенно если он используются с учетом специфики аудитории. Например, совсем недавно в разделах Discussions ряда различных проектов на GitHub злоумышленники публиковали поддельные уведомления о критической уязвимости в Visual Studio Code и необходимости обновления. Подписанным на эти разделы разработчикам уведомления приходили на электронную почту и могли быть восприняты как предупреждение об угрозе. Разумеется, внутри уведомлений была ссылка на «исправленную версию» VS Code, которая в реальности содержала зловред.

Как защитить компанию?

Чтобы снизить риски компрометации, компаниям стоит придерживаться следующих практик:

• Контролируйте безопасность на уровне CI/CD-пайплайнов: сканируйте образы, зависимости и используемые компоненты при помощи специализированных решений.
• Проверяйте используемые в разработке пакеты при помощи потоков данных threat intelligence, касающихся компонентов open source.
• Обучайте основам кибербезопасности всех сотрудников, включая разработчиков. С этим могут помочь специализированные решения, например Kaspersky Automated Security Awareness Platform.
• Дополнительно предупреждайте своих разработчиков о новых схемах атак. Для этого читайте материалы в нашем блоге по тегу разработка.