James Governor's Monkchips

The high cost of free: on serverless, convenience and security vulnerabilities

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Plastic waste

Jeffconf today was excellent, but the talk that really stuck with me was Guy Podjarny, founder of Snyk, because he introduced an idea I had never considered before. At RedMonk we spend a fair bit of time discussing the power of convenience in technology adoption, but also its potential costs and downsides. As a metaphor think of how absurdly convenient plastic packaging is, but also how damaging.

So what happens in the serverless economy, where you don’t need to pay for a function until it is actually used? Well for one thing, just like plastic bottles, you’re less likely to dispose of them effectively. In microservices we talk about disposability as a virtue, but with serverless it’s so easy to deploy code, why bother getting rid of it? When it comes to security though, poor code hygiene essentially leads to bigger attack surfaces, which is A Bad Thing.

“With serverless there is zero cost to deploying functions, so you deploy everything. Say a cron job. That is awesome, but also false from a security perspective. i am most concerned about this explosion of attack surface.Make sure you know what is disposable, and dispose of it.”

Snyk is all about understanding vulnerabilities in your source code, looking at dependencies and attack vectors. It turns out that serverless, by the very fact of it’s convenience and low cost model, may lead to laziness, and poor security. If you’re not worried about paying for your cruft, in terms of compute and storage, then why bother cleaning up after yourself?

This fact could be an Achilles heel for serverless implementations. Business and government have been surprisingly accepting of security breaches, but that seems to be changing, with regulations like GDPR coming over the horizon. Just because serverless looks cheap at first sight, doesn’t mean it might not be expensive in the long run. Definitely food for thought.

More on Jeffconf from me next week, but the Snyk talk was really good.

9 comments

  1. This is one of the nice things about using declarative deployment tools like CloudFormation as the definition of your infrastructure. Deleting a function is as easy as removing a few lines of JSON/YAML and updating your stack. Which sounds a lot like “deleting a function is as easy as removing a few lines of code and recompiling”. 🙂

  2. Two sides to that coin. Every time a cloud function is run, it’s on a (relatively) recently-booted freshly-patched host, and (relatively) free of accumulated inevitably-partially-unintended state. How’s the patch/update/state-management discipline in your typical microservice deployment?

    1. tim – really good point, the host is likely cleaner. and yes – cruft is a thing in any IT system, for all the talk of immutability with container-based microservices.

      jeff- agreed. hopefully part of the point i was making. good hygiene is good hygiene – but “cheapness” can definitely lead to laziness. “oh i will just leave that one there for now and come back to it”

  3. We’ve considered lifecycle (auto-expiry) rules for Lambda functions, but taking code out of service, even when it’s been requested by the owner, has always felt dangerous for a vendor to attempt. Maybe a liveness report?

    1. @tim great to see you here. very interesting to see you working on this. auto-expiry does sound potentially on point, though as you say, could upset people even if they set it up. the liveness reports idea is certainly interesting in helping with hygiene.

    2. I think auto expiry is an excellent idea. Should have an easy override, but have the default behaviour be at least making functions unavailable from the outside (maybe meaning an API Gateway expiry?).

      While taking code out of production is not a historically common practice, putting code into production has never been so easy, so it doesn’t surprise me we’ll need to introduce some automated pruning.

  4. […] good developers can find themselves making really bad decisions about security. Redmonk analyst James Governor hit on this in a recent post, arguing that the very convenience of serverless can lead to "poor code hygiene" […]

  5. […] wrote the other day that the talk from Jeffconf that had really stuck with me was by Guy Podjarny. That’s actually wrong, I should have said, one of the talks that really […]

  6. […] The High Cost Of Free: On Serverless, Convenience And Security Vulnerabilities […]

Leave a Reply to Guy Podjarny Cancel reply

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