Детальний посібник з аудиту безпеки npm та атак на ланцюги поставок

Головна » Python » Детальний посібник з аудиту безпеки npm та атак на ланцюги поставок

Якщо ви сьогодні створюєте щось за допомогою Node.js або TypeScript, ви стоїте на вершині гігантської купи залежностей npm, які ви не писали і, ймовірно, ніколи повністю не прочитаєте. Це неймовірно зручно для швидкого впровадження функцій, але також відкриває величезну поверхню для атак на ланцюги поставок, крадіжку облікових даних та непомітні бекдори, що проникають у ваші програми або конвеєри CI/CD.

Сучасна безпека npm — це вже не просто питання «чи є в моїх пакетах відомі CVE?» — це питання… захист від фішингових кампаній, що захоплюють облікові записи адміністраторів, черв’яки, які автоматично публікують заражені версії, та шкідливі бібліотеки, які намагаються видалити дані розробника home каталог або викрасти хмарні облікові дані. У цьому посібнику ми розглянемо, як аудит безпеки npm працює, як покращити свої робочі процеси за допомогою таких інструментів, як npm audit, Dependabot, сканери SAST/SCA та перевірки CI/CD, а також що ви реально можете зробити як розробник, коли хвилюєтеся, що «ця класна маленька бібліотека може бути шкідливим програмним забезпеченням».

Чому безпека залежностей npm така важлива

Щоразу, коли ти біжиш npm install, ви імпортуєте сторонній код у свій проєкт і фактично довіряючи своїм авторам з частиною вашої поверхні атаки. У Node.js цей ланцюжок довіри може бути напрочуд глибоким: одна залежність верхнього рівня може залучати сотні транзитивних пакетів, які ви ніколи безпосередньо не обирали.

Вразливі або покинуті залежності можуть призвести до класичних проблем безпеки, таких як атаки ін'єкцій, відмова в обслуговуванні (DoS), ескалація привілеїв або витік даних. Навіть невелика помилка в низькорівневій утиліті – HTTP-клієнті, синтаксичному аналізаторі кольорів, завантажувачі YAML – може мати значний вплив, якщо вона знаходиться в популярних фреймворках та інструментах.

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

Підтримка аудиту та оновлення залежностей тому це не приємне гігієнічне завдання, а ключова частина підтримки будь-якого серйозного проекту Node.js або TypeScript. Регулярні аудити безпеки, як автоматизовані, так і ручні, — єдиний спосіб утримувати ризик від стороннього коду на прийнятному рівні.

Розуміння npm-аудиту та що він насправді перевіряє

npm audit – це вбудована команда, яка сканує дерево залежностей вашого проєкту на наявність у базі даних відомих вразливостей та створює звіт про безпеку. Коли ви запускаєте її в кореневому каталозі вашого проєкту, npm переглядає ваш package.json і файл блокування, будує повний граф залежностей і зіставляє кожну версію з рекомендаціями.

Аудиторський звіт охоплює обидва прямі та непрямі залежності (пакети, які ви перераховуєте самі, та залежності залежностей). Для кожної проблеми перелічено уражений пакет, короткий опис вразливості, її серйозність (низька, помірна, висока, критична) та діапазон версій, що містять виправлення.

З точки зору робочого процесу, npm audit можна використовувати інтерактивно розробниками та неінтерактивно в конвеєрах CI/CD. У конвеєрах ви навіть можете зробити так, щоб збірка завершилася невдало, лише якщо вразливості перевищують певний поріг серйозності, використовуючи такі прапорці, як --audit-level.

Цей інструмент належить до ширшого сімейства Аналіз складу програмного забезпечення (SCA): він зосереджується на відомих проблемах у компонентах з відкритим кодом, а не на помилках у вашому власному коді. Це означає, що він дуже потужний для виявлення застарілих або вразливих бібліотек, але не виявляє магічним чином абсолютно нового шкідливого програмного забезпечення, що постачалося вчора під ніколи раніше не використовуваною назвою пакета.

Як провести npm-аудит та інтерпретувати результати

Щоб виконати базовий аудит безпеки, відкрийте термінал у кореневому каталозі вашого проекту (де package.json життя) і бігти npm auditПісля короткого аналізу залежностей, npm виведе таблицю проблем, згрупованих за серйозністю, разом із запропонованими кроками щодо їх усунення, такими як оновлення до виправленої версії.

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

Якщо ви хочете передати результати в інші інструменти або зберегти їх на потім, ви можете запросити вивід JSON через npm audit --jsonЦе особливо зручно під час інтеграції з користувацькими панелями інструментів, системами продажу заявок або платформами оркестрації безпеки.

У конвеєрах CI/CD багато команд налаштовують конвеєр для роботи npm audit --json одразу після встановлення залежностей, проаналізувати результат і завершити збірку невдало, якщо присутня будь-яка вразливість вище вибраного рівня серйозності. Зовнішні помічники, такі як audit-ci може обгорнути цю логіку для вас і надати зручні опції для переривання збірок у разі перевищення порогових значень.

Виправлення вразливостей за допомогою npm-аудиту

один раз npm audit попереджає про проблеми, ваша перша лінія захисту — це npm audit fix, який намагається автоматично оновити вразливі залежності до найближчих безпечних версій. Під капотом він переписує package-lock.json (І package.json (де це можливо) для збільшення пакетів у межах сумісних діапазонів версій.

Це автоматичне виправлення добре працює для багатьох проблем низького та середнього ступеня серйозності, і навіть для деяких проблем з більшою серйозністю, коли виправленням є незначний випуск або патч. Це швидка перемога, яка часто вирішує значну частину вашого списку невиконаних завдань з мінімальними людськими зусиллями.

Не кожну вразливість можна безпечно виправити за допомогою автоматичного оновлення; деякі вимагають суттєвих змін версії, які можуть порушити роботу вашого коду або інших залежностей. Ось тут і виникає проблема. npm audit fix --force з'являється: він примушує до оновлення навіть після критичних змін, але ви повинні використовувати його обережно та завжди ретельно тестувати після цього.

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

Блокування файлів, npm ci та детерміновані інсталяції

Команда package-lock.json файл (або yarn.lock/pnpm-lock.yaml (для інших менеджерів) є критично важливим для безпеки, оскільки він закріплює точні версії кожної залежності, що використовується вашим проектом. Без нього кожен npm install може витягувати дещо різні сумісні версії, що робить збірки недетермінованими та складнішими для аудиту.

Вам слід уникати редагування package-lock.json вручну, а натомість дозвольте npm керувати цим, коли ви додаєте, видаляєте або оновлюєте залежності. Під час коміту коду завжди включайте обидва package.json і файл блокування, щоб усі – і ваш CI/CD – встановлювали однакові версії.

В автоматизованих середовищах віддавайте перевагу npm ci над npm install оскільки npm ci використовує файл блокування як суворий контракт і відмовляється запускатися, якщо він не відповідає оголошеним залежностям. Це забезпечує швидші та повністю відтворювані встановлення, що саме те, що вам потрібно в CI.

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

Автоматизація оновлень за допомогою Dependabot, Renovate та npm-інструментів

Ручне відстеження застарілих або вразливих пакетів у багатьох репозиторіях швидко стає некерованим, тому автоматизація за допомогою таких інструментів, як Депендабот або Renovate дуже цінний. Ці сервіси відстежують ваші залежності та відкривають пул-реквести, коли з'являються нові версії або виправлення безпеки.

Наприклад, Dependabot від GitHub налаштовується через .github/dependabot.yml файл, який визначає, які екосистеми слід спостерігати, частоту оновлення та цільові гілки. Коли виявляється вразливий або застарілий npm-пакет, створюється PR-оновлення. package.json та package-lock.json, часто з посиланнями на рекомендації.

Поєднано з npm audit, ви отримуєте приємний цикл зворотного зв'язку: аудит виявляє проблеми, а Dependabot (або Renovate) постійно пропонує оновлення для їх усунення. Ваше завдання полягає в перегляді та тестуванні цих запитів на внесення змін, а не в ручному пошуку кожного бампу версії.

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

Виконання перевірок безпеки в конвеєрах CI/CD

Безпечне налаштування npm не обмежується лише вашим ноутбуком; ваші конвеєри CI/CD також повинні забезпечувати перевірки безпеки, щоб запобігти потраплянню вразливого або шкідливого коду у продакшн. Кожен етап – вихідний код, збірка, тестування, розгортання – повинен мати відповідні елементи керування.

Бігти — це звичайна справа. npm audit автоматично під час етапу збірки або передрозгортання, часто разом із --json прапорець для легшої інтеграції з інструментами моніторингу. Якщо сканування виявить вразливості, що перевищують поріг ризику, конвеєр може вийти з ладу та заблокувати випуск.

Розширені інструменти, такі як Сник можуть виступати в ролі контролерів безпеки в CI/CD, скануючи залежності та видаляючи збої у збірках, коли виявляються високі або критичні проблеми. Поєднання їх з аналізаторами якості, такими як SonarQube або SonarCloud, дає вам ширше уявлення про якість коду, ризики безпеки та технічний борг.

Під час розробки використовуються інструменти статичного аналізу, такі як ESLint, з плагінами, такими як eslint-plugin-security та eslint-plugin-node допомогти вам виявляти небезпечні шаблони на ранніх етапах вашого власного коду. Це доповнює сканування залежностей, яке зосереджується на сторонніх компонентах, а не на вашій бізнес-логіці.

Зміцнення конвеєрів CI/CD поза межами npm-аудиту

Автоматизоване сканування є потужним засобом, але безпечний конвеєр також потребує надійного управління секретами, надійного контролю доступу та належної гігієни репозиторію. Неправильно налаштовані секрети або надмірно дозвільні ролі можуть перетворити незначне порушення на повномасштабний інцидент.

Використовуйте спеціальні секретні менеджери, такі як Сховище HashiCorp або AWS Secrets Manager замість вбудовування токенів чи ключів у файли конфігурації чи змінні середовища, що передаються в систему керування версіями. Це зменшує ймовірність того, що зловмисник або навіть допитливий учасник натрапить на конфіденційні дані у вашому репозиторії.

Контроль доступу на основі ролей (RBAC) з принципом найменших привілеїв є критично важливим для GitHub, npm та будь-якої платформи CI/CD, яку ви використовуєте. Розробники та сервісні облікові записи повинні мати лише ті дозволи, які їм абсолютно необхідні – нічого більше.

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

Сповіщення від ваших інструментів безпеки слід інтегрувати в канали реального часу, такі як Slack, Microsoft Teams або електронна пошта, але ретельно налаштувати, щоб ваша команда не була перевантажена маловажними сповіщеннями. Пріоритетність за серйозністю та контекстом зосереджує увагу на тому, що справді важливо.

Атаки на ланцюги поставок NPM у реальному світі та чого вони нас навчають

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

В одній з кампаній відомий розробник npm отримав ретельно сформований фішинговий лист з домену, який виглядав майже невідрізним від офіційного сайту npm. Повідомлення погрожувало заблокувати обліковий запис, якщо двофакторну автентифікацію не буде «оновлено», що заманювало жертву на фальшиву сторінку входу, яка перехоплювала облікові дані.

Щойно зловмисник отримав контроль над npm-акаунтом розробника, він розповсюдив шкідливі версії 18 надзвичайно популярних пакетів з мільярдами завантажень щотижня. Оскільки ці пакети були глибоко вбудовані в граф залежностей екосистеми JavaScript, потенційний радіус вибуху був величезним.

Впроваджений код поводився як перехоплювач на стороні браузера, спрямований на криптовалюту та активність Web3: він перехоплював API браузера, такі як fetch, XMLHttpRequest та інтерфейси гаманців, такі як window.ethereum або API гаманця Solana. Він сканував мережеві відповіді та корисні дані транзакцій на предмет будь-чого, що виглядало як криптоадреса чи переказ.

Виявивши транзакцію, шкідливе програмне забезпечення замінювало законну адресу одержувача на адресу, контрольовану зловмисником, часто вибираючи схожі рядки, щоб уникнути підозр. У багатьох випадках інтерфейс користувача все ще відображав «правильну» адресу, тоді як базові підписані дані вже були змінені для надсилання коштів зловмиснику.

Шкідливий код був сильно завуальований, з такими змінними, як _0x... і великі закодовані масиви рядків, декодовані під час виконання, і іноді він повертав фальшиві відповіді про успіх, щоб програма не помітила нічого поганого. Лише певні програми були справді придатними для використання, особливо ті, що взаємодіяли з гаманцями або криптосервісами та встановлювали уражені версії у вузькому вікні компрометації.

Вказівки щодо інциденту з перехоплювачем браузера

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

Ретельна перевірка package.json та package-lock.json (Або yarn.lock) є важливим для перевірки того, чи ваш проект коли-небудь завантажував шкідливі версії. Саме тут детерміновані інсталяції та файли блокування з версією значно спрощують роботу з експертизи.

Якщо ваш застосунок взаємодіє з криптогаманцями або Web3 API, вам слід уважно стежити за журналами транзакцій на наявність аномальних пунктів призначення або неочікуваних схвалень у часовому вікні, де були присутні скомпрометовані пакети. Раннє виявлення може обмежити фінансові збитки та допомогти ідентифікувати постраждалих користувачів.

Посилення безпеки облікових записів за допомогою двофакторної автентифікації, в ідеалі за допомогою апаратних ключів, є життєво важливим для облікових записів npm та GitHub, особливо для тих, хто підтримує популярні пакети. Навіть у цьому випадку завжди скептично ставтеся до електронних листів із закликом перейти за посиланням для «оновлення» облікових даних; натомість перейдіть безпосередньо на офіційний сайт і перевірте там наявність сповіщень.

Організації, що використовують комерційні інструменти SCA та SBOM, часто можуть запитувати свої інвентаризації за назвою пакета та версією, щоб знайти всі системи та програми, які залежать від скомпрометованої бібліотеки. Така видимість значно скорочує час реагування на інциденти в ланцюжку поставок.

Черв'як Shai-Hulud: самовідтворюване шкідливе програмне забезпечення npm

Ще одна помітна кампанія, що отримала прізвисько Кампанія Шай-Хулудавивів атаки npm на ланцюги поставок на новий рівень, поводячись як самовідтворюваний черв'як у пакетах та середовищах розробника. Він перетворив пост-інсталяційні скрипти npm на зброю для запуску шкідливої ​​логіки одразу після встановлення скомпрометованої версії.

Шкідливе програмне забезпечення сканувало середовище на наявність конфіденційних облікових даних, зокрема .npmrc файли з токенами npm, персональними токенами доступу GitHub, ключами SSH та ключами API хмарних провайдерів для AWS, GCP та Azure. Все, що було знайдено, було вивезено до інфраструктури, контрольованої зловмисником.

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

У багатьох випадках викрадені секрети скидалися до новостворених публічних репозиторіїв GitHub від імені власного облікового запису жертви, з іменами або описами, що посилаються на Шай-Хулуда. Це ще більше погіршувало проблему, оскільки конфіденційні дані потрапляли до кожного, хто випадково натрапляв на ці репозиторії.

Дослідники з безпеки помітили характерні ознаки (зокрема дивні коментарі та парні емодзі), які свідчать про те, що частини шкідливих bash-скриптів були згенеровані за допомогою моделей великих мов. Це яскравий приклад того, як генеративний штучний інтелект можна використовувати для прискорення створення інструментів атаки.

Шай-Хулуд 2.0: саботаж перед встановленням та руйнівні резервні варіанти

Пізніша хвиля, що отримала назву Shai‑Hulud 2.0, змінила тактику виконання на етапі перед встановленням, а не після встановлення, що значно розширило охоплення на машинах розробників та серверах CI/CD. Скрипти перед встановленням запускаються ще раніше на етапі життєвого циклу та можуть спрацьовувати на більшій кількості систем.

Одним із найтривожніших аспектів цього варіанту був резервний механізм: якщо шкідливе програмне забезпечення не вдавалося викрасти корисні облікові дані або встановити канал зв'язку, воно намагалося виконувати деструктивну поведінку, таку як витирання жертви home каталогЦе сталося шляхом перезапису та безпечного видалення будь-яких файлів, придатних для запису, що належать поточному користувачеві в цьому каталозі.

Корисне навантаження було замасковане під корисні скрипти інсталятора Bun, такі як setup_bun.js і величезний, сильно заплутаний bun_environment.js файл розміром перевищує 9 МБ. Щоб не привертати уваги, основна логіка перейшла у фоновий процес, завдяки чому початкове встановлення завершилося нормально.

Облікові дані та секрети, зібрані в рамках цієї кампанії, знову були вивезені на GitHub, цього разу до репозиторіїв, описаних як «Sha1‑Hulud: The Second Coming», і шкідливе програмне забезпечення намагалося отримати стійкість, створюючи робочі процеси GitHub Actions, такі як discussion.yamlЦі робочі процеси реєстрували заражені машини як самостійно розміщені програми, що дозволяло зловмисникам запускати довільні команди, просто відкриваючи обговорення.

Загальний масштаб атаки був величезним, торкнувшись десятків тисяч репозиторіїв та понад 25 тисяч шкідливих репозиторіїв на сотнях облікових записів GitHub, включаючи популярні бібліотеки, такі як @ctrl/tinycolor з мільйонами завантажень щотижня. Оскільки метою була крадіжка облікових даних для хмарних платформ, подальший вплив міг варіюватися від крадіжки даних та програм-вимагачів до криптомайнінгу та широкомасштабних перебоїв у наданні послуг.

Негайні захисні дії проти шкідливих програм-червів ланцюга поставок npm

Зіткнувшись із кампаніями, подібними до Shai-Hulud, фахівці з реагування на інциденти рекомендують негайно замінити всі облікові дані розробника – токени npm, PAT-файли GitHub, ключі SSH та будь-які ключі хмарного API, що використовуються на комп’ютерах розробників або серверах збірки. Припустімо, що будь-що, що знаходилося на скомпрометованій робочій станції, могло статися витік.

Повний аудит залежностей у всіх проектах є важливим, використовуючи такі інструменти, як npm audit, інвентаризації SBOM або комерційні платформи SCA, щоб знайти будь-які випадки використання назв та версій пакетів, на які поширюються проблеми. Файли блокування (package-lock.json, yarn.lock) надають достовірну інформацію про те, що було фактично встановлено.

Розробникам слід перевірити свої облікові записи GitHub на наявність дивних публічних репозиторіїв (особливо названих на честь Шай-Хулуда), підозрілих комітів або неочікуваних змін у робочих процесах GitHub Actions, які могли зареєструвати неавторизованих виконавців. Будь-які аномалії слід розглядати як ознаки компрометації.

Запровадження багатофакторної автентифікації для всіх облікових записів розробників – із використанням методів, стійких до фішингу, де це можливо – це ще один невід’ємний крок. Він не усуває ризик, але підвищує планку для зловмисників, які намагаються зловживати кампаніями з крадіжки облікових даних.

Організації, що використовують передові платформи для пошуку загроз, також можуть використовувати спеціальні запити для пошуку відомих індикаторів, таких як виклики до певних webhook.site URL-адреси, наявність файлів, таких як shai-hulud-workflow.yml або підозріло великий bun_environment.js файли, написані на комп'ютерах розробників. Раннє виявлення за допомогою телеметрії може значно скоротити час витримки.

Як реагують постачальники: можливості виявлення та запобігання

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

Розширені сервіси пісочниці та аналізу шкідливих програм можуть позначати завуальовані корисні навантаження JavaScript, такі як ті, що використовуються в кампаніях Shai-Hulud. Коли ці інструменти виявляють підозрілі пост-інсталяційні або перед-інсталяційні скрипти, які намагаються виявити облікові дані або знищити файли, вони генерують сповіщення або блокують виконання.

Брандмауери наступного покоління з розширеним запобіганням загрозам та фільтрацією URL-адрес можуть допомогти, блокуючи доступ до шкідливих доменів, що використовуються для фішингу або крадіжки даних, – наприклад, фальшивих доменів підтримки npm або певних webhook.site кінцеві точки, жорстко закодовані у шкідливому програмному забезпеченні. Класифікація цих URL-адрес як шкідливих запобігає успішному надсиланню викрадених даних корисним навантаженням..

Агенти виявлення та реагування на кінцеві точки (EDR/XDR) сприяють моніторингу поведінки процесів, виконання скриптів, створення незвичайних файлів (наприклад, гігантських bun_environment.js файли) та підозрілі командні рядки. Вони можуть зупиняти як відомі хеші, так і раніше невидимі варіанти на основі правил поведінки.

Платформи безпеки хмарних застосунків все частіше додають функції, орієнтовані на ланцюг поставок, такі як видимість SBOM у режимі реального часу, оцінка ризиків для компонентів з відкритим кодом та перевірки неправильної конфігурації CI/CD (відсутні файли блокування, небезпечні npm install використання, залежності на основі Git без закріплених хешів комітів, невикористані залежності, що розширюють поверхню атаки). Ці засоби контролю ускладнюють проникнення шкідливих або неперевірених версій пакетів у виробничі збірки.

Практичні звички для розробників, які стурбовані шкідливими npm-пакетами

Якщо ви новачок у JS/TS і відчуваєте неспокій щоразу, коли встановлюєте npm-пакет, ви не самотні – але є конкретні звички, які ви можете застосувати, щоб знизити ризик, не заморожуючи свою продуктивність. Уявіть їх як особистий контрольний список безпеки.

По-перше, віддайте перевагу добре зарекомендували себе пакети з успішною історією обслуговування, активне відстеження проблем та широке використання, особливо для основної інфраструктури, такої як HTTP-клієнти, логування або криптовалюти. Це не гарантує безпеки, але зазвичай означає більше уваги приділяється коду та швидше виявлення, якщо щось піде не так.

Крихітні або маловідомі пакети (особливо ті, що майже не завантажуються) ретельніше перевірте: перевірте сторінку npm, посилання на репозиторії, дату останньої публікації та чи можна чітко ідентифікувати розробника. Будьте обережні, якщо пакет npm посилається на репозиторій GitHub, який насправді не містить опублікованого коду або все ще вказує на непов'язаний основний продукт.

По можливості перевіряйте опублікований tar-архів пакета, а не лише репозиторій з вихідним кодом, оскільки зловмисники можуть надіслати до npm збірку, яка відрізняється від тієї, що відображається на GitHub. Такі інструменти, як npm pack у поєднанні з ручною перевіркою (навіть якщо код транспілюється або мініфікується) може виявити очевидні тривожні сигнали, такі як дивні скрипти встановлення, обфусковані блоби або неочікувані мережеві виклики.

Для бібліотек TypeScript, які постачають лише визначення типів та мінімізований JavaScript, важче провести швидкий ручний аудит, тому ви можете вирішити використовувати їх лише за суворою «пісочницею» або ж розгалужувати та перебудовувати з вихідного коду, якщо вони стають критично важливими для вашого стеку. У деяких контекстах, чутливих до безпеки, команди справді вирішують розгалужувати залежності до приватних реєстрів після ретельного перегляду.

Зробіть безпеку npm рутиною, а не пожежною інструкцією: запустіть npm audit Регулярно очищайте невикористовувані залежності, зберігайте файли блокування зафіксованими та інтегруйте перевірки SCA/SAST у ваш CI/CD. У поєднанні з надійною гігієною облікових записів та управлінням секретами ці практики не роблять вас невразливими, але вони суттєво зменшують ймовірність того, що випадкове встановлення npm непомітно скомпрометує ваші системи.