Lt; DR
Npm paketo pažeidžiamumų paieška yra paprasta. npm audit padaro tai per keturias sekundes ir įteikia jums 400 radinių. Sunkiausia dalis yra kiti du klausimai: kurį iš jų iš tikrųjų galima pasiekti jūsų programoje ir kuris atnaujinimas išsprendžia problemą nesugadindamas kompiliavimo.
- Didžioji dalis sąrašo nėra jūsų problema. Taikant pasiekiamumo ir vykdymo laiko kontekstą „kritiniams“ radiniams, nedidelė jų dalis vis dar lieka kritinė. Kurie iš jų yra kritiniai, parodo skambučių grafų analizė.
npm audit fix --forcenėra taisymo strategija. Jis išsprendžia įspėjimus peršokdamas pagrindines versijas, taip saugumo užduotis tampa sutrikimu.- Tranzityviosios priklausomybės yra ta vieta, kur gyvena tomas. Jūs jų nepasirinkote, dažnai negalite jų tiesiogiai patobulinti, ir jie dominuoja radinių skaičiuje.
- Ištaisyti prieš sujungimą, o ne po išleidimo. Vartai CI ir automatizuota pull request kainuoja minutes. Gamybos pataisymas kainuoja savaitgalį.
Kodėl radinių skaičius nėra problema
Kiekvienas „Node“ projektas, pasibaigęs pirmaisiais savo gyvavimo metais, sukuria tą pačią patirtį. Atliekant nuskaitymą, randami šimtai npm paketų pažeidžiamumų, o sąrašas tampa toks didelis, kad racionalus atsakas būtų uždaryti terminalą.
Ši reakcija teisinga, ir tai yra nemaloniausia dalis. Beveik trys ketvirtadaliai kodų bazių turi didelės rizikos atvirojo kodo komponentus, ir dauguma to, ką skaitytuvas praneša bet kurią dieną, iš tikrųjų yra jūsų priklausomybių medyje. Sąrašas yra tikslus. Tai tiesiog nėra darbo eilė.
Skirtumas tarp tikslaus ir įgyvendinamo sąrašo priklauso nuo konteksto, ir jis priklauso nuo kelių klausimų.
- Ar pažeidžiamas kodas iš tikrųjų pasiekiamas iš mano programos?
- Ar kas nors tai išnaudoja gamtoje?
- Ar tai, kam tai daro įtaką, yra svarbu verslui?
Skaitytuvas, kuris negali atsakyti į tuos klausimus, įteikia jums inventorių ir vadina jį ataskaita.
Kaip patikrinti npm paketų pažeidžiamumus
Yra keturi praktiniai būdai, kaip patikrinti npm paketų pažeidžiamumus, ir jie atsako į skirtingus klausimus.
Pradėti npm audit nes tai nieko nekainuoja ir trunka kelias sekundes. Nesustokite ties tuo, nes atsakymas yra „čia yra viskas“, o ne viskas yra planas.
Vienas dalykas, kurį verta žinoti, jei pasitikite patarimų srautais: „GitHub“ patarimų duomenų bazėje yra patarimų apie kenkėjiškas programas, skirtų npm ekosistemai, tačiau „Dependabot“ sąmoningai nesiunčia įspėjimų apie juos, nes tolesnis vartotojas paprastai negali jų išspręsti atnaujindamas versiją. Tai struktūrinė spraga, o ne nustatymas, kurį galite įjungti. Kenkėjiškiems paketams reikalinga kitokia kontrolė: aptikimas publikavimo metu, o ne po atskleidimo. „Xygeni“... Kenkėjiškų programų ankstyvas įspėjimas analizuoja naujai publikuotus paketus npm, PyPI, Maven ir kituose registruose jų atsiradimo momentu, naudodamas elgsenos ir anomalijų analizę, o ne laukdamas parašo, ir tai įtraukta į nemokamą kūrėjo planą. Mes tai aptariame toliau tyčinis npm paketai.
Filtrai, kurie 400 radinių paverčia trumpu sąrašu
Tai yra ta dalis, kuri keičia komandos darbo būdą.
| Filtruoti | Klausimas, į kurį atsako | Kas paprastai pašalinama |
|---|---|---|
| Pasiekiamumas | Ar mano programos vykdymas gali pasiekti pažeidžiamą funkciją? | Didžiausias sumažinimas. Dauguma patarimų yra kode, kurio programa niekada iškviečia. |
| Išnaudoti prieinamumą | Ar egzistuoja veikianti vieša spraga ir ar ji šiuo metu išnaudojama natūraliai? | Atskiria teorinę riziką nuo ginkluoto pavojaus. Radinys, turintis viešą pažeidžiamumo spragą, pralenkia eilę, kad ir koks būtų jo pavojingumo balas. |
| Išnaudojimo tikimybė (EPSS) | Kokia tikimybė, kad per ateinančias 30 dienų laukinėje gamtoje bus vykdomas išteklių naudojimas? | Labai svarbūs radiniai, kuriais niekas nepasinaudoja ir kurie šią savaitę retai pasitaiko darbe |
| Verslo kontekstas | Ar paveikta paslauga yra svarbi ir ar ji yra pažeidžiama? | Pasiekiami, panaudojami radiniai sistemose, kurios nekelia reikšmingos rizikos |
| Pataisyti prieinamumą | Ar yra versija, kuri išspręstų šią problemą manęs nesulaužydama? | Atskiria tai, ką galite uždaryti šiandien, nuo to, kam reikia laikino sprendimo |
- Pasiekiamumas yra pirmasis ir didžiausias trūkumas. Paketo, nuo kurio priklausote, pažeidžiamumą galima išnaudoti tik tuo atveju, jei vykdymas iš tikrųjų gali pasiekti pažeidžiamą funkciją. Iškvietimų grafų sekimas atsako į tai funkcijos lygmeniu, o ne spėlioja iš manifesto, ir tai atskiria komponentus, kuriuos iš tikrųjų naudojate, nuo tų, kurie tiesiog yra. „Xygeni“ pasiekiamumo analizė sumažina klaidingus teigiamus rezultatus iki 70 %.
Išnaudoti prieinamumą yra antrasis, ir tai yra faktas, o ne prognozė. Veikiantis viešas pažeidžiamumo išnaudojimas arba patvirtintas išnaudojimas gamtoje pakeičia radinio prioritetą, neatsižvelgiant į tai, ką rodo jo pavojingumo balas. Šis skirtumas nustojo būti gera praktika ir tapo įpareigojimu: pagal Kibernetinio atsparumo įstatymą gamintojas, sužinojęs apie aktyviai išnaudotą savo produkto pažeidžiamumą, praneša apie jį 24 valandų laikrodyje. Programa, kuri negali atskirti „aktyviai išnaudotų“ nuo „aukšto CVSS“, negali laikytis šio laiko.
Trečias klausimas – išnaudojimo tikimybė, ir tai tas pats klausimas, tik įvedus prognozę. EPSS įvertina tikimybę, kad pažeidžiamumas bus išnaudotas per ateinančias 30 dienų, o tai labai skiriasi nuo klausimo, koks būtų pavojus, jei taip būtų. Aukštas CVSS balas su nereikšmingu EPSS balu šią savaitę retai kada būna sėkmingas.
- Verslo kontekstas yra trečias, ir tai yra tas, kurio negali pateikti joks bendras informacijos srautas. Pasiekiama, išnaudojama pažeidžiamumas internetinėje mokėjimo paslaugoje nėra tas pats radinys, kaip ta pati CVE vidinėje ataskaitų teikimo priemonėje.
Taikant kartu, šie filtrai įprastai paverčia sąrašą, kurio niekas neskaito, sąrašu, kurį kažkas užbaigia. Veikimo laikas ir pasiekiamumo kontekstas paprastai palieka tik nedidelę dalį „kritinių“ radinių vis dar svarbius. „Xygeni“ pasiekiamumą, išnaudojimo prieinamumą, EPSS ir verslo kontekstą traktuoja kaip konfigūruojamus prioritetų nustatymo piltuvo etapus, kurių gali būti iki aštuonių, todėl „pasiekiamas ir aktyviai išnaudojamas“ tampa nuolatine eile, o ne užklausa, kurią kažkas atlieka rankiniu būdu.
Npm paketo pažeidžiamumų taisymas nepažeidžiant versijos
Rasti yra lengva pusė. Npm paketų pažeidžiamumai mėnesių mėnesiais lieka neišspręsti todėl, kad jų taisymas yra rizikingas, ir kūrėjai tai žino.
Prieš bet kokį atnaujinimą svarbus klausimas yra ne „ar šis pataisymas ištaiso CVE“. Tai trys klausimai vienu metu: kurie pažeidžiamumai išnyksta su šia versija, kokie nauji atsiranda kartu su ja ir ar versijos šuolis nesugadina mano kodo.
Ksigeni rodo visus tris kiekvienai pažeidžiamai priklausomybei, todėl pasirinkimas yra tarp matomų parinkčių, o ne šuolis. Tada „Autofix“ sugeneruoja pull request Naudojant pataisytą versiją, masinis taisymas vienu veiksmu pritaiko kelias pataisas, o „Xygeni Bot“ veikia pagal poreikį. pull requests arba kasdien, todėl darbų sąrašas mažėja niekam to neplanuojant.
Tranzityvinių priklausomybių atveju, kai negalite tiesiog atnaujinti nepasirinktos versijos, naudinga išvestis yra trumpiausias atnaujinimo kelias medyje, kuris išsprendžia įspėjimą, o ne įspėjimas, rodantis, kad keturiais lygiais žemesnis paketas yra pažeidžiamas.
Prieš išsiunčiant: kur priklauso čekis
„Prieš išsiunčiant“ yra planavimo teiginys, ir jis susiveda į tris vietas.
- IDE aplinkoje, taigi kūrėjas mato problemą rinkdamasis priklausomybę, kuri yra pigiausias momentas ją pakeisti.
- Dėl pull request, kur robotas pakomentuoja, kas pasikeitė, ir atidaro pataisą, ir kur apsaugos vartai gali nepavykti sukurti versijos, jei radiniai viršija ribą. Vien tik svarbos apribojimas verčia komandas išjungti apsaugos vartus. Apsauga nuo pasiekiamų ir išnaudojamų radinių verčia jas juos pasilikti.
- Nuolat po išleidimo, nes priklausomybė, kuri sujungimo metu buvo švari, tampa pažeidžiama tą dieną, kai paskelbiamas įspėjimas. Nuolatinis registrų stebėjimas tai aptinka, niekam nereikės prisiminti apie pakartotinį nuskaitymą.
Ir visų trijų išvestis priklauso vienai prioritetinei eilei kartu su jūsų SAST, paslaptysir konteinerių radiniai, įskaitant tuos, kurie buvo priimti iš jau naudojamų įrankių. A pažeidžiamumų sąrašas kuris yra savo konsolėje, yra sąrašas, konkuruojantis dėl dėmesio su darbu, kurį jis turėjo informuoti.
Siųskite pataisą, o ne radinį
Skeneris, rodantis 400 npm paketų pažeidžiamumus, darbo neatliko. Jis darbą perkėlė į kitą pusę.
„Xygeni“ susiaurina priklausomybių radinius pagal pasiekiamumą, išnaudojimo tikimybę ir verslo kontekstą, parodo, ką kiekvienas atnaujinimas ištaiso ir ką jis gali sugadinti, ir atidaro pull request su pataisyta versija. Ji veikia jūsų pipeline, gamina SBOM ir VDR išvestį SPDX ir CycloneDX programose, įrodymus, kurių prašo CRA, NIS2 ir DORA, ir priklausomybės išvadas įtraukia į tą pačią prioritetinę eilę kaip ir likusią jūsų rizikos dalį, įskaitant išvadas iš skaitytuvų, kurių nekeičiate.
Pradėkite nemokamai ir nuskaityti saugyklą arba pažiūrėkite, kaip pasiekiamumas keičia sąrašą.
DUK
Kaip patikrinti npm paketus dėl pažeidžiamumų?
paleisti npm audit Norėdami gauti momentinę peržiūrą, naudokite įrankį su pasiekiamumo analize, kad susiaurintumėte sąrašą iki radinių, kuriuose pažeidžiamą kodą iš tikrųjų galima iškviesti. Konsultacinės duomenų bazės, tokios kaip OSV ir „GitHub“ konsultacijų duomenų bazė, yra naudingos norint patikrinti konkretų paketą ir versiją.
Is npm audit fix saugu bėgioti?
Neforsuota versija paprastai yra saugi, nes ji neviršija su „Semver“ suderinamų diapazonų. npm audit fix --force nėra: jis atnaujinamas pagrindinėse versijose, kad išspręstų įspėjimus, ir iš čia atsiranda esminiai pakeitimai.
Kodėl turiu tiek daug npm paketo pažeidžiamumų?
Nes dauguma jų yra tranzityvios. Įdiegiate keletą tiesioginių priklausomybių ir paveldite šimtus netiesioginių, kiekviena su savo patariamąja istorija. Apimtis yra normalu. Trūksta triažo.
Kas yra pasiekiamumo analizė?
Nustatyti, ar jūsų programos vykdymas iš tikrųjų gali pasiekti pažeidžiamą funkciją priklausomybėje. Tai didžiausias triukšmo mažinimas, galimas priklausomybių saugumo srityje, nes dauguma praneštų pažeidžiamumų yra kode, kurio jūsų programa niekada iškviečia.
Ar turėčiau naudoti CVSS ar EPSS prioritetų nustatymui?
Abu, skirti skirtingiems dalykams. CVSS apibūdina, koks sunkus būtų pažeidžiamumas, jei juo būtų pasinaudota. EPSS įvertina, kokia yra išnaudojimo tikimybė per ateinančias 30 dienų. Sunkumas be tikimybės sukuria eilę, surūšiuotą pagal neteisingą ašį.
Kaip dažnai turėčiau tikrinti npm paketus dėl pažeidžiamumų?
Nuolat, o ne pagal grafiką. Pirmadienį atliktas švarus nuskaitymas trečiadienį nieko nereiškia, jei apie jau išsiųstą siuntinį gaunamas pranešimas.
