Y'all might want to limit the number of characters in a user's name...
Npm security post-mortem
31–40 of 65 posts
Re: Npm security post-mortem
#32Why do they have to apologize for that? Almost every piece of software has security vulnerabilities. Do people now really believe that there are definitely no security vulnerabilities related to the npm registry? Or any other type of registry, or website or application for that matter? People have completely unrealistic expectations about security. Every time you had a significant amount of new functionality, or even…
"Why do they have to apologize for that?" It's just the sad state of the 'industry'. As soon as some armchair warrior finds something remotely wrong with whatever, they'll go nuts on you and you need this sort of touchy-feely PR nonsense to placate the comic book shop types. Hats off to these guys for being level-headed enough to be able to play the game this way - I couldn't do it any more, I'd go bonkers over overh…
If anyone needs placating, it's those developers, managers and executives who pushed hard for the use of Node.js in business settings, not expecting a serious security incident like this one to happen.
For those who are especially serious about their careers, reputations, budgets and power, incidents like this involving the technologies they hyped and pushed through can be disastrous. Now they're seen as being very wrong about something very important, and this in turn makes them extremely angry.
They know that their competitors within the business will use this incident against them. Their next initiative will surely face comment like, "Why should we listen to you after the npm disaster?", and they will face a much harder battle if their decision involves any controversy or doubt at all.
Re: Npm security post-mortem
#33The world would be a little better if every software company could inform its users of security vulnerabilities and bugs as these guys did.
They can, and many do or have done so in the past.
Let's not pretend that security incident post-mortems are anything new; they aren't. There's not really even anything special about this one.
I don't really see much point in applauding these guys for doing what's perhaps the minimum we should expect from them in this situation.
Re: Npm security post-mortem
#34Earlier quoted context omitted.
"Why do they have to apologize for that?" It's just the sad state of the 'industry'. As soon as some armchair warrior finds something remotely wrong with whatever, they'll go nuts on you and you need this sort of touchy-feely PR nonsense to placate the comic book shop types. Hats off to these guys for being level-headed enough to be able to play the game this way - I couldn't do it any more, I'd go bonkers over overh…
If anyone needs placating, it's those developers, managers and executives who pushed hard for the use of Node.js in business settings, not expecting a serious security incident like this one to happen. For those who are especially serious about their careers, reputations, budgets and power, incidents like this involving the technologies they hyped and pushed through can be disastrous. Now they're seen as being very w…
Every technology is going to have an "incident" like this. Experienced developers expect security "incidents". There are quite a few managers and executives who do not understand security and don't. And many people who will use this sort of "incident" politically. Politics is the problem there, not the technology.
Just because they found one significant security issue with npm does not mean they were "very wrong" about using Node. Its just a reality of security with any technology.
This isn't a disaster, this is a demonstration of maturity, responsibility and transparency.
Re: Npm security post-mortem
#35So the audit was mostly about nom the website and the service for maintaining npm packages? That's a good first step. Has there been any talk within the node community about auditing node modules themselves? Maybe start with the most popular? I could see this being popular with enterprise development, etc. I want to say that Strong Loop made noise about doing something like this, but I haven't seen much on it of late…
One of the Node Security Project (https://nodesecurity.io/) main efforts is to audit all the npm modules in a community driven way.
We are accepting contributions from the community to build the tools that get the job done efficiently and to audit modules, disclosing vulnerabilities in a responsible manner.
Re: Npm security post-mortem
#36[deleted]
I'm sorry you took it that way. The scope of our security hole was exactly as big as the Rubygems vulnerability. If I'd omitted that comparison, I was sure somebody would say "these guys were just as bad as ruby but they're covering that up!" At the same time, I wanted to make it clear that the only reason this wasn't a game-over disaster for us is because we were lucky. We weren't any smarter, or better designed. Ju…
I think the problem I had with it had to do with the way the sentences were constructed. For example:
"... this could have been a disaster, very much like the rubygems.org security breach in early 2013"
This implies that the issue you had wasn't as serious as the RubyGems issue.
Similarly, the following sentence likewise implies that the breach was not as severe:
"Unlike that incident, there’s no evidence that, other than ourselves, the engineers who reported the bugs, and a few members of the GitHub security team who knew about the issue, anyone knew about this hole."
This implies a confidence in the presumption that you weren't breached that you then backpedal on in the following sentence by saying "of course we're not positive because we didn't have logs".
Both of the sentences I cite lead a reasonable reader to a different impression than the one you say you were attempting to convey. I'm glad to see you clarify things here, but I hope you can see why people would misconstrue things based on the words in the post.
Re: Npm security post-mortem
#37can 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.
Thomas could give you better numbers here, but in general, appsec reviews cost as much as getting software development done. (i.e. For a security review worth the paper you print the report on, you're looking at $5k at the lower end if your application is simple or if someone wants to really do you a favor, and they get substantially more expensive than that. You can get someone to run an automated scan for $500 and…
Thanks, this gives me some basic figures to think of.
Re: Npm security post-mortem
#38[deleted]
I'm sorry you took it that way. The scope of our security hole was exactly as big as the Rubygems vulnerability. If I'd omitted that comparison, I was sure somebody would say "these guys were just as bad as ruby but they're covering that up!" At the same time, I wanted to make it clear that the only reason this wasn't a game-over disaster for us is because we were lucky. We weren't any smarter, or better designed. Ju…
Truly exactly as big?
The Rubygems vulnerability was the ability to run any code you want. What you describe is remote file browsing/access.
Re: Npm security post-mortem
#39Why do they have to apologize for that? Almost every piece of software has security vulnerabilities. Do people now really believe that there are definitely no security vulnerabilities related to the npm registry? Or any other type of registry, or website or application for that matter? People have completely unrealistic expectations about security. Every time you had a significant amount of new functionality, or even…
I thought the apology was measured and appropriate.
They knew they needed to have an audit and have intrusion detection when they started, four years ago.
Re: Npm security post-mortem
#40can 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 wil…
Thanks for the heads up. I had actually mentioedn only KLOCs as an initial number just to have a rough idea; I understand it's not sufficient for a real quote, but I was just looking into ballparks here.