Slashing total application security risk with serverless

If you watched the #Serverless-First Function you might have seen this slide on measuring and comparing #security between a serverless app and a "Monstrous Monolith." Did you know these are actually numbers you can calculate and measure?

Take another look at this formula from two slides previous. Let's break down each of these components.

c = each function's computational complexity

This is essential or irreducible complexity as defined by T.J. McCabe all the way back in 1976. It's a positive integer, and you can calculate it. For more information, see McCabe's seminal paper on complexity here: https://ieeexplore.ieee.org/document/1702388

d = each function's dependencies

This is also a positive integer (consider your main application to be the first dependency to eliminate multiply by zero reduction). Import a library? +1 This is more challenging to compare across languages.

r = total number of accessible resources

You guessed it - you can calculate this too. DynamoDB table? +1. S3 bucket? +1. On-premises API? +1. The important thing is that you are consistent in how you apply this for your use case.

So now we can compare the two formulae. But what's the point? Not just to hate on monstrous monoliths, although they're awful relics and security nightmares and you should migrate away from them. Don't at me.

Since I know you're gonna at me anyway, consider this. Adding a dependency, a branching statement, or a resource to your monstrous monolith increases your risk on a cubic scale. With your serverless application that increase is linear.

The point is to understand how your system is evolving from a #security perspective over time. Where can you apply your limited resources to gain the maximum risk reduction? Don't guess the answer - calculate the answer!