There are few obvious things like adding min-release-age, ignore-scripts and save-exact. What other practice we can follow to ensure we are minimizing the damage, especially with chained dependencies.
Ask HN: How are you securing your NPM dependencies?
1–5 of 5 posts
Re: Ask HN: How are you securing your NPM dependencies?
#2Freezing the versions in package.json and generally not revisiting unless they have vulnerabilities or there's a compelling reason to update a specific package (which is rare).
Re: Ask HN: How are you securing your NPM dependencies?
#3Freezing the versions in package.json and generally not revisiting unless they have vulnerabilities or there's a compelling reason to update a specific package (which is rare).
Curious to know how are you going to ensure right security patches are getting updated in-time.
Most of my troubles are that I have fixed version of packages that are older than a year old. Now I am scared to update anything :)
Re: Ask HN: How are you securing your NPM dependencies?
#4Freezing the versions in package.json and generally not revisiting unless they have vulnerabilities or there's a compelling reason to update a specific package (which is rare).
Curious to know how are you going to ensure right security patches are getting updated in-time. Most of my troubles are that I have fixed version of packages that are older than a year old. Now I am scared to update anything :)
I use calendar alerts to run `npm audit`, but the older the code is the less likely you have to worry. You can update dependencies on a similar schedule but you need a solid test suite to make sure nothing broke.
When a vulnerable package there's only a few options, best case scenario you can ignore it if it it isn't relevant to your usage, otherwise I prefer whichever is the smallest action of updating, removing, or mitigating it in place.
Re: Ask HN: How are you securing your NPM dependencies?
#5Earlier quoted context omitted.
Curious to know how are you going to ensure right security patches are getting updated in-time. Most of my troubles are that I have fixed version of packages that are older than a year old. Now I am scared to update anything :)
I use calendar alerts to run `npm audit`, but the older the code is the less likely you have to worry. You can update dependencies on a similar schedule but you need a solid test suite to make sure nothing broke. When a vulnerable package there's only a few options, best case scenario you can ignore it if it it isn't relevant to your usage, otherwise I prefer whichever is the smallest action of updating, removing, or…
Neat idea to add a scheduled audit! going to steal it.