Цифровая гигиена разработчика: стараемся не попасться на удочку злоумышленника

Направление Supply Chain Security появилось в департаменте киберразведки PT ESC в 2022 г. Тогда мы проводили исследование, направленное на выявление protestware-пакетов в Python Package Index, и обнаружили вредоносы, которые прятались в репозиториях еще с 2018 г. Стало очевидно, что нынешних общемировых мер по поиску троянов в опенсорсе недостаточно, — и мы приступили к работе.

На данный момент мы сканируем в режиме реального времени все новые релизы, выходящие в:

• Python Package Index (главный репозиторий Python-кода);
• Node Package Manager (главный репозиторий JavaScript-кода);
• Visual Studio Code Marketplace (магазин расширений VSCode);
• OpenVSX (магазин расширений VSCode-совместимых редакторов кода);
• Firefox Marketplace (магазин расширений для браузера Mozilla Firefox).

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

Почему атакуют разработчиков 

Есть несколько причин, почему разработчики и их CI/CD-пайплайны привлекают злоумышленников больше, чем обычные пользователи ПК:

• Украденную у них информацию проще монетизировать. Токены от облачных провайдеров и CI/CD, API-ключи от публичных сервисов, доступные из интернета БД, мощности захваченных раннеров — это так называемые низко висящие фрукты. Похищенные данные можно попробовать перепродать, а вычислительные ресурсы — использовать для майнинга криптовалюты.
• Доступность кодовой базы и непубличной проектной документации. Код, к которому злоумышленник получает доступ, — это часть продукта компании. Такой улов дает много возможностей — от простой перепродажи интеллектуальной собственности до встраивания вредоносной логики в ПО.
• Разработчик == большая поверхность развития атаки. У других сотрудников нет доступа к внутреннему GitLab, артефакториям, раннерам, тестовым и продуктовым средам. Некоторые из этих систем могут смотреть наружу, что дает неплохие возможности для закрепления и развития атаки.

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

• установка и запуск стороннего кода;
• эксперименты с новыми библиотеками и инструментами;
• копирование примеров кода из документации, блогов, Q&A-платформ (StackOverflow и др.), ответов LLM;
• работа с непроверенными и малопопулярными пакетами.

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

Наконец, отдельно остановлюсь на роли CI/CD-пайплайнов в современных атаках на разработчиков и цепочки поставок. Они создавались для автоматизации и ускорения доставки кода, но именно эти свойства и делают их особенно привлекательными для злоумышленников. В отличие от локальной рабочей станции, CI/CD:

• автоматически выполняет код без участия человека;
• автоматически подставляет секреты и токены;
• запускается регулярно и масштабируется на множество окружений;
• имеет доступ к артефактам, репозиториям и инфраструктуре.

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

Портрет злоумышленника

В контексте атак на цепочки поставок действующее лицо — не обязательно большая организованная группировка или даже высококвалифицированный хакер-одиночка. Зачастую это просто прагматичный злоумышленник, который осознал, что Open Source и CI/CD — удобный и масштабируемый путь к результату. 

Выделим основные типы атакующих:

• Одиночки-энтузиасты. Интересующиеся люди, которые уже обросли определенными навыками или только пробуют себя на новом поприще.
• Организованные сообщества. Распределяют задачи между участниками: наполнение пакета, публикация, поддержание инфраструктуры, сбыт результатов труда, автоматизация процессов. Как правило, они понимают, чем занимаются и как будут извлекать выгоду.
• Продвинутые государственные группировки. Встречаются нечасто и, как правило, преследуют цели, связанные с кибершпионажем. Яркий пример — северокорейцы Lazarus. Sonatype отмечает, что группировка использует майнеры и стилеры в отношении пользователей Open Source. Для них майнинг — вспомогательный источник финансирования.

Мы не стоим со свечкой за спинами хакеров в момент злодеяния, поэтому наше понимание о типах атакующих строится на качественных, количественных и временны́х признаках, присущих определенным кампаниям:

• Использование готовых инструментов. Существуют публичные фреймворки, которые злоумышленники используют как есть или вносят в них минимальные корректировки.
• Обратное явление: использование самописных инструментов. Речь не только о наполнении самого пакета и закладываемой в него вредоносной логике, но и к применяемым мерам сокрытия последней — обфускации.
• Метаданные. Злоумышленник может упустить из виду, что хоть его вредоносные пакеты и опубликованы с новых учетных записей, но все имейлы принадлежат одному домену, а их адреса состоят из 16 случайных символов английского алфавита. Такие корреляции могут быть полезны для идентификации атакующего.
• Инфраструктура. Как и в случае с имейл-паттернами, если злоумышленник использует один и тот же хостинг, криптокошелек или сервис, это упрощает обобщение отдельных пакетов в одну кампанию.
• Повторное использование кода. В случае с Open Source злоумышленники склонны шаблонизировать атаки.

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

Цели злоумышленника

1. Кража данных

Прежде всего речь идет о следующей информации:

• токены облачных провайдеров;
• API-ключи для различных сервисов;
• данные БД;
• приватный код и внутренняя документация.

Полученные данные можно перепродать или использовать самостоятельно для нанесения более серьезного ущерба жертве.

2. Майнинг

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

3. Шифрование и вымогательство

Классические ransomware-атаки встречаются в Open Source реже, чем инфостилеры и майнеры, но это не делает их менее опасными. Phylum писала о кампании в PyPI и NPM, в рамках которой пакеты скачивают шифровальщик, реализованный на Golang. Злоумышленник требует за расшифровку файлов 100 долл. в криптовалюте.

4. Удаленный доступ и разведка

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

Удаленный доступ можно использовать для последующей разведки или перепродажи. По сути, жертва может стать плацдармом для развития атаки на цепочку поставок. К примеру, мы рассказывали о пакетах catbannersxd и catbannerslol, которые скачивают и запускают исполняемый файл — продвинутый RAT PySilon, написанный на Python. Он обладает широким функционалом — от кражи учетных записей Discord и выполнения произвольных команд на устройстве до вызова «синего экрана смерти» (BSoD) и запуска форк-бомбы. 

В той же статье мы освещали пакет pyconfuserm, который скачивает и устанавливает RAT Xworm. Он позволяет скрытно наблюдать за действиями жертвы, дает полный контроль над периферией зараженного устройства (в том числе направляет злоумышленнику данные с веб-камеры, микрофона, рабочего стола) и возможность управлять файловой системой. Также XWorm позволяет добавлять устройства жертв в ботнет для осуществления DDoS-атак.

5. Целевые атаки

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

Snyk писала про JavaScript-пакет node-ipc, вредоносное обновление для которого вышло в марте 2022 г. Пакет проверял по данным GeoIP, что пользователь находится на территории России и Беларуси, а затем заменял все файлы на устройстве эмодзи сердца.

Phylum рассказывала про кампанию, которая щадит устройства, работающие не на MacOS. Исследователи обнаружили, что злоумышленники целились в конкретное устройство и знали его UUID. То есть атака была нацелена на определенного разработчика либо пакет предназначался для запуска на тестовой инфраструктуре (без ущерба для остальных пользователей). 

Точки входа 

Переходим к следующему вопросу: как злоумышленники попадают в инфраструктуру жертвы? Как правило, речь идет далеко не о поиске 0-day-уязвимостей и других сложных векторах. В подавляющем большинстве случаев это злоупотребление доверительными отношениями в Open Source, автоматизацией CI/CD и типичными рабочими практиками разработчиков (в том числе не совсем корректными с точки зрения ИБ). 

Точки входа можно условно разделить на три группы: атаки на разработчика, на CI/CD и на проекты-зависимости.

Атаки на разработчика

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

1. Мимикрия под «полезные» инструменты

В статье на «Хабре» мы приводили пример с разработчиком wizardforcel. Он генерировал несколько десятков пакетов в час и сумел создать более 13 тыс. пакетов с довольно интересными названиями: cdndrive, kubernetes-handbook, epubcrawler, doc-template, deep-learning-bengio и др. Невнимательный разработчик вполне может установить такую ловушку.

2. Тайпсквоттинг (Typosquatting)

Один из самых простых и при этом массовых способов атаки. Злоумышленники регистрируют вредоносные пакеты, названия которых немного отличаются от легитимных, в надежде на то, что разработчик опечатается и скачает вредонос. В качестве примера возьмем кампанию OrangeAlice, в рамках которой хакеры зарегистрировали свыше десятка пакетов, мимикрирующих под популярную библиотеку requests (см. рис. 3).

Кодовая база проектов также была скопирована из requests, но с добавлением дополнительной логики, скрывающей инфостилер (см. рис. 4).

Мы также писали про библиотеку aiihttp (вышла в январе 2026 г.), вредоносная активность которой нацелена на майнинг криптовалюты. Но об этой библиотеке можно сказать и кое-что хорошее: она установит вам легитимный aiohttp :) 

3. Атаки через Stack Overflow и публичные ответы

Stack Overflow и аналогичные Q&A-площадки оказались достаточно эффективным каналом доставки вредоносного кода. Причина проста: разработчики ходят туда за быстрым решением проблем. Если ответ выглядит убедительно, человек может скопировать весь сниппет без дополнительной проверки.

В 2024 г. Sonatype описали кампанию с вредоносным PyPI-пакетом pytoileur. Чтобы увеличить охват атаки, злоумышленник начал «рекламировать» свой вредоносный пакет-инфостилер в комментариях на Stack Overflow (см. рис. 5.1 и 5.2).

4. Slopsquatting: регистрация выдуманных LLM-пакетов

Эта атака чем-то напоминает Typosquatting. LLM иногда придумывают названия пакетов, которые в действительности не существуют или относятся к внутренним инструментам компании — создателя модели. Если злоумышленники зарегистрируют вредоносную библиотеку с таким названием, разработчик может, не проверяя, установить ее по рекомендации LLM. Так, исследователь из Lasso Security в марте 2024 г. описал в блоге, как создал пакет-заглушку huggingface-cli, название которой «сгаллюционировал» ChatGPT. За три месяца наблюдений пакет скачали более 30 тыс. раз.

Атаки на CI/CD

Некоторые атаки, направленные на разработчиков, могут быть реализованы не только на их устройствах, но и в пайплайне (например, тот же тайпсквоттинг). Кроме того, существуют специфичные для CI/CD векторы, связанные с компрометацией или созданием вредоносных раннеров. Приведу пару примеров:

Март 2025 г.: атака Supply Chain через скомпрометированный GitHub Action tj-actions/changed-files 

Крупный GitHub Action, который используется более чем в 23 000 репозиториев, был скомпрометирован злоумышленниками, что привело к утечке CI/CD-секретов через workflow-логи. Атаке был присвоен идентификатор CVE-2025-30066 (CVSS score: 8.6).

Сентябрь 2025 г.: атака Supply Chain через изначально вредоносные GitHub Actions 

Хакеры скомпрометировали множество GitHub-аккаунтов и внедрили в их CI/CD-воркфлоу вредоносные Actions, которые собирали API-токены и ключи из CI/CD-сред и отправляли их на сервер злоумышленников. Атака использовала 327 скомпрометированных аккаунтов разработчиков, затронула 817 репозиториев, в которые были внедрены вредоносные воркфлоу. Было украдено 3325 секретов, включая токены PyPI и NPM (в том числе позволяют выпускать новые версии от имени автора пакета), учетные данные DockerHub, GitHub-токены, API-ключи CloudFlare и AWS-ключи.

Атаки на проекты-зависимости

Современные проекты почти никогда не существуют изолированно: они опираются на десятки или даже сотни сторонних библиотек. Это делает зависимости одним из самых удобных и масштабируемых векторов атаки. К тому же безопасности популярных библиотек обычно уделяется пристальное внимание. Атаковать их разработчиков или CI/CD куда сложнее, чем обратить внимание на транзитивную зависимость, которая не так серьезно модерируется…

1. Атака на мейнтейнера

Разработчика могут зафишить 

В июле 2025 г. в результате фишинговой атаки злоумышленники получили доступ к учетной записи JounQin, автора пакетов eslint-config-prettier (на тот момент — 30 млн скачиваний за неделю), eslint-plugin-prettier, snyckit, @pkgr/core, napi-postinstall.

Злоумышленники добавили в пакеты JounQin дополнительную логику, которая запускала вредоносную библиотеку для Windows-систем — инфостилер, крадущий информацию из Chromium-based браузеров.

Другой пример: в сентябре 2025 г. хакеры провели целевую фишинговую атаку, в рамках которой имитировали официальное письмо от службы поддержки NPM (см. рис. 8). Им удалось протроянить Josh Junon, автора 18 npm-пакетов, среди которых chalk (313 млн скачиваний в NPM за неделю), debug (372 млн скачиваний), strip-ansi (272 млн скачиваний), wrap-ansi (206 млн скачиваний) и has-flag (200 млн скачиваний). 

Вредоносная логика, добавленная в пакеты, хукалась на события отправки сетевых запросов. При упоминании криптокошельков (Bitcoin, Ethereum, Solana, Tron, Litecoin или Bitcoin Cash) на место адреса получателя криптовалюты подставлялся адрес кошелька злоумышленника.

Разработчик может перестать поддерживать проект

NPM-библиотека event-stream была создана в 2011 г. В 2018-м пользователи обнаружили, что в версии 3.3.6 появилась новая зависимость flatmap-stream, которая содержала обфусцированный код, нацеленный на кражу ключей Bitcoin-кошельков. Как оказалось, автору перестало хватать времени на поддержку проекта, и он передал права человеку, который, по его словам, был готов продолжить работу над библиотекой. Им оказался злоумышленник…

Разработчика могут загазлайтить

Создатель популярной библиотеки xz-utils (реализует алгоритмы сжатия, используется во многих дистрибутивах Linux) стал жертвой длительной атаки. Хакеры убедили разработчика сделать их доверенными участниками проекта и встроили вредоносный код в релиз.

Атакующие действовали сразу с двух сторон. Злоумышленник под псевдонимом Jia Tan проявлял активность на GitHub, предложил много небольших правок и активно взаимодействовал с автором библиотеки. С октября 2021 г. он наращивал присутствие в проекте и в итоге добился статуса сомейнтейнера.

С другой стороны, сторонние аккаунты, контролировавшиеся злоумышленниками, начали засыпать проект жалобами и запросами на расширение функциональности. Таким образом атакующие давили на автора библиотеки, чтобы он добавил в репозиторий нового разработчика. Выбор пал на Jia Tan… В итоге в марте 2024 г. злоумышленник добавил в проект вредоносную функциональность, которая активировалась в рамках функции OpenSSH RSA_public_decrypt. Новая логика извлекала команду, содержащуюся в сертификате пользователя, и исполняла ее, реализуя функционал бэкдора.

2. Троянистые pull request’ы

В марте 2024 г. была выявлена кампания, в рамках которой злоумышленники скомпрометировали один из репозиториев организации Top.gg — агрегатора Discord-ботов с огромной аудиторией. Они сделали коммит, затрагивающий 52 файла, включая файл, описывающий зависимости. Хакеры подменили ссылку на пакет colorama и заменили адрес легитимного домена на вредоносный (см. рис. 9).

В итоге пользователи устанавливали инфостилер, крадущий браузерные куки, формы автозаполнения, историю, закладки, банковские карты, учетные записи, токены Discord и Instagram, пользовательский ввод с клавиатуры и многое другое.

3. Продажа проектов

В июне 2020 г. автор Chrome-расширения The Great Suspender, нацеленного на экономию памяти браузера, продал его — как оказалось, злоумышленникам. Новые владельцы выпустили обновления 7.1.8 и 7.1.9, в которые добавили функционал скрытого трекинга пользователей и выполнения удаленного кода.

А домен cdn[.]polyfill[.]io, через который шло распространение JavaScript-библиотеки polyfill.js (предоставляет старым браузерам поддержку функционала, который появился в новых версиях) попал во владение злоумышленникам в феврале 2024 г. Хакеры внедрили в релиз вредонос, который перенаправлял пользователей на мошеннические сайты.

Как злоумышленники усложняют обнаружение

Вредоносный код вряд ли сможет долго продержаться в открытом проекте. Помимо пользователей, которые могут обнаружить активность злоумышленников, существуют дополнительные уровни контроля. Например, премодерация со стороны репозиториев (на VSCode Marketplace или Anaconda) или сканеры для проверки пакетов, курируемые ИБ-вендорами.

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

1. Разбиение на стейджи

Распространенный подход — разделение атаки на несколько стадий. Например, когда сам вредоносный пакет играет роль загрузчика, который содержит только логику скачивания/запуска и не отражает конечной цели злоумышленника. Скачиваемый стейдж может быть представлен в виде исполняемого бинарного файла или скрипта (JavaScript, Python, PowerShell и др.). В ряде сценариев, если скачиваемый стейдж зашифрован, загрузчик также выполняет расшифровку.

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

2. Использование обфускации

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

Но если речь идет о репозиториях исходного кода (PyPI, NPM и др.), наличие обфускации, как правило, дает повод насторожиться. Зачем разработчик усложняет анализ своего кода? К примеру, на Python Package Index обфускация относится к потенциальным признакам вредоносности и является обоснованием для отправки жалобы на пакет.

В качестве примера приведу обфусцированный код библиотеки procleaner, который скрывает за собой реверс-шелл (см. рис. 10). 

3. Обход песочниц

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

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

• имя пользователя не равно «root»;
• имя компьютера не начинается с «ip-172-»;
• в имени пользователя и компьютера не фигурирует «snyk»;
• имя компьютера не попадает под маску «^DESKTOP-[A-Z0-9]{4,10}$” или “[a-f0-9]{11,13}».

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

Как защититься

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

Важно понимать, что тотального контроля над безопасностью кода вы все равно не получите: слишком большая площадь атаки, затрагивающая не только зависимости используемых нами пакетов, но и приложений, а также ОС (как в примере с xz-tools, который затрагивает OpenSSH). Тем не менее можно достичь системного снижения рисков.

Технические меры

1. Карантин

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

Адекватная практика — не позволять пакетному менеджеру скачивать пакеты младше 14 дней. Параноики могут увеличить срок до двух месяцев (этого должно хватить для прохождения полного цикла вредоносного релиза) :) 

2. Внутренние зеркала и модерируемые репозитории

Внутренние зеркала (proxy-репозитории) позволяют:

• контролировать список доступных пакетов;
• фиксировать версии;
• централизованно блокировать вредоносные релизы;
• анализировать скачиваемые зависимости.

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

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

3. Фиды 

Фиды — это регулярно обновляемые списки вредоносных, скомпрометированных и уязвимых пакетов. Их формируют сами экосистемы (например, advisory-базы PyPI и Debian), ИБ-вендоры, исследователи и сообщество Open Source. Если карантин снижает риск стать жертвой новой кампании, то фиды позволяют реагировать на инциденты, уже выявленные другими аналитиками.

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

4. Изоляция окружения

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

• использование контейнеров и виртуальных машин для экспериментов;
• запуск подозрительных инструментов в изолированной среде;
• разделение рабочих и личных окружений;
• отказ от запуска сборок с повышенными привилегиями без особой необходимости.

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

5. Управление доступами и секретами

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

• минимальные привилегии (least privilege);
• раздельные токены для разных сред;
• ограничение прав CI/CD-раннеров;
• использование короткоживущих токенов;
• регулярная ротация ключей.

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

Организационные меры

Технические средства важны, но нельзя забывать и о культуре разработки в целом.

1. Осознанность и внимательность

Разработчик — первый и часто единственный фильтр перед запуском стороннего кода. Практики, которые снижают риски:

• внимательное отношение к новым зависимостям;
• проверка популярности и истории проекта;
• настороженность к обфускации в исходниках;
• осторожность при копировании кода из блогов, форумов и ответов LLM.

Речь не о паранойе, а о привычке задавать простой вопрос: «Почему этот код выглядит именно так? Нет ли здесь злого умысла?»

2. Знание портрета злоумышленника

Нужно иметь базовое представление о том, как устроены атаки:

• какие паттерны присущи различным видам ВПО;
• как проявлялись известные вредоносные кампании;
• как выглядит обфускация и как ее «разбирать».

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

3. Security-by-default в разработке

Современная разработка требует перехода от «Сначала заработает — потом защитим» к модели «Работает безопасно по умолчанию».

Базовые принципы:

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

Безопасность цепочки поставок должна быть частью архитектуры процессов.

***

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

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