Само два од 25 менаџери на пакети ја провериле секоја зависност

На 14 октомври 2026 година, истражувањето на Trail of Bits покажа дека само Go и vcpkg, од 25 испитани менаџери на пакети, го провериле интегритетот на секоја преземена зависност во тестираните стандардни поставки. За CI изградба, пресудно е дали алатката ја споредува содржината на преземениот пакет со претходно доверлива вредност и ја прекинува инсталацијата при несовпаѓање.

Прегледот на Andrew Nesbitt ја издвојува разликата меѓу проверка без lockfile и проверка што зависи од проектна поставка: Go и vcpkg ги провериле сите преземања и без таква датотека, а Go бил единствениот што стандардно проверувал потписи. Кај другите испитани алатки, lockfile може да помогне само ако содржи соодветни контролни суми и ако командата навистина ги спроведува.

Каков напад симулирал тестот

Истражувачот Keegan Ryan испитувал дали менаџерот ќе прифати изменет код испорачан под името и верзијата на легитимен пакет. Околината користела Docker, WireGuard и mitmproxy за да го измени одговорот што клиентот го добива од репозиториумот. Приватните клучеви за потпишување останале надвор од контролата на симулираниот напаѓач.

Патеките биле испитани со популарен јавен пакет, по една верзија на менаџерот и на една платформа, со и без lockfile каде што тоа имало смисла. Командите биле извршени со стандардни опции. Затоа резултатот опишува конкретни конфигурации и закана од компромитиран извор на преземање; приватен репозиториум, друга платформа или поинакви поставки може да дадат друг исход.

Која поставка го запира изменетиот пакет во CI

Очекуваниот хеш мора да постои пред CI да го преземе пакетот од изворот што може да биде изменет. Ако истата инсталација прво го запише новиот хеш или го обнови lockfile по несовпаѓање, споредбата не го блокира нападот од експериментот. Разликите меѓу екосистемите се следниве:

• Go и vcpkg: Во испитаните стандардни поставки не бил потребен проектен lockfile. Go ја споредува содржината на јавните модули со својата база на контролни суми; vcpkg ги користи хешовите вклучени во податоците за пакетите што ги дистрибуира менаџерот. CI треба да ги задржи тие доверливи механизми, особено кога проектот користи приватни извори или изменета конфигурација.
• npm: Зачувајте го package-lock.json со проектот и инсталирајте со „npm ci“. Датотеката носи вредности за интегритет на преземените архиви, а командата бара постоечки lockfile и не го препишува ако зависностите во package.json не се совпаѓаат со него. „npm audit signatures“ е посебна проверка на потписи, а не дел од обичната инсталација.
• Bun, pnpm, Yarn, Bundler, Cargo, Poetry, uv и SwiftPM: Во испитаните патеки соодветен lockfile со зачувани хешови овозможил откривање на изменет пакет. Во CI датотеката треба да доаѓа од верзиската контрола, наместо првпат да се создава при изградбата. Тоа важи за преземањата што алатката ги опфаќа со тие хешови; самото заклучување на верзијата не е доказ за проверка на содржината.
• Pip: Обичен requirements.txt со заклучени верзии не е доволен. Документацијата на Pip бара локално запишани хешови за сите директни и посредни зависности во режимот „--require-hashes“. Во CI употребете „python -m pip install --require-hashes -r requirements.txt“, со точно одредени верзии и хешови за секоја дозволена архивска варијанта. Без хеш за некоја зависност, овој режим ја прекинува инсталацијата.
• Gradle: gradle.lockfile ги задржува верзиите, но не ги содржи потребните хешови на преземените артефакти. За нив е потребна gradle/verification-metadata.xml; почетна датотека може да се создаде со „./gradlew --write-verification-metadata sha256“, да се провери и да се зачува со проектот. Создавањето од веќе изменет извор би го запишало погрешниот хеш како очекуван. Во CI проверката треба да остане во режим што ја прекинува изградбата при грешка.
• NuGet: За проекти со PackageReference, вклучете RestorePackagesWithLockFile, зачувајте го packages.lock.json и користете „dotnet restore --locked-mode“. Датотеката содржи хеш на пакетот, а заклучениот режим не дозволува тивко обновување на разрешените зависности. Не комбинирајте го со „--force-evaluate“, кој може да го обнови lockfile наместо да ја зачува очекуваната состојба.
• Pub за Dart и Flutter: pubspec.lock содржи хеш, но во испитаната вообичаена инсталација Pub го пријавил несовпаѓањето, го инсталирал пакетот и го обновил хешот. Во CI е потребно „dart pub get --enforce-lockfile“ или соодветната команда „flutter pub get --enforce-lockfile“ за инсталацијата да запре при разлика.
• Conda: Во испитаната категорија била потребна дополнителна алатка за lockfile. conda-lock може однапред да создаде датотека за целната платформа, која потоа се зачувува и се употребува при инсталацијата во CI. Генерирањето нов lockfile за време на истата изградба не обезбедува претходно доверлива вредност за споредба.

Кога lockfile не ја проверува содржината

Composer покажува зошто референца до изворен код не е исто што и проверен преземен архив. Во испитаниот пример composer.lock содржел хеш на Git commit, но преземениот ZIP не го содржел Git дрвото потребно за Composer да ја потврди таа референца. Затоа „composer install“ со непроменет lockfile не би открил изменет ZIP испорачан од компромитираниот извор.

Кај Conan, ревизијата во lockfile служи како идентификатор на рецепт, но неговиот хеш не се пресметува повторно при инсталацијата. Кај CocoaPods, контролната сума се однесува на описот на пакетот, додека изворниот код се презема од Git. Gem има lockfile без хешови за оваа проверка, а Maven и неколку други испитани алатки немале посебен lockfile што би ја извршил во тестираната патека.

Потписите се одвоен механизам со сопствени поставки. На пример, задолжителната проверка на потписи во NuGet бара режим „require“ и доверливи потписници во nuget.config; заклучениот restore сам по себе не ја воспоставува таа политика. За тимот што ја оценува следната CI изградба, одлучувачкиот доказ е конкретната инсталација да запре кога преземената содржина не се совпаѓа со претходно доверливиот хеш.

Прочитајте и:

• Разговорот со AI-лик не е дневник: што да проверите пред да се доверите
• Финансиските тимови трошат 26% од неделата проверувајќи AI
• Бришењето на My Activity не го чисти прелистувачот: потребни се два чекора