Помʼякшення наслідків атак на ланцюги постачання
Іноді пакунки npm можуть бути скомпрометовані та опубліковані разом із шкідливим програмним забезпеченням. На щастя, є такі компанії, як Socket, Snyk та Aikido, які виявляють ці скомпрометовані пакунки на ранній стадії. Реєстр npm зазвичай видаляє уражені версії протягом кількох годин. Однак між моментом публікації шкідливого програмного забезпечення та його виявленням завжди є певний проміжок часу, протягом якого ви можете бути вразливими. На щастя, є кілька речей, які ви можете зробити за допомогою pnpm, щоб мінімізувати ризики.
Block risky postinstall scripts
Історично більшість скомпрометованих пакунків використовували скрипти postinstall для запуску коду одразу після встановлення. Щоб зменшити це, pnpm v10 вимикає автоматичне виконання скриптів postinstall у залежностях. Хоча існує налаштування для їх повторного глобального увімкнення за допомогою dangerouslyAllowAllBuilds, ми рекомендуємо явно вказувати лише надійні залежності. Таким чином, якщо залежність не потребувала збірки в минулому, вона не запустить шкідливий скрипт раптово, якщо буде опубліковано скомпрометовану версію. Однак, ми рекомендуємо бути обережними під час оновлення надійного пакунка, який містить скрипт postinstall, оскільки його може бути скомпрометовано.
Delay dependency updates
Ще один спосіб зменшити ризик встановлення скомпрометованих пакунків — це відкласти оновлення ваших залежностей. Оскільки шкідливе програмне забезпечення зазвичай виявляється швидко, відстрочка оновлення на 24 години, швидше за все, допоможе вам уникнути встановлення шкідливої версії. Параметр minimumReleaseAge визначає мінімальну кількість хвилин, яка повинна пройти після публікації версії, перш ніж pnpm встановить її. Наприклад, встановіть значення 1440, щоб чекати один день, або 10080, щоб чекати один тиждень перед встановленням нової версії.
Enforce trust with trustPolicy
To further protect your supply chain, pnpm also supports a trustPolicy setting. When set to no-downgrade, this setting will prevent installation of a package if its trust level has decreased compared to previous releases (for example, if it was previously published by a trusted publisher but now only has provenance or no trust evidence). This helps you avoid installing potentially compromised or less trustworthy versions.
If you need to allow specific packages or versions to bypass the trust policy check, you can use the trustPolicyExclude setting. This is useful for known packages that may not meet the trust requirements but are still safe to use.
Use a lockfile
Само собою зрозуміло, що ви завжди повинні фіксувати свої залежності за допомогою файлу блокування. Додайте файл блокування до свого репозиторію, щоб уникнути несподіваних оновлень.