Slopsquatting: ИИ в тандеме со злоумышленником

Интересно смотреть, как ИИ меняет разные сферы - и кибербезу тоже досталось. Недавно наткнулся на термин slopsquatting и удивился: он живёт уже больше года, просто прошёл мимо меня - придумал его в 2025 Сет Ларсон из Python Software Foundation. Разбираемся, что это и почему это не страшилка ради красивых заголовков.

Начнём издалека - с более старого трюка, typosquatting (опечатка + захват). Атакующий регистрирует в PyPI, npm или другом репозитории пакет с именем, почти неотличимым от популярного - на одну букву, на дефис, на порядок слов. Классика: в декабре 2019 в PyPI нашли jeIlyfish - настоящий jellyfish, только строчная l заменена на заглавную I, визуально похожую в большинстве шрифтов. Пакет воровал SSH- и GPG-ключи. Рядом ехал python3-dateutil под python-dateutil; в npm похожая история - crossenv вместо cross-env (2017).

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

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

Slopsquatting - тот же трюк с апгрейдом под эпоху AI-кодинга. Когда LLM пишет вам код, она время от времени советует import библиотеки или pip install, которой на самом деле не существует - модель её выдумала, потому что название звучит правдоподобно.

Раньше на это смотрели как на безобидный баг: заметишь, попросишь исправить, и всё. Но в 2025-м исследователи UTSA опубликовали работу на USENIX Security: 16 моделей, 576 тыс. сэмплов на Python и JS. Результат - 19,7% рекомендованных пакетов не существовало.

Результаты правда относятся к моделям предыдущего поколения, актуальных метрик пока нет. Но нам интересно другое: 500 галлюцинирующих промптов прогнали по десять раз каждый. 43% выдуманных имён повторялись во всех десяти прогонах, ещё 58% - больше одного раза. Список фейковых имён воспроизводимый, а не случайный.

А воспроизводимость - подарок для атакующего. Не нужно брутфорсить: достаточно позадавать модели типичные вопросы вроде «напиши скрипт парсинга CSV», собрать частые несуществующие названия и зарегистрировать их с вредоносной начинкой. Дальше сценарий тот же: разработчик видит незнакомую библиотеку, не всегда успевает загуглить - и ставит то, что подсунула модель.

Это не теория. В 2024-м Бар Ланьядо из Lasso Security зарегистрировал пакет-пустышку huggingface-cli, который модели упорно советовали. За три месяца - больше 15 тысяч загрузок, а pip install huggingface-cli заехал в README репозитория Alibaba GraphTranslator. Никакого взлома - люди просто ставили то, что продиктовал ИИ.

Второй случай свежее и неприятнее: в январе 2026-го Чарли Эриксен (Aikido Security) заметил, что LLM склеила jscodeshift и react-codemod в несуществующий react-codeshift. Имя попало в коммит с 47 сгенерированными Agent Skills и через форки разошлось по 237 репозиториям - никто не вычитывал. Эриксен зарегистрировал пакет превентивно и сразу увидел загрузки. По его словам, вектором атаки это не стало только потому, что он успел первым.

Почему это стало проблемой именно сейчас:

• AI-агенты стали привычным способом писать рутинный код, и вопрос «а точно ли существует эта библиотека?» многие перестали задавать в принципе;

• галлюцинации разных моделей пересекаются - есть 127 имён пакетов (109 в PyPI, 18 в npm), которые независимо выдумывают сразу несколько ведущих моделей. Один зарегистрированный пакет ловит пользователей всех сразу;

• репозитории пакетов по-прежнему пускают регистрировать что угодно и от кого угодно, никак не проверяя, зачем вам это имя.

Короче: slopsquatting - история про то, как одна безобидная особенность модели превращается в готовый вектор атаки. Старый как мир supply-chain риск получил новый, куда более дешёвый вход.

Пользуясь случаем, пришлашаю в мой Telegram-канал.

А вы еще помните, как было?

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

Первая ссылка ведёт на StackOverflow. Вопрос 2014 года. Принятый ответ заминусован, а рабочий лежит третьим снизу. Сорок голосов, комментарий «this saved my life».Ты его даже не копируешь, потому что случай всё равно другой. Но ты уже понял, в чём было дело.

Иногда уходишь на старый форум, на 23 страницу давно заброшенной темы. Последнее сообщение датировано 2015 годом. Аватарки битые, половина ссылок ведёт в никуда. И вдруг там, между «спасибо, помогло» и «у меня то же самое», сидит человек, который разобрал твою проблему по косточкам. Для себя. Не зная, что однажды его ответ спасёт кого-то ещё.

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

Жмёшь «отправить». Ждёшь. Обновляешь вкладку. И вот он, ответ от незнакомца, которому просто не всё равно.

Сейчас ты выделяешь трейсбек, не дочитав до конца, и пишешь: «почини».

И он чинит.

Работает. Тесты зелёные. Можно идти дальше.

Но где-то в этот момент из профессии исчезает важная часть ритуала. Та самая, где ты не просто получал ответ, а прожёвывал проблему. Злился, тупил, копался в чужих обсуждениях и постепенно начинал понимать, что вообще происходит.

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

И в этом есть что-то страшное.

Профессия программиста всегда держалась именно на привычке разбираться. На внутреннем упрямстве: «я хочу понять, почему оно сломалось».

А теперь у нас появился идеальный способ этого не делать.Да, мы стали быстрее. Да, мы стали продуктивнее. Да, назад никто не пойдёт.

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

Вот это и пугает.

Не то, что ИИ заберёт работу.

А то, что он оставит нам работу, но постепенно заберёт профессию.

Давайте вместе смотреть на то, как меняется разработка, заглядывайте в мой Telegram-канал.

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

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

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.

Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.

Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.

Почему это важно именно сейчас?

Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.

Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.

Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.

Но есть нюансы. А где их нет, правда?

Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.

Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.

Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.

Перемены — впереди!

И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.

Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».

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

Ждём, когда мутанты станут умнее.

Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем.

Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ChatGPT объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие!

По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом.

Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками.

Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с ChatGPT точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее.

На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера".

Что думаете?

Сейчас в очередной раз увидел новость от Антропика, что разработчики доживают свой последний год. И снова эти "эксперты" путают карту с местностью. Но у нас же с вами есть голова на плечах? Так что давайте сами и подумаем.

Типичный менеджер/аналитик - человек очень далёкий от кода и архитектуры. Да, двигает задачки, общается с бизнесом, делает красивые таблички, НО В КОДЕ НИЧЕРТА НЕ ПОНИМАЕТ. И не поймёт, даже если попросит ChatGPT объяснить. Почему? Да потому что даже если человек знает синтаксис - у него нет самого главного. Нужное мышление нарабатывается годами. Разработка это вообще не про "писать код", вот так открытие!

По какой-то необъяснимой для меня причине каждый раз упускается из вида самое главное. Рабочее приложение != "кнопочки жмутся, всё работает". Это верхушка айсберга, которую видно. Всё на самом деле сильно-сильно глубже. Все эти красивые сервисы, где ты натыкал в графе приложение и оно задеплоилось не применимы ни для одной серьезной компании. Это хорошо работает для стартапа или MVP, у которого трафик 1,5 колеки. И естественно, у человека "не из разработки" нет даже примерного понимания того, как это устроено изнутри. Чёрный ящик. Он не объяснит, почему выбрал тот или иной подход. Не заметит, что он был ошибочным. И это на проектах, в которых дай бог 2-3 сервиса, БД и nginx. Может ли такой человек довести проект до зрелого, стабильного состояния, который сможет развиваться годами? Сомневаюсь. Даже если допустить, что какой-нибудь Claude 5.7 будет в 10 раз умнее нынешнего - проблема не в этом.

Хороший инженер с хорошим инструментом может написать в 10 раз больше хорошего кода. Плохой инженер - напишет в 10 раз больше плохого кода. Пока что я не видел ни одного кейса, который мог бы опровергнуть это утверждение. Ты должен понимать, как работает твоё приложение и почему оно так работает. Это еще один скилл, который каждый разработчик приобретает годами. Это та самая "карта проекта" в голове, которая помогает тебе быстро и эффективно решать задачи. И это понимание спасает от многих проблем и ошибок, которые с ростом проекта становится нереально дорого исправлять. Даже с нейронками.

Еще свежи в памяти падения Cloudflare, AWS и десятка других сервисов. Почему? Потому что инженеры дали слишком много прав агенту, либо невнимательно проверили сгенерированный конфиг или код. НАСТОЯЩИЕ ИНЖЕНЕРЫ, КОТОРЫЕ ПОНИМАЛИ, ЧТО ДЕЛАЮТ. Лицо менеджера-вайбкодера, когда у него упал целый датацентр представили?) Сможет ли медсестра поставить диагноз с ChatGPT точнее, чем опытный врач, который использует тот же инструмент? Нет. Получается, что сам "инструмент" - не решающий фактор. Почему все сравнивают "вот я с гпт такооое могу, увольняйте всех бэкендеров"? И что, я с тем же ГПТ могу больше и быстрее.

На самом деле именно разработчики выигрывают больше всех с развитием ИИ. Сделать нормальное приложение сложнее, чем оформить табличку в аналитике. И уж явно сложнее 99% задач, которые выполняют менеджеры. Думаю Клод с этим справится на ура. Всё потихоньку движется к концепции software-инженера, который сам отвечает за аналитику, сроки выполнения и разработку. Ну и конечно же акцент больше сместится на проектирование архитектуры. Мы просто будем тратить меньше времени на код. И этот подход будет в десятки раз эффективнее любого "менеджера-аналитика-вайбкодера".

Что думаете?

Clawdbot: когда обезьяне дали гранату 🤡

Совсем недавно Clawdbot хайпанул. И тут такое началось... Это не цирк, это хуже.
Добрый дядя из гайда советует прокинуть туннель через ngrok или развернуть это дело на VPS с открытым портом.

Итог: любой школьник находит ваш IP или ngrok-адрес и получает RCE (удаленное выполнение команд) от вашего имени.

Судя по последним новостям агенты и сами не против опубликовать куда нибудь ваши тонны. Так, между делом.

Какой-то цифровой эксгибиционизм. Отберите у них Докер, пока не поздно.