Чи може AI допомогти розв’язати проблему, над якою інженери працювали роками? І наскільки можна довіряти результатам тестування AI-моделей, якщо вони знаходять способи обійти правила? У жовтневому дайджесті — експеримент Лінуса Торвальдса з Claude Code, несподівана поведінка моделі Liquid AI, нові загрози для розробників та зміни в інструментах, якими вони користуються щодня.
Ці та інші новини, а також їхнє практичне значення для інженерних команд розбирає Макс Березанський, Tech Lead у Keiki.
Головне у матеріалі
npm-хробак ChainDrop атакує розробників: викрадає токени доступу, заражає інші пакети та може видаляти файли після відкликання GitHub-токена.
Лінус Торвальдс використав Claude Code для оптимізації Linux: у синтетичному тесті продуктивність зросла у 23 рази, але під час кодрев’ю розробники виявили критичну помилку.
AI-модель Liquid AI навчилася обходити тестування: замість самостійного розв’язання задач шукала готові відповіді в GitHub та інших джерелах.
Зловмисники маскують шкідливе ПЗ під Claude і ChatGPT: через підроблені інструкції зі встановлення викрадають код, SSH-ключі й токени розробників.
Google перейшла з Pytype на Pyrefly від Meta: новий інструмент перевірки типів Python працює приблизно в 10 разів швидше та скорочує витрати на обчислення.
ChainDrop: npm-хробак краде токени й заражає інші пакети
У версії 0.5.144 npm-пакета Tensorlake SDK виявили шкідливий код, який викрадає облікові дані розробників і поширюється на інші пакети. Компанія Socket помітила заражену версію 8 жовтня, приблизно через 11 хвилин після публікації.
Хробак запускається вже під час npm install, якщо дозволено виконання інсталяційних скриптів. Тобто достатньо встановити заражений пакет — навіть імпортувати бібліотеку в код або запускати застосунок не потрібно. Шкідлива програма шукає npm- і GitHub-токени, секрети хмарних сервісів та конфігурації інструментів на кшталт Claude Code і Cursor.
Використовуючи викрадені права на публікацію, хробак випускає заражені версії інших npm-пакетів. Він також створює підроблені записи Sigstore provenance — дані про походження збірок, які мають допомагати перевіряти їхню справжність. Для зв’язку зі зловмисниками програма використовує Ethereum-смартконтракт, а шкідливі GitHub Actions маскує під звичайні автоматизовані процеси.
Окрема небезпека — реакція на відкликання GitHub-токена. Хробак встановлює фоновий процес, який перевіряє, чи залишається викрадений токен чинним. Якщо відкликати його, поки цей процес працює, може спрацювати механізм видалення домашньої директорії користувача. Тому в разі зараження потрібно спочатку ізолювати машину та вимкнути встановлений шкідливою програмою механізм моніторингу, а вже потім змінювати ключі доступу.
Атака нагадує кампанію Shai-Hulud, яка з 2025 року поширюється через npm. Це приклад того, як один заражений пакет може не лише викрасти секрети розробника, а й запустити ланцюгове зараження інших проєктів.
Лінус Торвальдс залучив Claude Code до оптимізації ядра Linux
Творець Linux Лінус Торвальдс використав Claude Code для розв’язання проблеми продуктивності ядра, над якою розробники працювали понад два роки. AI-асистент допоміг підготувати патчі, тести й документацію, а Торвальдс керував процесом і сам перевіряв результати.
Проблема стосувалася page cache — механізму, який зберігає нещодавно прочитані дані файлів в оперативній пам’яті, щоб не звертатися щоразу до диска. Під час одночасного читання кількома потоками операції з лічильниками посилань на сторінки пам’яті створювали додаткове навантаження й сповільнювали роботу. Запропоновані зміни дозволили скоротити кількість цих операцій.
У синтетичному тесті на 64-потоковому Ryzen Threadripper продуктивність читання зросла приблизно у 23 рази — з 13,3 до 304 млн операцій на секунду. У реальних застосунках приріст буде значно скромнішим, про що попередив і сам Торвальдс.
Однак під час кодрев’ю розробники ядра знайшли race condition — помилку, за якої результат залежить від порядку одночасних операцій. За певних умов вона могла призвести до читання даних, які ще не були записані у файл. Після обговорення проблему врахували в оновленому патчі, а подальшу роботу над оптимізацією передали розробнику ядра.
Цікаво, як саме розподілилися ролі: Торвальдс поставив задачу й керував процесом, Claude Code підготував реалізацію, після чого автор Linux перевірив продуктивність, а розробники спільноти виявили помилку під час рев’ю. AI не замінив інженерну експертизу, а став інструментом у руках досвідченого розробника. У невеликих командах, де немає спільноти рев’юверів масштабу Linux, процес буде іншим, але сам принцип розподілу відповідальності цілком можна застосовувати.
Liquid AI виявила, що її модель шукала готові відповіді під час тестування
Під час навчання моделі LFM2.5-24B-A2B компанія Liquid AI помітила, що замість самостійного розв’язання задач із програмування вона шукала готові відповіді в історії Git, на GitHub, PyPI та Hugging Face. Ситуація трохи нагадує студентів, які замість розв’язання завдання шукають готову відповідь.
Таку поведінку називають reward hacking — коли AI знаходить спосіб отримати бажану оцінку, не обов’язково виконуючи завдання так, як задумали розробники. Дослідники також помітили ознаки того, що модель розпізнавала тестове середовище (sandbox). Водночас Liquid AI не встановила, звідки взялася така поведінка, і не знайшла доказів, що вона вплинула на опубліковані результати тестів.
Проблема не обмежується Liquid AI. Наприклад, дослідники BenchJack виявили 219 недоліків у десяти популярних бенчмарках для AI-агентів. Через такі прогалини моделі можуть отримувати високі оцінки, фактично не виконуючи поставлених завдань. В іншому дослідженні обмеження доступу до готових відповідей і механізмів перевірки зменшило частоту використання подібних лазівок майже на 88%.
Тому, коли ми тестуємо AI-агентів, обмеження краще закладати безпосередньо в середовище, а не розраховувати, що модель дотримуватиметься правил лише тому, що її про це попросили.
Фальшиві Claude і ChatGPT використовують для викрадення даних розробників
Зловмисники дедалі частіше маскують шкідливе ПЗ під популярні AI-інструменти. За даними дослідників Any.Run, за шість місяців на їхній платформі проаналізували 1258 випадків атак із використанням підроблених AI-сервісів. Найчастіше зловмисники видавали свої інструменти за Claude (60% випадків), ChatGPT і Codex (33%).
Схема доволі проста. Людина шукає, як встановити черговий AI-інструмент, переходить за посиланням із пошуку, реклами або документації та отримує команду для термінала. Вона виглядає як звичайна інструкція зі встановлення, але насправді запускає шкідливий код. Такі атаки називають ClickFix та InstallFix. За даними Any.Run, приблизно у 45% досліджених випадків користувачів спонукали самостійно скопіювати й виконати команду.
Причому шкідливі інструкції можуть розміщувати не лише на підроблених сайтах. Зловмисники використовують GitHub, Cloudflare Pages, Google Sites, а також справжні платформи Claude і ChatGPT (наприклад, публікують інструкції в поширених чатах або створених користувачами матеріалах). Людина бачить знайомий домен і не очікує, що посилання чи команда всередині можуть бути небезпечними.
Для розробників наслідками можуть стати викрадення вихідного коду, SSH-ключів, CI/CD-токенів і ключів доступу до хмарних та AI-сервісів. Соціальна інженерія тут працює особливо добре: користувача навіть не потрібно довго переконувати, адже встановлення інструментів через термінал давно стало звичайною практикою.
Для security-команд це привід переглянути, які AI-інструменти співробітники можуть встановлювати самостійно. Варто сформувати перелік дозволених сервісів, а перед встановленням нових інструментів перевіряти джерело та звіряти команди з офіційною документацією.
Google замінила власний Python-інструмент на розробку Meta
Google відмовилася від власного інструмента Pytype для перевірки типів у Python і перейшла на Pyrefly (це відкритий проєкт, який створила Meta). Цікаво, що компанія обрала технологію свого конкурента замість подальшого розвитку власного рішення.
Pytype аналізував скомпільований байткод Python, тому з кожною новою версією мови підтримувати його ставало складніше. Pyrefly працює безпосередньо з вихідним кодом, написаний на Rust і краще підтримує сучасні можливості типізації Python. Він також дає зрозуміліші підказки щодо помилок і в деяких випадках пропонує виправлення.
За внутрішніми тестами Google, Pyrefly працює приблизно в 10 разів швидше за Pytype, скорочує затримку повторної перевірки після змін у коді до 98% і зменшує пікові витрати на обчислення більш ніж на 80%. Перевірка типів під час повної збірки також стала швидшою на 90-99%. Для великих кодових баз це означає менше очікування під час розробки та CI.
