TL; DR
Trobar vulnerabilitats de paquets npm és fàcil. npm audit ho fa en quatre segons i et dóna 400 troballes. La part difícil són les dues preguntes següents: a quina d'elles es pot accedir realment a la vostra aplicació i quina actualització soluciona el problema sense trencar la compilació.
- La major part de la llista no és problema teu. Aplicar l'accessibilitat i el context d'execució a les troballes "crítiques" deixa una petita fracció encara crítica. L'anàlisi de grafs de crides és el que indica quines són.
npm audit fix --forceno és una estratègia de correcció. Resol els avisos saltant les versions principals, que és com una tasca de seguretat es converteix en una interrupció.- Les dependències transitives són on resideix el volum. No els has triat, sovint no els pots millorar directament i dominen el recompte de troballes.
- Corregiu-ho abans de la fusió, no després del llançament. Una porta a CI i una automatitzada pull request costa minuts. Un pegat de producció costa un cap de setmana.
Per què el recompte de troballes no és el problema
Cada projecte de Node després del seu primer any produeix la mateixa experiència. Executeu una exploració, obteniu centenars de vulnerabilitats de paquets npm i la llista és tan gran que la resposta racional és tancar el terminal.
Aquesta reacció és correcta, que és la part incòmoda. Gairebé tres quartes parts de les bases de codi contenen components de codi obert d'alt risc, i la major part del que informa un escàner en un dia determinat es troba realment al vostre arbre de dependències. La llista és precisa. Simplement no és una cua de treball.
La diferència entre una llista precisa i una de pràctica és el context, i es redueix a un grapat de preguntes.
- És realment accessible el codi vulnerable des de la meva aplicació?
- Algú està explotant això en estat salvatge?
- Allò que afecta, importa per al negoci?
Un escàner que no pot respondre a aquestes mans et fa un inventari i ho anomena informe.
Com comprovar si hi ha vulnerabilitats als paquets npm
Hi ha quatre maneres pràctiques de comprovar si hi ha vulnerabilitats als paquets npm, i responen a preguntes diferents.
Començar amb npm audit perquè no costa res i triga segons. No us atureu aquí, perquè la resposta que us dóna és "aquí ho teniu tot", i tot no és un pla.
Una cosa que val la pena saber si confieu en els canals d'assessorament: la base de dades d'assessorament de GitHub conté avisos de programari maliciós per a l'ecosistema npm, però Dependabot deliberadament no genera alertes per a ells, perquè un usuari posterior normalment no els pot resoldre actualitzant. Això és una bretxa estructural, no una configuració que es pugui activar. Els paquets maliciosos necessiten un control diferent: detecció en el moment de la publicació en lloc de després de la divulgació. Xygeni's Alerta precoç de programari maliciós analitza els paquets recentment publicats a npm, PyPI, Maven i altres registres en el moment en què apareixen, utilitzant anàlisi de comportament i anomalies en lloc d'esperar una signatura, i està inclòs en el pla gratuït per a desenvolupadors. Ho cobrim a maliciós paquets npm.
Els filtres que converteixen 400 troballes en una llista curta
Aquesta és la part que canvia la manera com funciona un equip.
| filtre | La pregunta que respon | El que normalment elimina |
|---|---|---|
| Accessibilitat | Pot l'execució de la meva aplicació arribar realment a la funció vulnerable? | La retallada més gran. La majoria dels avisos es troben en codi que l'aplicació mai crida. |
| Disponibilitat d'explotació | Existeix alguna vulnerabilitat pública que funcioni, i s'està explotant actualment? | Separa el risc teòric del risc armat. Una troballa amb una vulnerabilitat pública salta la cua independentment de la seva puntuació de gravetat. |
| Probabilitat d'explotació (EPSS) | Quina probabilitat hi ha d'explotació en estat salvatge en els propers 30 dies? | Troballes d'alta gravetat que ningú està explotant, que rarament són feina d'aquesta setmana |
| Context empresarial | El servei afectat és important i està exposat? | Troballes accessibles i explotables en sistemes que no comporten cap risc significatiu |
| Correcció de la disponibilitat | Hi ha alguna versió que solucioni això sense fer-me malbé? | Separa el que pots tancar avui del que necessita una solució alternativa |
- Accessibilitat és el primer i més gran tall. Una vulnerabilitat en un paquet del qual depeneu només es pot explotar si l'execució pot arribar realment a la funció vulnerable. El rastreig de grafs de crides respon a això a nivell de funció en lloc d'endevinar a partir del manifest, i distingeix els components que realment utilitzeu dels que simplement hi són presents. L'anàlisi d'accessibilitat de Xygeni redueix els falsos positius fins a un 70%.
Disponibilitat d'explotació és el segon, i és un fet més que no pas una previsió. Una explotació pública que funciona, o una explotació confirmada en estat salvatge, canvia la prioritat d'una troballa independentment del que digui la seva puntuació de gravetat. Aquesta distinció ha deixat de ser una bona pràctica i s'ha convertit en una obligació: segons la Llei de Ciberresiliència, un fabricant que s'adona d'una vulnerabilitat explotada activament al seu producte té un rellotge d'informes de 24 hores. Un programa que no pot separar "explotació activa" d'"alt CVSS" no pot complir aquest rellotge.
La probabilitat d'explotació és la tercera, i és la mateixa pregunta amb la predicció reintroduïda. L'EPSS puntua la probabilitat que una vulnerabilitat sigui explotada en estat salvatge en els propers 30 dies, cosa que és una pregunta molt diferent de com de greu seria si ho fos. Una puntuació CVSS alta amb una puntuació EPSS insignificant rarament és la feina d'aquesta setmana.
- Context empresarial és la tercera, i és la que cap canal genèric pot subministrar. Una vulnerabilitat accessible i explotable en un servei de pagament amb accés a Internet no és la mateixa troballa que el mateix CVE en una eina d'informes interna.
Aplicats conjuntament, aquests filtres converteixen rutinàriament una llista que ningú llegeix en una llista que algú acaba. El context d'accessibilitat i en temps d'execució normalment només deixa una petita minoria de troballes "crítiques" encara crítiques. Xygeni tracta l'accessibilitat, la disponibilitat d'explotacions, l'EPSS i el context empresarial com a etapes configurables en un embut de priorització, fins a vuit, de manera que "accessible i explotat activament" es converteix en una cua permanent en lloc d'una consulta que algú executa manualment.
Correcció de vulnerabilitats del paquet npm sense trencar la compilació
Trobar-ho és la meitat fàcil. El motiu pel qual les vulnerabilitats del paquet npm romanen sense resoldre durant mesos és que solucionar-les comporta el seu propi risc, i els desenvolupadors ho saben.
La pregunta important abans de qualsevol actualització no és "això aplica un pegat al CVE". Són tres preguntes alhora: quines vulnerabilitats desapareixen amb aquesta versió, quines de noves arriben amb ella i si la versió fa salt de codi al meu codi.
Xígeni mostra els tres per a cada dependència vulnerable, de manera que l'elecció és entre opcions visibles en lloc d'un salt. Aleshores, l'Autofix genera el pull request amb la versió amb pegats, la correcció massiva aplica diverses correccions en una sola acció i el bot Xygeni s'executa sota demanda, a pull requests o diàriament, de manera que l'acumulació de comandes es redueix sense que ningú ho programi.
Per a dependències transitives, on no es pot simplement augmentar una versió que no s'ha triat, la sortida útil és la ruta d'actualització més curta de l'arbre que resol l'avís, no una alerta que indica que un paquet quatre nivells més avall és vulnerable.
Abans que s'enviïn: on pertany el xec
"Abans que s'enviïn" és una afirmació de programació i es redueix a tres ubicacions.
- A l'IDE, de manera que un desenvolupador veu el problema en triar la dependència, que és el moment més econòmic per canviar-la.
- Per pull request, on un bot comenta què ha canviat i obre la correcció, i on una porta de seguretat pot fallar una compilació amb troballes per sobre d'un llindar. Només la limitació de la gravetat és el que fa que els equips desactivin la porta. La limitació de troballes accessibles i explotables és el que els fa mantenir-la.
- Continuament després de l'alliberament, perquè una dependència que estava neta en el moment de la fusió esdevé vulnerable el dia que es publica un avís. El monitoratge continu entre registres és el que detecta això, sense que ningú hagi de recordar tornar a escanejar.
I la sortida de tots tres pertany a una cua prioritzada juntament amb la teva SAST, secretsi troballes de contenidors, incloent-hi les ingerides de les eines que ja executeu. A llista de vulnerabilitats que viu a la seva pròpia consola és una llista que competeix per l'atenció amb l'obra que se suposava que havia d'informar.
Envia la solució, no la troballa
Un escàner que et proporciona 400 vulnerabilitats de paquets npm no ha fet la feina. Ha desplaçat la feina.
Xygeni restringeix les troballes de dependències per accessibilitat, probabilitat d'explotació i context empresarial, mostra què corregeix cada actualització i què podria fallar i obre la pull request amb la versió amb pegats. S'executa al vostre pipeline, produeix SBOM i la sortida VDR a SPDX i CycloneDX, l'evidència que sol·liciten CRA, NIS2 i DORA, i posa les troballes de dependències a la mateixa cua prioritzada que la resta del vostre risc, incloses les troballes dels escàners que no esteu substituint.
Comença gratis i escanejar un repositori, o veure com l'accessibilitat canvia la llista.
FAQ
Com puc comprovar si hi ha vulnerabilitats als paquets npm?
Correr npm audit Per obtenir una vista instantània, feu servir una eina amb anàlisi d'accessibilitat per reduir la llista a les troballes on es pot cridar el codi vulnerable. Les bases de dades d'assessorament com OSV i la base de dades d'assessorament de GitHub són útils per comprovar un paquet i una versió específics.
Is npm audit fix segur per córrer?
La versió no forçada sol ser segura, ja que es manté dins dels rangs compatibles amb el semver. npm audit fix --force no ho és: s'actualitza a través de les versions principals per resoldre avisos, i d'aquí provenen els canvis importants.
Per què tinc tantes vulnerabilitats de paquets npm?
Perquè la majoria són transitives. Instal·leu un grapat de dependències directes i hereteu centenars d'indirectes, cadascuna amb el seu propi historial d'assessorament. El volum és normal. És el triatge el que falta.
Què és l'anàlisi d'accessibilitat?
Determinar si l'execució de l'aplicació pot arribar realment a la funció vulnerable d'una dependència. És la reducció de soroll més gran disponible en la seguretat de dependències, perquè la majoria de les vulnerabilitats reportades es troben en codi que l'aplicació mai crida.
Hauria d'utilitzar CVSS o EPSS per prioritzar?
Tots dos, per coses diferents. El CVSS descriu la gravetat d'una vulnerabilitat si s'explotés. L'EPSS estima la probabilitat d'explotació en els propers 30 dies. La gravetat sense probabilitat produeix una cua ordenada per l'eix incorrecte.
Amb quina freqüència he de comprovar si hi ha vulnerabilitats als paquets npm?
Contínuament, no de manera programada. Una anàlisi neta dilluns no significa res dimecres si un avís arriba a un paquet que ja envieu.
