Npm security post-mortem
blog.npmjs.org
Npm security post-mortem
1–10 of 65 posts
Re: Npm security post-mortem
#2Its great to finally have full time folks managing npm and to finally have the resources to do things right (eg. hire ^lift).
Thanks for doing!
Re: Npm security post-mortem
#3The world would be a little better if every software company could inform its users of security vulnerabilities and bugs as these guys did.
Re: Npm security post-mortem
#4Nice write-up and good on them for fixing that quickly, but it's a serious bummer they unnecessarily bring in the RubyGems incident as some sort of awkward "Well at least we didn't screw up that badly!" swipe. It's not relevant to anything else they said.
Re: Npm security post-mortem
#5Nice write-up and good on them for fixing that quickly, but it's a serious bummer they unnecessarily bring in the RubyGems incident as some sort of awkward "Well at least we didn't screw up that badly!" swipe. It's not relevant to anything else they said.
I think what they're trying to say is that the bug is exactly as bad as the Rubygems incident, but they got lucky and it wasn't exploited.
Re: Npm security post-mortem
#6can anybody disclose some figures on how much ^lift (or competitors) costs, e.g.: for a 100K-line Python codebase? A rough ballpark would help a lot.
Re: Npm security post-mortem
#7It's worth noting that the XSS vulnerability ("A user could inject scripts into the npm website via the README and license fields") assuredly exposed a whole slew of easy-to-exploit vulnerabilities, and the community should feel very lucky that such an obvious vulnerability was in the wild for so long without being exploited.
TL;DR always use a templating engine that makes you think about XSS and don't allow unsanitized user-provided HTML through raw.
Re: Npm security post-mortem
#8can anybody disclose some figures on how much ^lift (or competitors) costs, e.g.: for a 100K-line Python codebase? A rough ballpark would help a lot.
Don't scope projects based on lines of code; you'll get shafted. Figure out the attack surfaces (for instance, how many app endpoints, how many URL routes, how many roles), come up with a total person/weeks scope, and then (especially if it's your first project) triage: capture the most important attack surfaces in a "pilot" or "90%" project to figure out how well you work with outside security teams.
A good firm will help you do this, gratis, if you're serious about funding the work. We do it "on spec" for most of our clients, even though that work sometimes ending up helping a competitor deliver the project.
It's fine if firms ask you for lines-of-code counts, but if that's the only question they ask, I'd consider that a red flag.
Re: Npm security post-mortem
#9Nice write-up and good on them for fixing that quickly, but it's a serious bummer they unnecessarily bring in the RubyGems incident as some sort of awkward "Well at least we didn't screw up that badly!" swipe. It's not relevant to anything else they said.
I think what they're trying to say is that the bug is exactly as bad as the Rubygems incident, but they got lucky and it wasn't exploited.
How I took it as well.
Re: Npm security post-mortem
#10can anybody disclose some figures on how much ^lift (or competitors) costs, e.g.: for a 100K-line Python codebase? A rough ballpark would help a lot.
^Lift gave us a really reasonable rate based on the number of people, the amount of time spent, and the number of weeks that they'd be poking at stuff.
They were extremely easy to work with, and very fast about getting stuff to us and verifying when it was fixed, and I felt like we definitely got more than our money's worth.
A+, would recommend, will hire again.