npm пакет може проћи audit, а ипак бити ризичан — проверите и порекло

|Аутор: Уредништво QUASA|5 мин читања
npm пакет може проћи audit, а ипак бити ризичан — проверите и порекло

Пре него што прихватите npm пакет у пројекат или CI, изаберите тачну верзију, припремите закључано стабло зависности и одвојено проверите рањивости, интегритет, порекло и садржај архиве. Према npm документацији за audit, команда npm audit тражи познате рањивости у зависностима, док npm audit signatures проверава потписе регистра и доступне потврде о пореклу преузетих пакета. Успешан audit зато није доказ да у пакету нема злонамерног кода.

Поступак спроведите у издвојеној копији пројекта, без приступа пројектним тајнама. Све резултате вежите за исту верзију и исто стабло зависности: ако се касније промени директна или посредна зависност, мења се и предмет одлуке.

Закључајте верзију и прегледајте стабло

Закључана верзија npm пакета повезана је са записима resolved и integrity у датотеци package-lock.json.

Проверите пуно име пакета, укључујући опсег ако га има, и одредите конкретну верзију. У копији постојећег пројекта команда npm install --package-lock-only --save-exact --ignore-scripts naziv-paketa@verzija припрема измену манифеста и датотеке package-lock.json без постављања зависности у node_modules и без покретања инсталационих скрипти. Ознаку naziv-paketa@verzija замените стварним именом и верзијом кандидата.

Пре осталих провера погледајте разлику у package-lock.json. Нови унос може да уведе више посредних пакета него што се види из једне ставке у package.json; за сваки важан унос проверите верзију и поље resolved, које показује одакле се пакет преузима. Поље integrity служи за проверу да ли преузети садржај одговара записаној вредности. Ако је штетна архива већ прихваћена у закључану датотеку, подударање са том вредношћу не говори да је њен код безбедан.

Шта налаз команде npm audit заиста значи

Покрените npm audit над припремљеном закључаном датотеком и за сваки налаз утврдите који га пакет уводи и да ли је захваћена баш верзија коју намеравате да прихватите. Предлог исправке проверите у контексту целог стабла: промена посредне зависности може да захтева и промену верзије директног пакета. Неки налази траже ручну одлуку јер аутоматска исправка није доступна.

Излаз npm audit --json може да помогне CI процесу да забележи налазе, а праг неуспеха треба подесити према политици пројекта. Нулти излазни статус значи да команда није нашла познату рањивост у посматраном стаблу; не проверава намеру аутора кода нити сва могућа понашања пакета. Током процене кандидата не покрећите npm audit fix без прегледа предложене промене: он може да измени закључане верзије, после чега audit треба поновити.

Одвојите интегритет од порекла објаве

За проверу преузетих пакета у издвојеној копији покрените npm ci --ignore-scripts, па npm audit signatures. npm ci користи припремљену закључану датотеку и одбија неслагање са манифестом, док опција --ignore-scripts спречава извршавање скрипти из пакета током тог постављања. Проверите исход команде за потписе и користите ажуран npm CLI, јер одсуство команде није успешна провера.

Потпис регистра повезује податке о објављеној верзији са интегритетом пакета. Потврда о пореклу, када је објављена, даје проверљиву везу са изворним репозиторијумом и поступком изградње. Упоредите наведени репозиторијум и изворну измену са пројектом који сте намеравали да користите. Одсуство потврде и неуспела провера потписа различити су исходи; проверено порекло показује одакле је пакет дошао, али само по себи не оцењује безбедност његовог кода.

Процените праксу репозиторијума

OpenSSF Scorecard процењује праксу репозиторијума, док објављена npm архива остаје засебан предмет провере.

Репозиторијум наведен уз пакет проверите као засебан предмет процене. OpenSSF Scorecard низом аутоматизованих провера процењује безбедносне праксе пројекта, а његов CLI може да анализира и туђи репозиторијум. Погледајте појединачне налазе и њихова објашњења: збирна оцена не показује која пракса је важна за зависност коју разматрате.

Резултат за репозиторијум односи се на праксу пројекта, док се одлука о прихватању односи на конкретну објављену архиву. Ако метаподаци пакета воде ка другом пројекту од оног који сте очекивали, или се изворна измена из потврде о пореклу не може повезати са објављеном верзијом, задржите пакет ван пројекта док не утврдите разлог. Добра пракса одржавања смањује неке ризике, али не замењује преглед самог издања.

Прегледајте објављену архиву

Преглед архиве npm пакета открива ставку postinstall у манифесту package.json пре одобравања зависности.

Пре одобрења погледајте метаподатке командама npm view naziv-paketa@verzija scripts и npm view naziv-paketa@verzija repository. Затим у издвојеном окружењу преузмите кандидата командом npm pack --ignore-scripts naziv-paketa@verzija и отворите добијену архиву без извршавања њеног садржаја. Проверите стварни package.json у архиви: метаподаци су полазиште, а објављене датотеке су оно што ће пројекат добити.

Посебно испитајте скрипте preinstall, install и postinstall, програме које позивају, мрежне захтеве и приступ променљивама окружења. Прегледајте и датотеке које ће апликација учитати при увозу пакета, јер штетно понашање може да се активира тек током рада апликације. Ако је кандидат ново издање већ коришћене зависности, разлика у садржају архиве помаже да уочите скрипте и извршни код који су се појавили у тој верзији.

Аутори упоредне студије детектора npm пакета испитали су 11 алата на скупу од 6.420 злонамерних и 7.288 бенигних пакета; налази показују да успех детекције зависи од понашања које алат препознаје и начина на који пакет избегава откривање. Зато аутоматски сигнал може да усмери ручни преглед, али чист резултат једног алата није основ за прескакање архиве.

Донесите одлуку за конкретно издање

Забележите пуно име и верзију кандидата, промену закључаног стабла, отворене audit налазе, исход провере потписа и порекла, релевантне налазе за репозиторијум и скрипте или код које сте прегледали у архиви. Ако скрипта тражи приступ који не можете да објасните или порекло објављене верзије остаје нејасно, одложите прихватање и затражите објашњење од одржавалаца или изаберите другу зависност.

Када верзија буде одобрена, CI треба да поставља зависности из одобрене закључане датотеке. При следећем ажурирању поновите процену над новим стаблом: нова посредна зависност, нова скрипта или промењено порекло објаве могу да промене одлуку и када име директног пакета остаје исто.

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

Подели:

Претплатите се на наш билтен

Добијајте најновије вести о Web3, AI-у и криптовалутама директно у пријемно сандуче.

0