[MUSIC PLAYING]
HAYLEY DENBRAVER: I'm a developer advocate at Snyk,
and at Snyk, we want to help you use open source
and stay secure.
And because we eat, breathe, sleep security,
we've chosen this intimidating-looking guard
dog for our logo.
But as a developer advocate, it's
my job to be more like this golden retriever--
friendly, approachable, helpful, really wanting
to talk to you about open-source security, so that's my goal.
Right?
And feel free to say hi on Twitter
because I'd love to chat open-source security with you.
So today, we're going to do a few things.
First, we're going to do a very brief overview of serverless
and how it compares to some other solutions
you might have encountered.
Then I'm going to show you a demo app that I built,
and then we're going to hack it, which is my favorite part.
And finally, I'm going to give you a few takeaways,
so when you go and build your serverless app,
you have a few things to keep in mind to help keep it secure.
All right.
So when you're working with a cloud provider like Google
Cloud Platform, there's a few different ways
that you can organize your app.
And there are kind of pros and cons to both, or to any
of these, and we'll kind of do a quick overview of each.
So a monolith is what I would kind of see
as a more traditional solution.
This is where your team handles the virtual machines
and your apps run on that and, you handle the operating system
and the security questions that arise within the operating
system.
So you have to make sure that you stay patched so you're not
leaving yourself vulnerable.
And the Cloud Platform very nicely handles your hardware
and there's just easier elasticity and host setup.
OK, this is working out.
So with containers, it's pretty similar.
Your team's going to handle your virtual machines.
But within those virtual machines, you have containers,
and those containers can have different functionality in them
and each container can have its own operating system.
So it's just a little bit more flexible
and you can spin up a new container if you need it
but you don't have to scale the things you don't need.
And the Cloud platform, it handles your hardware,
you handle the operating system, but it's more flexible.
And this system is more portable and it's easier
elasticity and host setup.
And finally, you have what we're going
to talk about today, which is a serverless setup.
And in this kind of situation, you only
really need to worry about your app, right?
So you worry about your app and the functions inside of it,
but the Cloud Platform handles your virtual machine,
it handles your operating system,
they handle the hardware.
You don't have to think about operating system
management, your host setup.
This is the best cloud portability
and has maximum elasticity.
So this talk is about serverless security, and you may wonder,
well, I have given a lot of the security concerns
over to Google Cloud Platform and they're doing
a really good job with it.
So what's left for me to secure?
And well, I want you to think about your application.
And this may be a broader consideration
than you may at first think, right?
This little chart here I have, the yellow
represents the code that you wrote.
But the code that you write is not the entirety of the code
that you ship.
OK?
The big blue circle represents the code that you ship,
and the part that isn't the little yellow dot,
well those are your dependencies.
So let's take an example.
In one of Snyk serverless demo apps,
we have 222 lines of code.
And that's really trim.
Not much to survey, and you could look and find
security problems pretty quick.
But in addition, we have five direct dependencies,
and because those dependencies have dependencies,
we have 54 total dependencies.
And you might shrug at this but it actually
adds up to nearly half a million lines
of code, which is a lot, right?
And how many security vulnerabilities
are within those half a million lines of code?
All right.
So Google Cloud Platform is going
to secure the operating system for your serverless app,
but you need to consider your application security,
and you need to consider all of it, not just the yellow dot.
So let's take a look at my sample app
and we're going to hack it.
All right.
Because I like a bit of whimsy in my life,
the sample app is a to-do list obsessively written
by my cat to make sure that I do all the things that he
requires.
OK?
And I have a function within this app that renders
the to-do list really nicely.
So you can see we have the start of that to-do list here.
And if I wanted to add to this to-do list,
I can hit the HTTP point with a simple cURL command.
We already have Feed Cat on the list,
so we're going to say Feed Cat again because that's
just how it works.
And so we see that an item was created.
And when I refresh this, it's going to show the new task.
Right?
And this is awesome.
Jacques, he's going to add as many things
as he wants to, right?
But maybe I don't like that so much.
You know, I'm the boss, he's not the boss, right?
So what would happen if I want to take this app down.
To cut it off at its knees.
And I'm going to show you how we might do that.
So first off, I'm going to show you Snyk's website, where
I've uploaded this app.
It looks at the dependencies within the app
and it scans them and it lets me know when there
are known vulnerabilities.
So within my dependencies, there are actually
nine known vulnerabilities.
There may be more but these are the ones we know about.
They have CDEs, all those different things.
And some of them, we can exploit and get in.
So the one we're going to look at
is a regular expression denial of service.
So this vulnerable module, MS, it's in our app
because it helps us parse time fields, kind of.
So to give you an example of that,
let's say my cat really wanted to take a nap
but he wanted to be woken up.
So he's going to add an item to the to-do list
of wake cat in two days.
So he's going to take a nice long nap.
And so we do another cURL command
and it creates another item on our list.
And we can see it here, wake cat,
and it recognized two days as a time period
and so that's why you see that formatting there.
Right?
And we could build functionality around that to,
like, send out a reminder or something along those lines,
right?
However, I'm kind of fed up with this whole thing
and I'm going to try to create a to-do item that it's
going to take the system too long to do matching.
Right?
So let's see.
So I'm going to use this cURL command, which
tries to add a to-do item to provide snacks
in an amount of time that's really long,
and just to keep it chugging away and trying to figure out
what's going on a little bit longer, I misspelled minutes.
OK?
It says here, minutey.
So let's see what happens then.
Well, nothing.
Right?
It's still chugging along, trying
to make a match somewhere and trying
to do its regular expression thing, right?
But while it's running like this, my cat,
whether he wants to or not, he can't add any new to-dos
to my to-do app.
And so I really appreciate that and I'm just really glad
I was able to stop him in his tracks just using
this simple regular expression.
Right?
So I'm going to just kill this.
So once again, I'm the master, not Jacques.
So let's go back to the presentation.
So I have a few takeaways that hopefully you
can use when you're writing your next serverless app.
And briefly there, number one, beware of vulnerable libraries.
Number two, deploy granular functions and permissions.
Number three, don't rely on function ordering.
Number four, don't rely on immutability.
And number five, to worry about all functions.
So first off, beware of vulnerable libraries.
Test during development and monitor over time.
This is exactly the kind of problem
that I just took advantage of when I broke
Jacques' to-do list, right?
And here's a little snippet of the Snyk website
and you can see that it'll list out the vulnerabilities
and give you a little report about them.
And so then you know.
And it also will tell you what remediation can be taken.
Right?
So this is a very important thing to be aware of.
Secondly, you should deploy granular functions
and permissions.
It's safer.
So think about today.
You were able to come down into this space
because you have a badge.
I'm looking out and you all have badges on, right?
But your badge doesn't get you into the entirety
of this space, right?
There are doors and things that you need a special badge for
or a different colored badge, something along those lines.
It would be madness to issue everyone
that came to Google Cloud Next just a generic, like, you're
allowed everywhere badge, right?
And it's the same here.
Deploy granular functions and permissions.
Don't let everyone access every function.
It's just better.
All right.
Don't rely on function ordering.
Every function is a perimeter that needs to be secured.
And when I think about this one, I
think about how I don't not lock my safe just because I've
locked my door, right?
Don't rely on these initial functions
to protect the ones that are maybe further in your app.
Right?
Every function has a perimeter that needs to be secured.
Fourth, don't rely on immutability.
Assume servers can be reused.
And just in general, don't make assumptions that
could compromise your security.
All right?
And finally, worry about all functions.
Every function increases your attack surface.
Let's say you have a house that has ten windows
and you were very diligent and you
alarmed and locked eight of them but two of them are open.
Or maybe they're not open but they're just not locked.
Well if you have something of value in your home,
the eight highly secured windows aren't
going to deter someone who wants to break in
to get what you have, right?
So it doesn't matter that you've secured those eight.
What matters is that there is a way in in those two windows.
So finally, just one more quick review,
be aware of vulnerable libraries,
deploy granular functions and permissions,
don't rely on function ordering, don't rely on immutability,
and worry about all functions.
Also, don't let your cat boss you around.
So thank you all.
And again, I'm Hayley Denbraver.
I'm a developer advocate at Snyk.
Feel free to say hi on Twitter @hayleydenb
or to follow my company Snyk @snyksec
or to check out our website on snyk.io.
You can try the tools that I showed you for free.
And yeah, thank you all for being so great.
[APPLAUSE]
[MUSIC PLAYING]