The Problem with Bolted on Security and Amateurs

Many practices in software engineering have improved dramatically over the past decade and a half.

The way we build. The way we componentize. The way we manage change and store code and share and browse and evaluate and audit each others’ work.

The quality of code in general — and I understand that some will disagree — has improved significantly. The art has been engineered.

Security, however, has plunged into the abyss. It has taken a perilous journey into the land of amateur hour. I mentioned this regarding Basho’s Riak and its unfortunate lack of any security at all, really, a part of my concern being that in many cases it pushes security to people who are woefully incapable of implementing it.

Yesterday I caught a post on Hacker News about a service that offered to integrate Dropbox and Amazon Glacier. To do this it requires access to both your Dropbox and Amazon AWS accounts. Even if you restricted the AWS key you provided to just Glacier — which is something that cannot be assumed — it intrinsically has access to all of those files that you backed up.

This is the sort of project where security should have been the very first architectural concern of the builders. Where security is layered and comprehensive.

Given that I’m posting this, you probably guessed that security was not their primary consideration, evident given that they don’t even make use of SSL (the first red flag). Indeed, it seems like it was absolutely no consideration at all as Ryan Kearney detailed.

That isn’t just a security oversight. It isn’t an “exploit”. It is the absence of even the most rudimentary of security practices.

It is completely inexcusable.

I’d like to imagine that they’re the exception (“we’ll just bolt on security later!”). Join me in my dream world.

Leave a Reply

Your email address will not be published. Required fields are marked *