9. Dylan Ayrey, Founder and CEO of Truffle Security, How Open-Source Makes the World More Secure

Hey everyone, welcome to the security podcast of Silicon Valley. Today I'm here with a very special guest, Dylan Airy, who is the co-founder and CEO of Truffle Secure. Before that, he was a contributing author of TruffleHog, which is the open source core of the product at Truffle Security. And prior to that, a senior security partner at Netflix.

And if you looked at his LinkedIn, he has a good chunk of other stuff related to being a security person. And if you go all the way back, was at RIT, got a BS in computer engineering. So welcome to the show, Dylan. Thanks, John.

Great to be here. So can you tell me about some of that, the security research that you were doing before you got involved with the Truffle Security? Yeah, sure. So I've been talking at conferences for a couple of years now.

Most recently in 2020, I spoke at Black Hat and DEF CON on some GCP related security stuff that we did in collaboration with Google. I've also spoken at KibiCon, TorCon, B-Sides SF, TorCamp, and a bunch of other on a wide range of topics. Usually it's centered around application security. A couple of years ago, I did some Wi-Fi hacking stuff.

And so I published the Wi-Fi WPA2 half handshake crack where you only needed half the handshake. Prior to that, it was like the full handshake. And I did a write-up on how that was possible and published some scripts there. A bunch of application security stuff.

And so I showed like malicious websites can stomp over what's on your clipboard and potentially put malicious commands in there and things like that. And a bunch of other one-off fun application security type blog posts. I bet that clipboard attack is really nasty, especially given how people transfer bitcoins around usually copying and pasting. Well, you know, the example that I think I gave was like a stack overflow page.

If you copy a command from stack overflow and go to paste it in a bash shell, what you copy isn't necessarily what's in your clipboard. And they could put a new line at the end of the command. So it would auto-run as soon as you pasted it in. And after I did the write-up on that, iTerm actually pushed out a new feature that prompts you and says, hey, what's in your clipboard has a new line at the end.

Are you sure you want to paste it in? So that was like as a result of that. And the other thing is like that particular security problem, I think, is like really easy for folks to wrap their head around whether or not they're in the security space. And so I think that kind of helped with the popularity of that blog post is, you know, as opposed to some of the complicated, you know, you can use CSS to see surf, steal this token over many requests type posts I did.

The clipboard one, like you mentioned, is just like really easy for folks to kind of wrap their head around, I think. But anyways, I also like I'm an avid open source contributor and user and have open sourced a number of things over the years that have just kind of collected dust on my GitHub. But that's sort of me in a nutshell and some of the research I've done over the years. Would you like to share with our listeners a little bit about what Truffle Security is or what you guys do over there at Truffle Security?

Yeah, sure. So TruffleHog is one of those open source tools that I open sourced a while ago, actually. And basically all it does is it finds API keys that are accidentally leaked out. So it can go through what was originally just meant for Git revision control, dig through all those old commits and find API keys that folks either accidentally or intentionally committed.

And it was originally just written for me to do bug bounties. So in the readme, you can actually see a screenshot. That's from a real bug bounty. It actually has the real key, which is no longer active, from when I first open sourced this thing and started doing bug bounties with it.

Decided to give it back to the community. Lots of folks have since used it for all kinds of reasons, bug bounties and putting it in CI pipelines and this, that, and the other. Today, I think I have something like a thousand daily installs from public repositories that I've published to. And in addition to that, it's, you know, native in Kali Linux and a bunch of other tool sources that also get different uses out of the tool.

So I think it's, you know, I'm so excited to be a part of that community and have given back in a way that allows people to improve their security and sort of be able to find these keys easier. And I'm just really happy this year to be given the opportunity to continue to grow that community and spend more time with those folks and continue to give back to them. Yeah, that's really special. I love the sort of the inception story and it's a nice focused space.

And I know as a security professional myself, I've had many facepalm moments where I'm looking at a repository and then, oops, there's a key. And it's like, oh, this is not good. And to have some automated help with that could go a long way. way in actually putting a real dent in a very pragmatic problem that I'm sure many security professionals share my experience of that facepalm moment.

You know, we do have an obligation to educate and jump on things that we do notice here and there. So that's awesome. And the fact that it got started with a bug bounty hunt program, so you were looking for bug bounties and just wanted to automate your hunt for credentials. Yeah, it was actually really difficult to go through revision history, actually.

So like, maybe you could type into the GitHub search bar or something that you're looking for, but it wouldn't go through all those old commits. And what I found is about half of the source code is actually buried in that past, which meant up to that point, half the keys just weren't being found. And I think maybe to your point, like, you know, everybody makes mistakes. Security should be ran in a blameless way.

Myself included, have committed keys in the past. And so, you know, you can think, you know, over the course of a year or two, an individual developer or security engineer might accidentally commit a key or two, but in an organization that's got 7, 000 people, that means you have more than 7, 000 keys leaking out in a year. That's really where this thing becomes a problem at scale, where you have a big organization that's regularly open sourcing stuff. You know, people make mistakes, even when the tools go through an open source review process, like that old revision history wasn't really audited super well.

And so I wrote the tool to kind of help dig through that past and help clean up some of those keys that were kind of missed. Like an archaeologist in a script knows exactly what to do. You know, it's funny you mentioned archaeology. What I think about all the time is that Arctic vault where they've taken all the big open source projects and put, you know, the one I'm talking about where GitHub put them in ice and locked them underground in the permafrost of Antarctica.

How many API keys are permanently codified in that vault until the end of time? And when real archaeologists 10, 000 years from now, you know, dig through what's no longer permafrost, it's just melted mud or whatever it turns into, and they find this big vault, they're going to do forensics on it and find the ancient keys that the, you know, 10, 000 years of developers accidentally leaked out. And maybe we'll give them access to some like, you know, subsystem or remnant of the human race. Right.

You know, some of those API keys are probably not going to be rotated by then. They're probably still be active 10, 000 years from now. 10, 000 years recommended we rotate this. Exactly.

Yeah. That's funny. Okay, so Truffle Security is built on this open source platform. So why open source?

I know a lot of companies don't really, they don't go down the open source road, but it sounds like you really embrace the community and you're still able to build a company around there. Yeah, that's a good question. So I think sharing a little bit about my background, I went to RIT, like you mentioned, they're the first school in the country to have an open source minor. And so I was able to get exposed to open source through their open source program.

I wasn't minoring in open source, but I took one of those classes and I was very involved with the program lead over there. I was part of his like open source club. jQuery is also like a big notable open source project that came out of RIT. And that creator was like involved in those same scenes and would go to those hackathons so that I could hear from him and bounce ideas off them.

I mean, the reality is like you're a company based out of San Francisco making technology and thinking about the users of that technology. I think it's often easy to localize your experiences to build it for companies that you've spent your time with and use cases that you're most familiar with. But when you don't give that technology back and you don't make it free and open, there are so many other use cases that you don't get to see that you miss and you don't get to build the tool for.

By creating that open source tool, you get to give back and allow others to come to the table and explain their use cases in the tickets and submit those pull requests and be able to just bring new perspective that just totally doesn't otherwise become available to you. And when you think about also the technology that you're building, I think we often build it, you know, we build it for the United States. We build it for San Francisco. We build it for like this hyper wealthy spot within San Francisco.

But the reality is like people all over the world use these tools. And by making it free and open, we're making technology more accessible to folks that don't otherwise have access to it. And we're bringing, in this case, information security and the ability to do bug bounties and make money to places that would otherwise have a have a hard time getting into those spaces. And so I think open source is a really powerful tool that can really help people.

It can really unlock technology in a lot of different areas that we don't necessarily always think to build technology for. And Being able to have them as part of the same community and help build the tool with you is, I think, really, really powerful. And that's sort of, that's my background of where open source kind of, kind of like why it's so important in my life. And I think specifically in terms of truffle security, you know, the open source tools that were available to me that allowed me to get into information security in the first place, I felt really the need to continue to give back to that, which is why I wrote the tool and open sourced it in the first place.

And then just seeing how large that community grew and how many use cases there were and how many folks became dependent on it and how so many different folks have contributed to it over the years just made me want to continue to eventually quit my full-time job, like you mentioned, leave Netflix and just continue to support that community and grow it out and continue to give back. No, that's incredible. I really feel the passion and I love that. It's a great story.

And I love the giving back and being part of a community. And through the community, you're going to have a much wider impact than if you just build one thing for one specific use case that you're just super focused on or familiar with. That's very powerful. So thank you.

Thank you for that. I very much appreciate all of that and the background that led you to this. So that's very cool. I had no idea that you could minor in, or maybe even major now in open source communities like that.

That's also very cool. Yeah, so they were the first open source program nationally, and they started with a minor, but I think other universities have since gotten involved. And I think there are universities that allow you to major in it. I mean, it's a big space, you know, learning about the different licenses, learning about contributor models, learning, you know, different ways that communities can grow and how communities can become toxic and all these, you know, there's a lot of different areas to dive into.

And I think also, like, open source is only becoming more and more popular. It's become the dominant operating system. It's starting to take over our infrastructure as well. Like we see, you can't think of using a database these days without it being open source.

So I think, you know, it's going to continue just to become more and more popular. And so it totally makes sense to me that that would become a more focused area in people's studies as they get into technology. I know it makes perfect sense. And I even heard someone, you know, say once, I think it was a VC actually, some managing director, managing partner, he was like, oh, if you don't, if you don't build a strong sense of community, then you will be commoditized and you will be a commodity and then you'll be priced out of the market.

But if you have a strong sense of community, you'll always have the community. There will be one community that will be part of your value proposition, actually. Yeah, there's definitely lots of value in community, but I think one part that maybe some folks maybe misunderstand when they want to go make an open source company is, it's not your community, right? The community is its own thing.

You're just a part of it. And so, like, the community itself, of course, is valuable and you get to give back and contribute to it. But, you know, to do it right, you're not the dictator of that community and you're listening to them just as much or if not more than hopefully they're listening to you. And I think that's the really important piece to us or to me is just, it's a level playing field.

Exactly, yeah. Being able to hear folks and to be able to build, you know, based on ways that I think can help and give back and not just ways that can to sort of turn this thing into some sort of a money machine or monetize, you know, thou shalt this or that. As, okay, so as you built this and you saw the community sort of show up and grow around what you were, what I guess you had started, but then the community has a life of its own. Was there a moment in time where you knew it was the right time to leave your day job and really just focus on building out this community and ultimately a company around truffle security?

Yeah, so I think the global pandemic hit and I had nice health insurance and I said, now's a really good time to give up that health insurance. No, I mean, so I mean, the reality is, I think, I think I probably, in hindsight, wish that I had done it sooner. I wish that I had been able to be more involved with that community earlier on, but I think we still did it at a really good time, myself and my co-founders. And I think I'm just really glad right now to be able to continue to grow and give back.

And, you know, it's never too late. And so I'm really excited to see what we're going to do in the next year or two. We have insurance now, so. Well, this is good.

I'm super happy for you. This is important. I, you know, with Peacemaker, we were on a very similar timeline. I was like, oh, health insurance, who needs that?

And so I understand completely. I really appreciate the joke. So, so far, what has been your best day in that entrepreneurial journey with truffle security? Hey, I think.

Honestly, it's just hearing all the different stories and use cases that folks have had with TruffleHog over the years. You know, I hear it kind of napkin math before that, back of envelope, like off the cuff, but now just being able to talk to folks all day about it and just hearing all the different wild use cases and the exciting bug bounty stories that people have had and the different ways people have used the tool over the years. I think it's been the most interesting to me, and I think like just being able to sit down with people and hear about those stories and hear how many different ways people have been able to use the tool, that's really been the best times for me.

That's awesome to see the impact and to really feel it and be surprised of how people pick up your technology and use it. Has there been one in particular that really resonated with you and you were like, oh, you've caught yourself totally by surprise, but in a very pleasant, happy sort of way that you could help? There's an intern that I worked with when I was at Salesforce, and she went on to work at Airbnb.

And then when she was at Airbnb, she took TruffleHog and operationalized it and then continued to give back, contribute, build new features, and just, you know, being able to continue to work with her through that community, even though we weren't at the same company, but still having that connection and still having that collaboration opportunity was an awesome experience. And I think that's really the power of open source is you have two different companies that are in no way would otherwise be working together.

And sometimes you have, you know, competitors as well, still able to come together within this sense of community and contribute and collaborate on some form of tooling and help make everybody more secure in that capacity. No, I love that. I love how it just brings people together and you can collaborate and help solve tough problems with others and really make the world a better place, more secure place at the end of the day for everybody. It's very, very altruistic.

And it gives a strong sense of meaning and purpose when you're contributing and working on an open source project like that, that you just don't get any other way, right? Yeah. And I think there's also like a sense of trust that you get from open source as well. Just being able to know that it's all out there in the open, not to say that open source projects can't have vulnerabilities, like they certainly can, but I think just being able to come to the table with a certain level of transparency, I think really helps with just trusting tools when you go to use them.

You know, it reminds me of whenever I'm at a big company, I find myself mentoring and I always encourage them to think about the stuff that they learned. Always learn as much as they can, but to think about the stuff that they learned in two very distinct categories. One of them is transitive knowledge, knowledge that you can bring with you to your next gig or bring with you along your career. It's something that will continue to exist and be useful for you, like in the long run.

And then non-transitive knowledge, where it's just, you have to learn something just to learn it. Maybe it's a legacy system, it's proprietary, and it's dead end. Like you'd never work on it again. And I think of open source as being a great way to increase your transitive knowledge and build up your toolbox that you can actually bring with you as you develop your career.

You can bring those tools from one gig to another gig to another gig. So given a choice between an open source project or some proprietary thing, I always will choose the open source project. Just from a professional sense, it's transitive knowledge you get to bring with you to your next thing. You learn it, you understand it, you understand the problem that it can solve.

You don't have to solve it yourself again. And a proprietary thing, you can't, it's just, there's no bringing it with you. So unless you plan to stay at the same company, you know, your entire career, those things just disappear. I think that's absolutely right.

And especially for folks earlier on in their career, when they first go to join a company and they just are energetic and want to learn everything they can. I think if they take the advice that you just gave and just focus on the tools that are going to be available to them beyond their current company, it's just going to help their career so much more. And it's going to just make them more valuable to the market when they go to look for future jobs.

Because if you have a bunch of experience with Kubernetes and you have a bunch of experience with all these different open source projects that you may have contributed to or built on top of, it's, you know, it's just something that you can pack up and take with you and bring to a job interview and be able to just, you know, immediately smash on day one when you go to that next job. But the flip side of that is if you invest all your time in debt from, you know, larger companies like historical proprietary internal whatever, you end up contributing to that debt, which is harder for that company to go out and hire for.

And you end up boxing yourself in because when you go to look for that next job, if all you have to speak about is this internal proprietary stuff, it. . . to have those conversations and harder to prove how you're able to prove your value to the new company if you don't have that familiarity with those other tools that are shared between the two.

Right, that's absolutely true. It's been my experience 100% here in the valley. I guess there is something to be said about being able to identify patterns and see the patterns repeat them. At every opportunity that I have to rip out a proprietary system and replace it with something that's open source, I do it.

I just do it. It's not even a question in my mind. But sometimes it takes a little finessing, a little bit of political dancing. It depends on the organization that you're part of.

But usually it's better for everyone. It's better for the engineers. It's better for the company. It's better for the customers.

It's better for the new people that are already part of that team. Yeah, that really resonates. So if you fast forward just a little bit into the future, or however much into the future you'd like to fast forward, I'll leave this up to you, like five years, maybe 10 years, whatever. What does success really look like to you for Truffle Security?

Yeah, I mean, I think I'm just really excited, and I know I've mentioned it a hundred times already, but I'm just really excited to give back. And so success for me is just being able to look back and say, you know, look at all the different ways we've been able to help the community. Look at all the folks new to security. We're able to give them tooling and get them, you know, experiences and get them ramped up with security in ways that they didn't have exposure to in the past.

And to be able to just give, you know, tools and scripts and all sorts of things, you know, in the future, talks and blog posts and all this and that to be able to just continue to grow and help the community that helped me get involved in security in the first place. And I think that's what I was most excited about jumping into this and doing it full time. And I think that's the part that would be, I'll hopefully look back on and be most proud of, is just being able to do that. Yeah, to take the and to really give back meaningful and concrete ways to the community.

Would you recommend if there is anyone out there thinking about dabbling around or trying to solve a tough problem, maybe building an open source thing around it, any advice that you would give? If you're building a tool and you think others are going to get value out of it, like you should probably bias towards open sourcing it, I think. Even if you're on the fence about whether or not other people are going to use it or whether or not, like, you may give the competitive advantage away to somebody else. Like, I definitely think like folks should not be as concerned with those things and lean more into just putting it out there and seeing what happens.

And if it takes off, it takes off. And if it doesn't, then there really isn't much harm with having open sourced it. And so that's kind of my advice is like the first step, you probably want to go to choose a license. org and figure out how the different open source licensing models work.

The reason why is if you just throw code on GitHub by itself, it'll be implicitly all rights reserved and other folks won't actually get to use it. So you'll want to figure out what open source license is right for you, whether or not it's important for that code and the derivations of that code to stay open source or something like copy left, or whether or not you just want it to be totally open and anyone to use it for any use case. So something like MIT or Apache to learn those differences and pick your license. You're going to want a code of conduct.

So to be able to say how folks can interact with this community to make sure that you don't have issues with folks harassing members of the community and things like that, you want to be able to lay out what's appropriate conduct so that you can enforce those rules and have something to point to when people break those rules. And you know, you want to have a couple of other like standards for how folks should engage with you and things like that. And GitHub walks through all of these things these days. If you go to the community tab, it's got basically a checklist of different things that you want for a good, strong, healthy open source community.

So that's the getting started kit in a nutshell, I guess, is like I would bias towards open sourcing something if you're on the fence about it. I would say, you know, do a little bit of homework to figure out what license is right for you. There's some really standard code of conducts and ways to engage and things like that that you can just one click add to your repositories in GitHub or copy paste them in. And those things are definitely important.

But that's, you know, for someone who's looking to get into open source, those are the fundamentals there is bias towards open sourcing it, figure out the right license, and then add the ways for folks to interact in the code of conduct and all those things. Awesome. That sounds like a really good starting point for anyone out there curious about open sourcing perhaps a new project or just an idea that they want to see where it goes. And well, hey, thank you so much for your time, Dylan, today.

And thank you everyone for listening and tuning in to the security podcast of Silicon Valley. I'm your host, John McLaughlin, and stay tuned for more episodes in the future. Thanks, John.