Monday 10 February 2014

Is Rapid Development a security threat?

The business world borrows Open Source software methodologies so that they can become agile (little a).  Release early, release often.  Continuous builds.  Unit testing.  This works out well.  Lower costs, quicker time-to-market, more reliable, repeatable and redundant.

We're into update cycles now.  We know about version numbers, feature sets, upgrades, updates.  That latest security thing?  Just update it.  Make sure it says v15.0.20140210_Build_29e4.  It's mundane.  One of my browser's plugins wants an update.  And my phone has some.  And my tablet.  TV.  Car.  Meh.  It's probably just a new wallpaper option, anyway.  Via the new in-app store!  I'll reboot on the weekend and it can apply the updates and reboot three times if it wants to.  I'll make some breakfast and eat it with my daughter, watching Regular Show.

But could Rapid Development actually be providing crackers with the exact information they need?

A committed attacker probably has about a week to crack a lot of systems.  But where should a potential cracker go to look for such weaknesses?  Backlogs, issue lists and change logs.  "It crashes right after I click save.  Here's the stacktrace and corresponding log entries: ..." "oops.  forgot to uncommnt the call to the fn() that cleans up all the tmp files before we exit().  Sorry.  Pull request 
6ac1649f26daed8e1e0ccafba43568a67ed00686."  Thanks for the exploit, fellas.

Perhaps this is why +Google  never reply to their users?  "Customer service rule 2: Just read what people are complaining about, don't say anything, fix the problem, release the update, announce '..., bug fixes, ...' and move on."

No comments:

Post a Comment