Дайджест технічних новин: захист LLM від prompt injection, шкідливий пакет у PyPI та нові можливості ESLint
- Таїсія Красноштан
- 2 трав.
- Читати 6 хв
У травневому технологічному дайджесті — актуальне та корисне зі світу розробки від Максима Березанського, Tech Lead в Keiki з екосистеми Genesis.
Цього разу: як у DeepMind захищають LLM від ін’єкцій підказок без допомоги додаткових моделей; як команда JFrog викрила шкідливий Python-пакет у PyPI та як ESLint дозволяє поступово впроваджувати нові правила лінтингу, приглушивши наявні помилки у спеціальному JSON-файлі.
Атаки через ін’єкцію підказок (prompt injection) стають однією з ключових загроз для великих мовних моделей. У відповідь на це дослідники Google DeepMind запропонували CaMeL — захисний шар, який аналізує управління даними всередині LLM-запитів і блокує потенційно шкідливі інструкції.
Як це працює
Prompt injection дозволяє зловмисникам впроваджувати команди, які LLM сприймає як частину завдання. Це може призвести до розкриття приватних даних, небезпечних дій або зловживання доступом до зовнішніх інструментів (наприклад, надсилання листів чи оформлення замовлень).
CaMeL не використовує іншу модель штучного інтелекту для фільтрації запитів. Натомість він спирається на класичні принципи безпеки, як-от контроль доступу, відстеження джерел даних та контроль потоків інформації. Кожному значенню в системі присвоюються метадані — «можливості», що визначають, що саме з цими даними можна робити відповідно до політик безпеки.
Для реалізації цього підходу CaMeL використовує спеціальний інтерпретатор Python, який відстежує походження даних та інструкцій, забезпечуючи безпеку на основі можливостей без необхідності модифікації самої LLM. Цей підхід розширює концепцію Dual LLM, яка передбачає використання привілейованої LLM для обробки запитів користувача та ізольованої LLM для взаємодії з недовіреними даними.
Чим CaMeL відрізняється
Навіть у цій схемі існує ризик, що зловмисник може змусити ізольовану LLM генерувати неправдиві або шкідливі відповіді. Щоб вирішити цю проблему, у новому підході привілейована LLM генерує програму на обмеженій версії Python, яка виконує всі необхідні дії.
Під час отримання даних від ізольованої LLM або інших інструментів ця програма створює граф потоків даних, відстежуючи походження кожного елемента, права доступу та відповідні метадані. Ці метадані використовуються для забезпечення того, щоб будь-яка операція з даними відповідала встановленим обмеженням.
Для перевірки ефективності CaMeL дослідники DeepMind інтегрували його в AgentDojo — бенчмарк безпеки, що включає набір реалістичних завдань для автономних агентів. CaMeL не є ідеальним рішенням для безпеки LLM, як визнають самі дослідники DeepMind, зокрема через необхідність визначення політик безпеки користувачами.
Крім того, оскільки CaMeL може вимагати ручного затвердження завдань, пов'язаних з конфіденційністю, існує ризик втоми користувачів, що може призвести до автоматичних і необережних затверджень.
У квітні 2025 команда безпеки JFrog виявила чергову атаку на ланцюг постачання: у PyPI з’явився шкідливий Python-пакет, який маскується під популярну бібліотеку для криптотрейдингу. Його мета — викрадення API-ключів і seed-фраз користувачів біржі MEXC.
Як працює фейковий пакет
Зловмисники виклали підозрілий пакет під назвою ccxd python m-exe – futures. За назвою він схожий на легітимну бібліотеку ccxt, яку активно використовують трейдери, ботобудівники й розробники, що інтегрують криптобіржі через API. Справжня ccxt — це інструмент для роботи з понад сотнею криптобірж, включно з MEXC, Binance, OKX та іншими.
Але у випадку з ccxd, всередині — зовсім інша історія: під виглядом знайомого інтерфейсу приховано крадіжку приватних ключів, логінів і seed-фраз.
Typosquatting у дії
Класична схема: зловмисники грають на неуважності. Вони публікують фейкові пакети зі схожими назвами — змінюють одну літеру, додають дивні суфікси, — і розраховують, що хтось не помітить різниці. У цьому випадку замість ccxt — ccxd, ще й із додатками типу m-exe.
Після встановлення пакет поводиться як справжній: виконує запити до API, повертає очікувані відповіді. Але в тіні — краде облікові дані та надсилає їх на сторонній сервер.
Кого це стосується
Ці атаки особливо небезпечні для розробників, які пишуть кастомні скрипти для торгівлі або створюють автоматизованих трейдинг-ботів. Такі скрипти часто запускаються без ручного втручання — отже, будь-який шкідливий код працюватиме без очевидних ознак зламу.
JFrog виділяє кілька червоних прапорців:
пакет має підозрілу або "схожу, але не ту саму" назву;
в історії — жодних оновлень чи активності;
кількість завантажень мінімальна, але пакет потрапляє в CI/CD або інструменти автоматизації.
Масштаб атаки — не лише Python
За словами Браяна Муссаллі, керівника напряму безпеки ланцюга постачання в JFrog, подібні пакети виявлено не лише в PyPI, а й у npm, NuGet, GitHub. Це свідчить про скоординовану атаку одразу на кілька екосистем.
Ціль зловмисників — не зламати шифрування біржі, а обійти захист через людський фактор. Їхня мета — інтегрувати шкідливий код у бекенд, гаманець або CI/CD-процеси, щоб отримати доступ до приватної інформації без явних ознак злому.
JFrog також повідомляє про випадки, коли подібні пакети змінювали поведінку популярних гаманців — наприклад, Coinbase чи MoonPay — шляхом підміни API-запитів або експортом конфіденційних даних.
Чому це проблема не лише розробника
Щодня відбуваються мільйони інсталяцій залежностей — вручну перевірити кожну неможливо. І хоча відповідальність часто покладають на команди розробки, цього недостатньо.
«Нереально очікувати, що кожен розробник самотужки виявить усі загрози. Безпека має забезпечуватись системно — через автоматичні перевірки, аналіз поведінки, політики безпеки CI/CD та перевірені каталоги залежностей», — пояснює Муссаллі.
Що робити українським розробникам і DevOps-ам
уважно перевіряйте назви залежностей перед встановленням;
не ігноруйте попередження систем безпеки, навіть якщо пакет «схожий на той, що ви вже використовували»;
налаштовуйте перевірки на typosquatting у ваших CI/CD-пайплайнах (наприклад, через JFrog Xray чи аналоги);
використовуйте бібліотеки з довгою історією, активною спільнотою та прозорими оновленнями;
ізолюйте ключі та секрети: уникайте зберігання API-ключів у відкритому вигляді, особливо у скриптах або CI.
Наразі блокчейн системи вважаються одними із найбільш захищених через свою архітектуру, тому такі модулі можуть потенційно нанести багато шкоди, якщо розслабитись і втратити пильність.
Для українських компаній, які працюють у FinTech, Web3 або просто інтегрують криптобіржі у свої сервіси, ризики атак на ланцюг постачання — цілком реальні. Один зайвий символ у назві пакета може коштувати доступу до гаманців або виведення коштів із бірж.
Команда ESLint представила нову систему придушування (suppressions), яка дозволяє поступово впроваджувати суворіші правила лінтингу без болісного рефакторингу всього легасі-коду. Тепер можна зафіксувати існуючі помилки окремим файлом, увімкнути нові правила як error — і бути впевненим, що ESLint не зламає CI/CD через старі порушення. А з часом ці помилки можна буде поступово виправити без тиску дедлайнів.
Проблема: нове правило — стара кодова база
Знайомо? Ви хочете увімкнути нове правило, наприклад, no-undef, щоб зробити код чистішим і стабільнішим. Але в кодовій базі вже десятки порушень, а правило не auto-fixable. Вибір невеликий: або все виправити одразу (що рідко можливо), або обмежитись попередженням (warn), або почати розкидати eslint-disable в коментарях.
Жоден із підходів не дозволяє повноцінно впровадити правило як error для нового коду і водночас мати контроль над старими порушеннями. Саме цю проблему вирішує нова система ESLint suppressions.
Як це працює
Новий механізм дозволяє:
зафіксувати всі поточні порушення у спеціальному файлі eslint-suppressions.json;
увімкнути правило як error, яке спрацьовує тільки на новий код;
поступово чистити легасі, орієнтуючись на suppressions-файл.
Запустити фіксацію suppressions можна з CLI:
Виправити те, що можна, і зафіксувати все інше
eslint --suppress-all --fix
Виправити все, що можливо, і зафіксувати лише конкретне правило
eslint --suppress-rule <rule-name> --fix
У результаті в корені проєкту створюється файл eslint-suppressions.json з приблизно такою структурою:
{
"src/file1.js": {
"no-undef": {
"count": 1
}
},
"src/file2.js": {
"no-unused-expressions": {
"count": 2
}
}
}
Цей файл не приглушує порушення на рівні рядків, лише на рівні "файл + правило". Якщо у file1.js раніше було 2 помилки no-undef, а після зміни стало 5 — ESLint покаже всі п’ять. Це зроблено навмисно: система не намагається вгадувати, чи нове це порушення, чи старе — натомість дає прозору картину.
Кастомне розташування suppressions-файлу
За замовчуванням ESLint створює suppressions-файл у корені проєкту, але можна змінити його розташування через флаг --suppressions-location:
eslint --suppress-all --suppressions-location ./suppressions.json
Цей шлях може бути абсолютним або відносним. Усі наступні запуски з цим suppressions-файлом мають вказувати його місце розташування:
eslint --suppressions-location suppressions.json
Підтримка suppressions у довгостроковій перспективі
Suppressions-файл рекомендується комітити до репозиторію — це забезпечує консистентність lint-результатів у команді.
З часом частину порушень можна буде прибрати вручну або автоматично, і тоді suppressions-файл втратить актуальність. ESLint попередить про це:
There are suppressions left that do not occur anymore. Consider re-running the command with --prune-suppressions.
Щоб очистити файл від неактуальних записів, достатньо запустити:
eslint --prune-suppressions
Це прибере всі suppressions, які більше не відповідають поточному стану коду.
Що ще варто знати
Suppressions-файл не впливає на linting, поки ви його не використовуєте.
Працює разом з --fix і --cache.
Впливає лише на error-рівень порушень.
Інформація про приглушені порушення доступна окремо через LintResult#suppressedMessages — для тих, хто інтегрує ESLint у свої тулінги.
Функціональність вже доступна в останній версії ESLint. Можна запускати в реальні проєкти.
