У сфері розробки програмного забезпечення зафіксовано нову масштабну атаку на ланцюжок постачання (Software Supply Chain Attack), яка отримала кодову назву easy-day-js. Цього разу під удар потрапив популярний фреймворк з відкритим вихідним кодом Mastra, призначений для створення додатків на базі штучного інтелекту (AI) за допомогою JavaScript та TypeScript. Згідно з дослідженнями компаній JFrog, SafeDep, Socket та StepSecurity, зловмисникам вдалося скомпрометувати 144 пакети в офіційному репозиторії npm під простором імен @mastra/*.

Через зламаний акаунт розробника заражено 144 npm-пакети Mastra

Причиною інциденту став зламаний обліковий запис одного з розробників (ehindero), який мав права на публікацію нових версій пакетів Mastra. Отримавши доступ до цього акаунту, зловмисники автоматизували процес масової публікації шкідливих оновлень. У результаті десятки легітимних бібліотек, які використовуються для інтеграції великих мовних моделей (LLM), агентів та складних робочих процесів, виявилися зараженими шкідливим кодом.

Технічний аналіз показав, що шкідливий код націлений на збір та ексфільтрацію чутливих даних з оточення розробки або розгортання додатків. Оскільки фреймворки для ШІ потребують доступу до хмарних сервісів, баз даних та API-ключів комерційних моделей (таких як OpenAI, Anthropic, Cohere), середовище виконання Mastra є ідеальною мішенню для крадіжки цінних секретів. Заражені пакети збирали змінні оточення (environment variables), системну інформацію, ключі доступу до хмарних платформ AWS, Google Cloud та токени авторизації, після чого відправляли їх на сервер зловмисників.

Цей інцидент підкреслює вразливість сучасних екосистем, де розробники сліпо довірятимуть відомим бібліотекам і автоматично оновлюють залежності. Оскільки Mastra використовують багато стартапів та інноваційних компаній, які часто не мають зрілих процесів аудиту безпеки коду та моніторингу залежностей, компрометація навіть одного акаунту контриб'ютора призводить до зараження тисяч кінцевих продуктів, які імпортують ці пакети під час збирання в CI/CD-конвеєрах.

Реакція спільноти була швидкою: шкідливі версії пакетів уже видалені або замінені чистими релізами в npm. Проте для розробників, які встигли завантажити компрометовані версії у свої локальні середовища, загроза залишається актуальною, оскільки їхні секрети та ключі доступу могли бути скомпрометовані та передані третім особам.

Що це означає на практиці

З точки зору практичної безпеки та організації процесу безпечної розробки (DevSecOps), командам рекомендується вжити таких заходів:

  • Аудит залежностей проекту: Перевірте конфігураційні файли (package-lock.json, pnpm-lock.yaml або yarn.lock) на наявність пакетів з простору імен @mastra/*. Переконайтеся, що ви використовуєте чисті версії та не імпортуєте код, опублікований скомпрометованим акаунтом ehindero.
  • Ротація API-ключів та секретів: Якщо у вашому середовищі розробки чи на сервері використовувалися скомпрометовані версії Mastra, вважайте всі змінні оточення скомпрометованими. Негайно відкличте та перегенеруйте ключі для ШІ-провайдерів (OpenAI, Anthropic тощо), токени доступу до баз даних та облікові дані для хмарних сервісів AWS, GCP чи Azure.
  • Використання інструментів SCA: Впровадьте у свій CI/CD-процес інструменти аналізу складу ПЗ (SCA), такі як Snyk, Socket, StepSecurity або OWASP Dependency-Check. Ці інструменти дозволяють автоматично виявляти підозрілу поведінку пакетів та відомі вразливості залежностей на етапі збирання проекту.
  • Обмеження вихідного трафіку: Налаштуйте правила брандмауера для серверів розробки та CI/CD-раннерів для обмеження вихідного трафіку лише довіреними адресами. Це ускладнить роботу шкідливого ПЗ, яке намагається надіслати викрадені дані на C2-сервери.
  • Впровадження 2FA: Якщо ваша организация розробляє власні npm-пакети, впровадьте обов'язкову двофакторну автентифікацію (2FA/MFA) для всіх облікових записів розробників у репозиторіях коду та менеджерів пакетів. Також використовуйте підписування комітів за допомогою GPG або SSH-ключів.