>> I'm Armon.
>> I'm Aaron.
>> And this is the Open Source Show.
[MUSIC]
>> I'm Aaron. I'm a Cloud Advocate at Microsoft.
>> I'm Armon, one of the co-founders and CTO of HashiCorp.
>> We're here today to talk about security and open source.
So, these things, just right out of the gate,
they seem kind of at odds.
>> I think when we typically talk about security,
we don't think about open source software.
We think about closed source,
proprietary, and so I think you're totally right.
They don't necessarily blend.
>> But you have a lot of experience in this kind of realm.
I guess, the intersection of open source and security.
>> HashiCorp is a very open source oriented company.
Every product that we make is open source
and so when we went out to create Vault,
which is our open source security product,
it was natural that we would do an open source.
So, it didn't seem odd to us
because everything else we do is open source.
But I think for the broader sort of security community,
it definitely seems strange.
I'm sure we've all committed this crime which is,
we're writing our application and we're like,
"Oh, I need my database password."
So, I'm just going to create
a variable and put my "Username" and "Password",
it was hard coded in my application source code.
>> A best practice is not to "Copy" and "Paste"
your database password into your source code, am I right?
>> Yeah, exactly.
>> Okay, all right.
>> Exactly, and note to viewers, do not do it at home.
>> Do not do that at home.
>> Although, we've all done it, right?
>> Yes.
>> I think that particular pain of like, "Okay, well,
I need this database Username and
Password. So, where do I put it?"
It has to come somewhere,
either put it in my source code,
I put it in a config file
I put it in sort of an environment variable.
I have to put it somewhere
but none of those are actually secure places, right?
>> Yeah. >> If I put on my source code, well,
anyone who can look at the source code can see it?
This is a problem we'd like to
collectively refer to as Secret Sprawl, right?
The reason we call it that you have these secrets, API
tokens, username, password, certs,
and you've sprawled them everywhere.
They're in our app code, our configs
in our GitHub, everywhere.
So, it's how do we solve that?
Move it to a central place and tightly wrap it.
So, what I'd recommend is looking
into secret management as an approach, right?
Bring it into a central place, encrypt it,
tightly protect it and that's our goal with the Vault tool.
>> So, you mentioned some heavy duty stuff;
encrypted, access control, maybe a couple of other things.
Putting my like, big company sort of enterprise hat on,
that sounds like something that could be super useful for me,
if like, I'm a CTO or something of a bigger organization.
>> Totally, and I think this is kind of
interesting dynamic with likely open source interaction,
when you typically think big enterprise hat on.
Security products, you think about closed source, proprietary.
The deals are done in the backroom
We don't talk about how the technology works.
But then we try and say like, okay, well,
but Vault is like the exact opposite of that,
which is you don't have to trust us.
We've literally given you the source code.
Go to GitHub and you can go see literally how the tool works.
I think it is a little unusual when you
talk about Vault as sort of an enterprise setting.
How do you get sort of
a security guarantee of a security product but
also deal with the fact that you're living in
open source and it's totally out there, right?
>> Why is it good for Vault to be
open source and why does that increase its security?
>> It's not specific
necessarily just to Vault, it's kind of, I think,
applies to really all open source software,
what's called the kind of the 1000 Eyes Principle, right?
>> Okay.
>> If I'm writing proprietary software,
let's just say, right?
Maybe I write the code and then one of
my teammates does a code review on it and that's it.
Those were the two people who looked at
that code and really understood "is this safe,
is there security issue,
how does this thing work?".
>> Okay.
>> But when you start talking about an open source project, great.
Maybe I wrote it, maybe you code
reviewed it and then we published it,
and a 1000 people looked at it, right?
>> A thousand people? Okay.
>> So, this is that notion of the 1000 eyes as it's like,
it's not just you as the authors and maintainers,
it's the entire community that can now look at the code,
audit it, find issues in it.
>> So, let me go grab my imaginary devil's advocate hat.
Okay. We've got a 1000 eyes on the project, right?
Let's say that two of those eyes,
they are hackers, right?
Or they're just looking to mess stuff up and they see
a security vulnerability in Vault. What happens then?
>> It's a super good question.
How do you maintain these open source projects in a way
that you can leverage
the community to increase everyone's security.
A common practice as what's known as responsible disclosure.
>> Okay.
>> Right? So, great. If I have
a 1000 people looking at the source code,
maybe two of them are attackers
but you'll have 50 of them who are security researchers,
who are going to find issues
and are going to report back to you and say, hey,
we found this bug or we found this sort
of possible attack against the tool.
So, how do you enable them to
improve the product and that's all about responsible disclosure.
The worst case scenario is that those people
post on GitHub and say, "By the way, everyone.
Like here's a huge issue that you can
use to like hack the system."
Then you're like, what you want is that they
come to you as a maintainer and say,
"Hey, we found this issue.
Here's a possible patch.
Like, let's figure out a timeline to get it fixed,
get a new version out there and then notify the whole community.".
>> Okay. So, you notify after its fixed?
>> Exactly.
>> Okay. So, I heard something about the Kubernetes.
Kubernetes had a security vulnerability
kind of like this, did you hear about that?
>> Yeah. I think you saw that exact same sort of
1000 eye principle at work there, which is,
a set of users that are just
using the tool but are periodically checking like,
"Hey, how does this work, can it be made safe,
like is this secure?"
Found an issue but then they were able to
work with the maintainers responsibly disclose,
"here's a big issue,
let's come up with a patch
and once there was a fix available,
notify the community, "Okay,
let's go, get to the latest version and this issue has been fixed."
So, that's a perfect example of sort of open source working well.
>> So, that sounds like a really good interaction
between a contributor and the maintainers.
So, we've kind of touched on the contributor thing like
some best practices or
at least one best practice for
contributors of open source in security.
What are some more things that like,
if I go in and I want to work on Vault,
let's say, what kinds of things should I look out for?
What kinds of things should I do so that I can help?
>> Right. Yeah, it's a super good question.
A core idea in security is,
trust no one including yourself.
>> I got this, trust no one including me.
>> It's sort of weird to say but I think in some sense,
that framing helps you think about what's the right process?
So, for example, what we do is,
if I'm writing the code,
I'm going to get two or three of my peers to review it
but then I'm also going to bring in an external security auditor.
I'm also going to have the community take a look at it.
So, you want to have sort of all of these people kind of
looking at this and sort of three-legged tripod approach,
because you don't trust any one of them.
You don't trust that I wrote it correctly,
I don't trust that you reviewed it perfectly,
I don't trust with the community is going to catch everything,
but sort of we're working together to secure this.
>> All right. That's good to remember, tripod approach.
But if I'm a contributor or maybe I
am a maintainer on another project that's not security related,
is there any other stuff I can do to make sure I don't compromise
some infrastructure that my product
needs or somebody else's credentials?
>> Security is it's a whole universe, right?
We stepped back from saying,
maybe I'm not a contributor,
I'm just a developer on a different project, writing a web service
>> Right. How do I think about the role of open source there?
I think there's a few aspects to it, which is like,
just like everything you have to
stay up-to-date with your dependencies like,
the Kubernetes example is a great example.
Like, let's say I'm using that
but I deployed it and it's working fine.
I'm just not going to pay attention anymore.
Well, there's security issues, there's things that come up.
So, if you're not paying attention to it and there's
a security issue and you just don't update,
well, now you're vulnerable to them.
As you pull in libraries or as you
pull in tools, you have to stay on top.
If there are security issues and making sure I'm updating,
don't just pull in the version of
the day you start using it and it's saying like,
it works, I'm done here, right?
Because, these projects move on.
That's a best practice as a developer.
Stay up-to-date, understand what are your dependencies,
because those are the things that sort of come to bite you later.
>> Right. If I can get someone else to like host it for me,
or automatically do the updates for me,
like a cloud or a service or whatever it is,
that's sounds even better, right?
Because I don't have to stay up on like, well,
new issues come into the queue
or responsible disclosure or anything else like that.
>> Yeah. I think when we talk about sort of like,
what are best practices as a developer?
Like, how do I make the
security challenges of writing software easier?
It's kind of the same with everything?
The easiest way to do something is to not do it at all, right?
>> Yeah.
>> So, if there's some way I can take this,
probably make it someone else's problem, right? Great.
>> Make it someone else's problem.
>> But it's true, right? It's like that's the easiest way.
We have so much to deal with as developers that it's like, okay,
if there's a service that
Azure will give me that will just solve this problem,
now I don't have to bring in a library in my app that I keep up
to date and watch their mailing list for updates,
sounds like, great, ripped out out of my app, use this service.
Now it's Azure's problem, not my problem.
>> All right, So, where can I read
more about how to get Vault setup,
what it does, et cetera?
Where can I go to see that kind of stuff?
>> So, there's a ton of good resources.
There's going to be an upcoming Azure Friday
video but in the meantime,
I recommend checking out the HashiCorp blog,
Vault's website, vaultproject.io or we have
a whole set of learning resources at learn.hashicorp.com.
We can learn how to use Vault and get
more in-depth into what problems helps us solve.
>> Cool. All right.
So, check out those links in the show notes below,
make sure to subscribe and definitely go check out
opensource.microsoft.com for more. Take care, everybody.
>> Thanks.
[MUSIC]