Necesitamos tu apoyo para difundir nuestras crónicas con relación a las ciencias de la computación.
Solución:
lodash-cli en devDependencies no afecta como browser-sync trabaja en su proyecto, devDependencies se ignoran cuando se instala un paquete como una dependencia.
Qué audit informe dice es que es easy-extender que tiene lodash dependencia:
browser-sync > easy-extender > lodash
Depende de Lodash 3, mientras que el problema se solucionó en Lodash 4. El problema podría solucionarse bifurcando easy-extender, actualizándolo e instalándolo en lugar del paquete del registro público de NPM. Pero no hay ningún problema real con esta dependencia.
audit La importancia del informe debe evaluarse manualmente. Incluso si la dependencia anidada tiene un riesgo de seguridad, esto no significa que se haya utilizado una característica que presenta este riesgo. Esto tampoco significa que incluso si se usa, presenta un riesgo real debido a cómo se usa.
browser-sync es una herramienta de desarrollo que no se usa en producción, no hay tantos escenarios donde se puedan explotar sus vulnerabilidades. Y Prototipo de contaminación no es una vulnerabilidad en absoluto, solo un aviso de que un paquete no sigue las buenas prácticas, puede ignorarse.
En general, esta es la forma de corregir las vulnerabilidades informadas:
- Haz un chequeo de cordura
- En caso de que sea un problema real, consulte el repositorio del paquete vulnerable para ver si hay problemas existentes. y relaciones públicas
- En caso de que no haya ninguno, envíe un problema
- Bifurque un repositorio o use PR existente como dependencia de git hasta que se solucione en el lanzamiento de NPM
- En caso de dependencias anidadas, haga esto en varios niveles de anidamiento
La mayoría de las veces se espera que no avance más allá de un control de cordura.
patch-package puede ayudar a parchear las dependencias anidadas en el lugar, pero esto no afectará audit reporte.
Si está absolutamente seguro de que desea omitir la auditoría, puede hacerlo agregando –no-audit
npm install --no-audit
La ‘corrección de auditoría npm’ incrementará la versión de la dependencia en package.json, lo que podría conducir a la ruptura del código. Entonces, la mejor manera es abrir package-lock.json y actualizar las versiones de dependencia/subdependencia a la versión requerida. Mantenga el paquete-lock.json en el repositorio.
A veces, las vulnerabilidades provienen de paquetes de desarrollo. En ese caso, ignore esas vulnerabilidades, ya que no se detectan en la producción.
Si piensas que te ha sido provechoso este post, sería de mucha ayuda si lo compartes con más juniors y nos ayudes a extender este contenido.