Помʼякшення наслідків атак на ланцюги постачання

Іноді пакунки npm можуть бути скомпрометовані та опубліковані разом із шкідливим програмним забезпеченням. Luckily, there are companies like Socket, Snyk, Xygeni and Aikido that detect these compromised packages early. Реєстр npm зазвичай видаляє уражені версії протягом кількох годин. Однак між моментом публікації шкідливого програмного забезпечення та його виявленням завжди є певний проміжок часу, протягом якого ви можете бути вразливими. На щастя, є кілька речей, які ви можете зробити за допомогою pnpm, щоб мінімізувати ризики.

Block risky postinstall scripts#

Історично більшість скомпрометованих пакунків використовували скрипти postinstall для запуску коду одразу після встановлення. To mitigate this, pnpm does not run the build scripts of dependencies unless they are allowed in allowBuilds. With strictDepBuilds (on by default), an install fails if a dependency has a build script that is not allowed. Хоча існує налаштування для їх повторного глобального увімкнення за допомогою dangerouslyAllowAllBuilds, ми рекомендуємо явно вказувати лише надійні залежності за допомогою allowBuilds. Таким чином, якщо залежність не потребувала збірки в минулому, вона не запустить шкідливий скрипт раптово, якщо буде опубліковано скомпрометовану версію. Однак, ми рекомендуємо бути обережними під час оновлення надійного пакунка, який містить скрипт postinstall, оскільки його може бути скомпрометовано.

Запобігання екзотичним перехідним залежностям#

You can prevent transitive dependencies from using exotic sources (like git repositories or direct tarball URLs) with blockExoticSubdeps, which is on by default. Це гарантує, що всі перехідні залежності отримуються з надійних джерел, що зменшує ризик атак на ланцюжок постачання.

Затримка оновлень залежностей#

Ще один спосіб зменшити ризик встановлення скомпрометованих пакунків — це відкласти оновлення ваших залежностей. Оскільки шкідливе програмне забезпечення зазвичай виявляється швидко, відстрочка оновлення на 24 години, швидше за все, допоможе вам уникнути встановлення шкідливої версії. Параметр minimumReleaseAge визначає мінімальну кількість хвилин, яка повинна пройти після публікації версії, перш ніж pnpm встановить її. У pnpm v11 стандартом є значення 1440 (1 день), тобто новоопубліковані пакунки не будуть оброблятися, доки їм не виповниться принаймні 1 день. Щоб відмовитися від цього, встановіть значення minimumReleaseAge: 0 у файлі pnpm-workspace.yaml. Ви також можете встановити значення 10080, щоб зачекати один тиждень перед встановленням нової версії.

Забезпечення довіри за допомогою trustPolicy#

Для додаткового захисту вашого ланцюга постачання pnpm також підтримує налаштування trustPolicy. При встановленні значення no-downgrade цей параметр запобігатиме встановленню пакунка, якщо його рівень довіри знизився порівняно з попередніми версіями (наприклад, якщо раніше він був опублікований надійним видавцем, а зараз має лише інформацію про походження або не має доказів надійності). Це допоможе вам уникнути встановлення потенційно небезпечних або менш надійних версій.

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

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

Використовуйте файл блокування#

Always lock your dependencies with a lockfile. Додайте файл блокування до свого репозиторію, щоб уникнути несподіваних оновлень.

If you scan pnpm-lock.yaml with a vulnerability scanner or an SBOM generator, check that it handles the two-document lockfile: a tool that reads only the first document reports that the project has no dependencies, and no vulnerabilities, without failing.

Pin dependencies to the registry they come from#

If you install from more than one registry, use namedRegistries aliases for the packages that must come from a specific one. Since v11.20.0, pnpm records those packages in the lockfile under registry-qualified keys (<name>@<registryName>:<version>), so a package cannot be quietly substituted by another registry that publishes the same name and version. See Named registries in the lockfile. Packages installed without an alias are resolved through the default registries configuration as before.