Дайджест технічних новин: атаки Lazarus, проблеми ШІ-коду та нативний TypeScript у Node.js
- Таїсія Красноштан
- 21 бер.
- Читати 4 хв
Оновлено: 23 бер.
У дайджесті новин запрошені експерти розповідають про найцікавіші події в технологічній індустрії. Березневий випуск підготував Максим Березанський, Tech Lead в Keiki з екосистеми Genesis.
Цього разу говоримо про те, що Microsoft переписала компілятор TypeScript на Go, чергову атаку угруповання Lazarus на npm-пакети, а також неочікувані проблеми, що виникають через ШІ-асистентів для програмування. Огляд цих та інших новин — у матеріалі.
TypeScript переписали на Go: пришвидшення в 10 разів
Microsoft переписала компілятор TypeScript на Go, що збільшило його швидкість у 10 разів. Це означає кардинальні покращення продуктивності для всіх розробників, які працюють із TypeScript — і на фронтенді, і на бекенді.
Раніше найслабшою ланкою у швидкодії TypeScript було використання компілятора, написаного на JavaScript. Його слабкість — він однопотоковий, тобто може використовувати лише одне ядро процесора. Перехід на Go дозволив розпаралелити процеси й максимально використати ресурси багатоядерних процесорів. Це значно прискорить збірки (білди) проєктів, перевірку коду та всі процеси, пов'язані з компіляцією. Найбільший ефект відчує бізнес із великими монорепозиторіями та складними CI/CD-процесами, де швидкість типізації завжди була слабким місцем.
Це доволі інтригуюча новина! Спільнота багато років просила підвищити продуктивність TypeScript — і нарешті це сталося. Це означає швидші білди, швидші локальні перевірки та загалом комфортніший Developer Experience (DX).
Новий TypeScript обіцяє стати значно привабливішим вибором для команд, які раніше уникали його через проблеми з продуктивністю.
Інакше кажучи, це оновлення буде відчутним та позитивним для всіх, хто працює з цією мовою програмування. Бета-версія стане доступною найближчим часом.
Безпека бізнес-застосунків продовжує погіршуватися
Згідно з новим звітом компанії Veracode, за останні 5 років кількість застосунків із серйозними вразливостями зросла на 181%. Найбільша проблема — сторонні бібліотеки: 70% застосунків містять уразливості саме в них, тоді як у власному коді таких проблем менше (64%). Ще один нюанс — виправлення помилок у third-party коді займає на 50% більше часу, ніж у власних рішеннях.
Чому так відбувається?
Багато бібліотек мають складні залежності, які важко оновлювати без ризику «зламати» проєкт.
Деякі open-source проєкти стають менш активними та перестають підтримуватися.
Частина вразливостей може існувати роками, адже вони впливають лише на окремі функції, які не завжди використовуються.
Якщо залежність використовується напряму, її можна замінити локально або знайти безпечний аналог. Однак якщо заражена бібліотека є частиною більших залежностей, виявити та видалити її буде набагато складніше.
Сторонні модулі не настільки широко використовуються, тож глобальних змін чекати не варто. Це радше сигнал для бізнесу: час переглянути безпеку, провести аудит або хоча б оцінити реальні ризики для продукту. А ще — критичніше ставитися до thith party-модулів, коли виникає бажання додати новий. Ну і рекомендую класний інструмент для моніторингу вразливостей — Snyk.
ШІ-код без рефакторингу — крок уперед чи катастрофа розробки ПЗ?
GitClear провели масштабне дослідження 211 мільйонів рядків коду та з’ясували, що ШІ-асистенти для програмування спричиняють збільшення дублювання коду та загального «шуму» в проєктах. У 2024 році кількість повторюваного коду вперше за всю історію програмування перевищила кількість рефакторингу.
Це означає, що:
швидкість розробки значно покращується завдяки AI, але це відбувається за рахунок якості;
рефакторинг падає, що може спричинити труднощі в підтримці ПЗ у майбутньому;
кількість змін у кодовій базі подвоїться у 2025 році порівняно з 2021 роком.
Можна сказати, що фраза «AI не замінить розробників, а розробники з AI замінять тих, хто його не використовує» стала реальністю: штучний інтелект у роботі активно використовують понад 60% програмістів. Однак, якщо якість коду не покращиться, ми зіштовхнемося з кризою програмного забезпечення. Головна проблема полягає в тому, що AI-асистенти швидко генерують код, але не оптимізують його, а лише додають нові рядки.
Втім, це класна новина для тих, хто боїться, що їх замінить штучний інтелект, і трошки збадьорююча для тих, хто загрався в AI та почав покладатися на нього занадто сильно. Дуже подобається теза, що «зі збільшенням code assistant tools фундаментальні поняття і принципи software development залишаються незмінними». Бо в гонитві за швидкістю не варто нехтувати якістю.
Хакери Lazarus знову атакують npm — дослідники виявили нові шкідливі пакети
Дослідники з Socket Research Team виявили шість нових npm-пакетів, які використовуються для крадіжки облікових даних, криптовалютних даних і впровадження бекдорів у середовища розробників. У всіх знайдених бібліотеках вбудовано BeaverTail malware, що підтверджує їхню схожість із попередніми атаками Lazarus Group.
До списку підозрілих npm-пакетів увійшли:
is-buffer-validator
yoojae-validator
event-handle-package
array-empty-validator
react-event-dependency
auth-validator
Як працює схема атаки?
Typosquatting — хакери створюють пакети з назвами, схожими на популярні бібліотеки, щоб розробники випадково їх встановили.
GitHub-кампанія — зловмисники реєструють відповідні репозиторії, щоб їхні пакети виглядали переконливіше.
Кросплатформний вплив — ці шкідливі бібліотеки атакують Windows, macOS і Linux, що розширює масштаби атаки.
Модульний бекдор — пакети містять BeaverTail malware і другий рівень атаки InvisibleFerret, що дає атакуючим змогу отримати стійкий доступ до системи.
GitHub досить активно реагує і видаляє ці репозиторії, проте перевіряйте уважно, які пакети ви встановлюєте та аналізуйте їх репутацію.
Тепер TypeScript у Node.js працює без додаткових налаштувань!
Команда Node.js офіційно анонсувала підтримку TypeScript у версії 23.6. Тепер розробники можуть запускати TypeScript-файли напряму — без прапорців, додаткових конфігурацій чи попередньої компіляції.
Це велике покращення DX, оскільки більше не потрібно встановлювати ts-node або вручну транспілювати код. Проте це не повноцінна заміна компіляції: TypeScript – Node просто видаляє анотації типів (type stripping) і виконує код як звичайний JavaScript. Зараз достатньо написати index.ts, виконати node index.ts — і Node самостійно прибере типізацію.
Окрім цього:
не потрібні додаткові інструменти, тобто TypeScript-файли можна запускати напряму;
менше налаштувань середовища — не треба встановлювати компілятор TypeScript або ts-node;
простий DX зменшує час на конфігурацію.
Але, звичайно, є й обмеження… Node ігнорує tsconfig.json, а отже, не підтримує: налаштування шляхів, новий синтаксис JS у старих версіях та JSX-файли. Не підтримуються також TypeScript-структури, що вимагають генерації коду в рантаймі, наприклад: enum-конструкції, namespace з кодом у рантаймі, import-аліаси.
Це наближає Node до TypeScript-нативних рантаймів, таких як Deno та Bun, але з обмеженнями. Наприклад, Deno все ще підтримує tsconfig.json і може розповсюджувати TypeScript без транспіляції.
Загалом, крутий крок уперед для DX у Node.js, але не без компромісів.
