Hacker News new | ask | show | jobs
by albeva 3323 days ago
Frankly this is to be expected when "developers" working on these projects tend to be script kiddies more concerned with UX/design rather than solid architecture engineering. When backends are thrown together as an afterthought in node, piled in bunch of 3rd party services and things just hacked together ... well this is exactly results one would expect.
3 comments

Is there a correlation between the size and experience of a company and it's engineering team or technology choices and the likelihood of it being hacked? Tiny startups get hacked, and billion dollar corporations get hacked, and businesses of every size and shape in between get hacked. 'solid architecture engineering' might be a defence (although even the best engineered backend has very human weakpoints), but whether or not a business has a pretty UI and a node based backend is hardly a signal of how good the engineering might be.
I agree that technology choices are not the best signal to use.

They're one of a variety of primitive proxies for engineering culture, depth of talent and "process maturity". IMHO there is a weak correlation with team size, but a strong small team with good culture can of course outperform a large team with worse organisational culture.

As you scale a team you get more capability, but there are more bases to cover and more value to protect. Some points along the appsec spectrum of practices and culture:

At very small team sizes, reviews of pull requests with some minimum number approvers, plus a culture of responding to comments and enough expertise on the team that someone recognises basic issues like "we shouldn't store passwords like that" or "maybe we shouldnt chuck a url parameter straight into window.location here".

Small-medium, some level of technical leadership and design going into features with security as at least a consideration. Maybe a budget for limited code reviews / pentesting now and then or someone on the team with a constructive focus on security. Some automation with mostly free tools. Issue tracking for security defects and sane priorities.

Further along / large: employees who conduct security reviews (e.g, devs cc on prs and some spelunking), pentest and work with developers during the design phase. Plug tools like static analysers, scanners / runtime analyses into ci & test envs. Conduct threat modelling. Run regular training for developers. Have devs who work on code safety (like wrapping unsafe libs or fixing bugs in key dependencies). Use an artifact repository and stay on top of bugs in dependencies. Maintain internal checklists and a security knowledge base. Sane metrics and reporting (this is surprisingly hard). Conducting 360's where you track down the root cause of bugs and see where you can stop it happening again. Processes for dealing with bug reports (security@). Bug bounties. And more.

Although all sizes of company experience a variety of incidents, where you see problems is when engineering maturity isn't commensurate with the value of the data / transactions / assets / brand.

I had this discussion with my boss the other day, his position was that as engineers we should be able to write our own security, we're not "just" web developers. My position was that as an engineer I might be able to, but I should know that if I do, it's a huge liability - and there are plenty of examples of the best of companies that did it wrong.
I'm not convinced that you read the article properly. You're making projections about their infrastructure without having all of the facts.
You should read the reddit AMA done by the Zomato CEO, it'll give nice insight into how the company works :)
Heh, thanks for that. It's two years old, but certainly worth reading: https://www.reddit.com/r/india/comments/2yo614/hi_im_deepind...

> Do you really expect a good developer to be able to be in the zone for 12 hours straight?

> Why would we contribute to open source if we are barely able to ship what we need to ship to keep our users happy.

Exactly the line I was wanting to say, but did not want to sound too negative
Saying this in this way is very impolite.
Doesn't make it any less true.