Here is the rough, unedited transcript of the show…

Swapnil Bhartiya: Hi, this is Swapnil Bhartiya, and welcome to Let’s Talk About Security. Deepfence is a security observability platform for cloud and container-native EcoSys environments based on security as microservice model. Deepfence measures and maps runtime attack surfaces and provides full stack protection from known and unknown threats. That’s all I know about the company because this is the first time we are interacting. But to learn more about the company and their open-source tool, we have with us two guests from the company: Sandeep Lahane, Founder and CEO at Deepfence, and Owen Garrett, Head of Product and Community. Sandeep, Owen, it’s great to have you both on the show.

Sandeep Lahane: Absolutely, Swapnil. Excited to be here.

Swapnil Bhartiya: Sandeep, since you are the founder of the company, I want to understand from your perspective, if you look at security, it’s a crowded space. It’s a busy space. It’s also evolving space. So what unique challenges that you saw, and you are like, “Hey, no, this is the unique proposition that we want to bring to the market,” that you created the company.

Sandeep Lahane: Absolutely. It’s a crowded market, and I think it’s going to get even more crowded. If you look at last few years, last few months, the number of breaches that you hear, it just going to get busier. Deepfence was built to protect the cloud-native continuum, Swapnil. We don’t look at cloud-native continuum as one modality. We look at it as a continuum of technologies. You’ve got mediums, you’ve got capabilities, you’ve got serverless, all of it, really, and where we deferred from most of the vendors in the space is our core technology, which is cloud-native deep packet inspection which let’s you monitor what comes in, what goes out, and what changes across time and space and across multiple modalities. You don’t need a separate solution just for Kubernetes or just for AWS. We’ve got it all covered for you, the whole cloud-native continuum, as well as across multiple clouds, right?

So we are squarely, singularly focused on the runtime and production which is where that stuff happens, really, and the core IP essentially is basically about deep packet inspection, including plaintext traffic as well as encryptic traffic, right? That’s our core IP, and how do we sort of go on making a more well-rounded solution is by adding some of the other sort of table states, which is your vulnerability scanning, supply chain security, compliance enablement, and all of that, essentially, but why our customers love Deepfence is because the sort of security observability we provide at runtime using our core technology, right? It illuminates everything, essentially. My good question to CISOs in my security practitioner software is “Hey, are you certain you seeing that at runtime across all of these modalities?” Right? Sure, you can put in a proxy, and you’ll be able to see a lot of edge ticket traffic going in, but then proxies have their own inherent problems. There is a scale issue, all of that. We do completely out of [inaudible 00:02:53], Swapnil.

Absolutely everything I mentioned is completely out of pan. We rely on EVPS to do this low-level testing. There’s, of course, a machine learning bit which sort of brings it all together really.

Yeah, I hope that sort of answered your question.

Swapnil Bhartiya: It did answer my question. One thing that I also want to talk about as quickly is that if you look at cloud-centric, containerized security versus if you just look at … I don’t know if legacy is the right word or [inaudible 00:03:18] is the right word, how different is cloud-native security? Because the challenges are different which also means the approach has to be different, too.

Sandeep Lahane: Oh, well, absolutely. It’s a whole new world. It’s a whole new world, essentially, and retrofitting some of these legacy mechanisms, really, just doesn’t work. I mean, it gets you just so far, and the infrastructure is evolving at a pace. You cannot have modality-specific solutions either. See what I’m saying? So that market, I think, while it’s an evolving large market, we feel it’s severely underserved at this point in time.

Swapnil Bhartiya: I will go back to the point you used the word “security” and “observability,” and that’s really important because we have … and sometimes there’s overlap happening in these two spaces. Observability may tell you what’s going on wrong, but then you have to have understandability. You have to actionability; you should be able to do something, and that’s where overlap happened. Okay? Okay, I do know something is wrong, but what do I do about it? So when I look at Deepfence, do you just know across the … or it’s like a bridge of both words? Is it the same word, we are using different labels? Talk about that.

Sandeep Lahane: Well, that’s such a beautiful question, Swapnil. In fact, security, observability, observability, deep observability enables deeper detection, which in turn enables better protection, certainly. What we are doing is instead of going horizontal with this, Swapnil, security and generative observability, we are really going deeper in security observability. There’s just a difference of an [inaudible 00:04:46] percent here, right? Security observability versus security and observability, we are singularly focused on building observability to protect better, which in turn, basically, means better protection.

Swapnil Bhartiya: When we talk about security or any other more technologies, there are two aspect. One is human aspect and one is technology aspect. When human aspect, especially in the terms of security, just there are bucks, but most of the issues also crop from misconfiguration or way too much rights or all those things also happen. So when we look at Deepfence, you can build technologies, but what about human limit? How do you also take care of the culture aspect of security as well?

Owen Garrett: Yeah, yeah. I’ll talk a little bit about, Swapnil. So the culture aspect of security, security is top of mind for anyone building and operating applications today, and there’s been a huge amount of investment from this recognition on the shift-left initiatives, so moving security to the development and DevOps teams, and there’s been great innovation in this space providing code scanning, vulnerability scanning, security as code, infrastructure as code, and various automation tools. That’s been a fantastic step forwards to help organizations build more secure applications, but these shift-left initiatives tend to stop once the application is moved into production because once it’s in production, it’s managed by a different team. There is a different group who are responsible for the security of the production platform as a whole, and that’s because the development team are then moving on and they’re building the next big thing. They don’t have the direct responsibility for their production platform.

You asked about some of the legacy solutions that are present to help secure production platforms. Those really don’t fit in today’s cloud-native world. They’re not fast enough, they’re not agile enough, and they don’t really talk the language that the DevOps team and the development team talk. They produce outputs that’s useful for a traditional network-focused security team. So what we felt is that shift-left only solves half of the security problem. There needs to be a way to carry that security across into production and the existing production security tools don’t really fit in today’s cloud-native space, and that’s where Deepfence comes in. We bring some of the technologies that you would use when you shift left, things like vulnerability scanning and compliance scanning, and we run those in production against production workloads.

So we will find and identify vulnerabilities that weren’t known when the application was written, when it was linked together and when it was shipped; maybe a late breaking vulnerability that was only announced yesterday. We’ll pick those up automatically in the production system, and we map those to the applications, to the containers, to the hosts, so we give the security team the information they need to go back to the development team and not say, “We scanned your code and there’s 2,000 vulnerabilities. Can you fix them all?” But instead say, “We’ve scanned it with Deepfence ThreatMapper. We’ve identified the top three or four vulnerabilities that pose the greatest risk of exploit, and these are the ones which we need you to focus on for the next release.”

So we give the production team the tools, the automated tools, the information they need, so they can identify what needs to be fixed first with the code that’s running in production.

Swapnil Bhartiya: Excellent. Thanks for explaining that, and there’s some funny stuff there, and which is that when we talk about this whole paradigm shift from developers to DevOps to DevSecOps stories, and we are like “Hey, we are breaking down old silos,” but the fact is we are kind of creating new silos, as you just said, that once the application moves into production, it becomes someone else’s problem, but what we used to talk about, “Hey, you know what, security is not someone else’s problem. It’s my problem,” but we are creating new silos, and then you also said the security teams talk to the production team. So we are still … and that’s where I was talking about there are still … so when we do expect in the cloud-native world, we talk about, “Hey, you know what? Security is no longer an afterthought. It has becomes everybody’s problem,” but that is not the reality.

So when we do talk about … even when we talk about CISOs, they have those. So talk about what kind of culture are you seeing? We can talk about it, all the paradigm shifts that are happening culturally, but what is the reality? Because you folks cannot go by the trends. You have to look how companies actually operate.

Owen Garrett: That’s right, and the reality that we see is that companies want to institutionalize security. They want security across all of the silos, but as you rightly said, these silos exist, and they exist because different people have different skills and different roles. People aren’t unicorns; people are best when they focus on what they do particularly well. So silos naturally emerge, but DevOps was the start of an initiative to try and get these silos talking the same language, using the same tools, and automating as much as possible to get rid of institutional knowledge or the dependence on institutional knowledge, and Deepfence ThreatMapper is emerging as one of those tools. It’s used by one of the silos, if you like. So the production-focused, SecOps-focused teams, but it operates in a way that produces output and it interacts with DevOps and standard operational tools. So it breaks down the silos with respect to security, and it helps an organization take its existing shift-left initiative and extend that into production.

Swapnil Bhartiya: Sandeep, earlier you also talked about compliance. When we look at containers, especially, I maybe totally wrong here, most of the companies, they don’t even know what’s running in the containers that they’re consuming and, of course, there are security risk, but also because we are using so many [inaudible 00:11:05] tool, they will not be in compliance. You might expose your own IP, so they should know. We are looking at a software supply chain problem.

So I want talk about ThreatMapper and open-source angle as well, but I want to quickly address that. How do you address that, and how big is that a problem?

Sandeep Lahane: It is a big problem, Swapnil, and I couldn’t put it in a better way than you did, essentially. Vulnerability is just one of that application, known vulnerability. That’s just one of [inaudible 00:11:31], but if you look at one of the most common causes of breaches in the cloud, you see it’s miscalculation: not hardened enough, not compliant enough, essentially. All of these things, basically, the things which enable compliance also, essentially, enable you to be bulletproof in your production, really. Right? So absolutely, and you know what, with ThreatMapper, what you’re really trying to do, Swapnil, is there’s a lot of innovation on the left side of CICD. You have great companies such as [SNCC 00:11:59], who are doing essentially code scanning and enable developers. We really sort of pick up where they leave, get into the middle of the CICD cycle from DevOps, CloudOps, all the way to SecOps team, right?

So we want sort of … We carry forward the baton from the left, from the center, all the way to the right of the CICD, right to the SecOps, really, and compliance, essentially, misconfiguration, I think this is the right place to sort of look at it because it’s a runtime phenomenon, really. Right? I mean, you misconfigured things and somebody exploiting in production, really. Right? So that’s a spot. And I think, you know what, if you look at this whole journey, I spoke about the far left, the center, the left of center, the right of the center and the right, which is where SecOps is; the left part is really well-served. What is underserved still, and the community just didn’t have enough … sort of a powerful tool to do that, that’s a need ThreatMapper is filling in, essentially. Right?

[inaudible 00:12:57] in the middle of the CICD, stay with you throughout the product. Think of it as like this, right? And I always love to give this analogy, which is $250 billion per year, public cloud spend. There is not even a single community tool, Swapnil, which lets you visualize multiple clouds and multiple cloud modalities, right? What is going in the connection to services? There is nothing at scale. Sure, you have some projects which are coming up, but that’s where we really start. We say, look, let’s see what you have running across multiple clouds, across modalities, and then on top of that, let’s go after the most common causes that sort of … breaches, be it known vulnerabilities, be it compliance failures, all of that. That’s the whole sort of spectrum of activities we want to cover with ThreatMapper.

Swapnil Bhartiya: You folks also open source ThreatMapper. Before we talk about ThreatMapper, I also want understand how important is open source for Deepfence? How much do you care about it?

Owen Garrett: So, Swapnil, we care deeply about open source, and the reason for that is really simple. Security, we believe, is a public good, the financial or economic definition of a public good. It’s something that everybody should be able to benefit from, something that everybody collaborates to create, and indeed, the resources, many of the resources that we use within our open-source product are public goods in their own right. [MITRE 00:14:22], a US federal agency, they manage vulnerability lists and operate the National Vulnerability Database. Compliance is executed through tools such as OpenSCAP, Security Content Automation Protocol, again, an open-source and federally-funded program. A lot of the knowledge, in fact, 99.9% of the knowledge that security tools use whenever they scan for vulnerabilities or look for compliance breaches, that knowledge is based on public open-source common knowledge, and the sad thing is that it’s very difficult to take that knowledge and apply that easily within production, to take vulnerability lists and run those against production workloads.

What we’re aiming to do with our open-source platform is to take all of those community and public resources and build an easy to deploy, easy to use, safe and trusted platform that will allow anybody to use the open-source technology to scan their applications, find and prioritize vulnerabilities, and visualize what’s happening within their application estate.

Swapnil Bhartiya: Thank you. I love when you said security is kind of public good because when we look at a lot of security companies, they don’t talk about open source. They’re like “Hey, no, open source is not the space that we operate in.” So that’s refreshing to hear. Now, you have also released a lot of your code under open source. What happens is when you release your code under open source, you lose control over it because it depends on how … of course, it depends how you manage it. You can do open core or whatever you do, but you hand it over to a community which also means that a lot of times what your business needs, you cannot push those changes because you have to make everybody happy. You cannot move faster also because the whole community has to have their own word there. So why, what value you see? Why do you release your code into open source and you can have full control, full influence, and full [inaudible 00:16:33] with that?

Owen Garrett: That’s a really interesting question. So I encountered exactly this challenge when I worked with the [Nginx 00:16:42] team previously. Nginx has emerged as the world’s premium open-source web server, and we looked to build a business on top of Nginx, and we did that very, very well, but other companies, organizations like CloudFlare or Kong, they also built on top of Nginx and built businesses that were even more successful than ours within their space. So part of the nature of open source is that you have to accept that if you’re creating something for the common good, then people will benefit from it and they will use it. You can’t afford to be greedy and try and keep all of those benefits to yourself. You have to allow the community to flourish. And if it does flourish, that is the signal that you’re doing the right thing for the community with your open-source technology.

What we’re doing at Deepfence is a little bit different to the traditional open-core approach. The open-core approach is very common with open-source projects where the open-source project is a subset of a larger closed-source commercial product. And although that’s a viable way to build an open-source business, it’s not the best way to encourage the community to contribute because there’s always the feeling that some of the technology is going to be held away from them, put behind some sort of paywall or commercial wall, and they can’t benefit from it. So we’re taking very deliberately a different approach at Deepfence. The security observability technology that we’ve talked about, our commitment is that that will become part of an open-source platform, something that’s 100% open source, and a platform because the data that we gather, we will also make available through a series of APIs. What this then allows us to do and for other agencies to do is to build products and tools that are separate to the platform, talk through the API, and those are tools that in themselves could become commercial and monetizable.

So we have on the one hand a 100% open-source platform with no barrier to adoption, no barrier to engagement, and on the other hand, the opportunity to create extensions that are standalone and separate from the platform and talk through public APIs and to create a level playing field. So we can do that. But in fact, if other organizations do the same and create other tools to address different use cases, then that’s just a sign of success of our platform.

Swapnil Bhartiya: It’s an open-source project, as you explained. So the roadmap is already there on GitHub. People can go and see it, but if I ask … because you have more insights than people who are consuming the code, what are the things that you are working on? What are the things in the pipeline? The only thing that pandemic taught us was don’t talk about one or two or three years. So just talk about six months from now.

Owen Garrett: So six months from now, we want to see maturity of our open-source product in terms of the capabilities that it offers. Our first release will offer the vulnerability scanning in production that we’ve talked about, the ability for the user to find what’s to fix first, but we’re basing this open-source release on technology that we’ve built over the last two or three years, and there’s much more to move across and add. We’ll add in, or we intend to add in, the compliance scanning capabilities so that as well as finding vulnerabilities in applications, users can find misconfigurations and errors in their platform itself, and we intend to add in the sensor capability that we built to discover resource anomalies, to discover integrity issues within an application, so changes to processes, changes to files, but most importantly, very standout feature is to discover what’s happening on the network as well, to use eBPF to extract network traffic and give users the option to process that so they can identify not just whether a compromise has happened, so indicators of compromise, changes in the application, but also identify the signals of attack, the indicators of attack, see what people are doing within the application, sending reconnaissance traffic, sending commands and control traffic, and pick up the tiny little signals so that then you get much greater observability as to what’s happening within your application estate.

Swapnil Bhartiya: You said that the six months, you want to see it production-ready, but in most cases, what I see, and I may be totally wrong, some of these technologies are already in production when you do a lot of users already using it. So can talk about if there is already users who are using in production or no, this is just something you’ve worked on, released it, and you will get it production ready?

Sandeep Lahane: Well, absolutely. Great question, Swapnil, again. So the core technology, what we used to call as the Deepfence cloud native security platform has been in general availability the past one year. We have dozens plus early adopters, customers who are using it to scale, essentially, thousands of nodes. The largest deployment we have seen so far had 40,000 capabilities parts. So it’s pretty, pretty sizable deployments we have. What we are really doing is it was a closed-source product now. With this open-source initiative, what we really released, it had basically two things. One is the attack surface measurement component, which is what ThreatMapper is, and the detection and protection component, which is what ThreatStrike is. We’re basically taking that platform that we already have in production, having two parts of it, and essentially opening up the first part. ThreatStrike is just going to be an add-on on top of this ThreatMapper, Swapnil. So it is going to use the same public APIs that we’re making available for community. If somebody wants to come in and build something like ThreatStrike on top of that, they could. You see what I’m saying?

So that’s the model that we are sort of going ahead with. Yeah.

Swapnil Bhartiya: What kind of use cases are there?

Sandeep Lahane: As an early stage company, Swapnil, who’s had the product [inaudible 00:22:54] for over a year now, we were squarely focused on the mid-market. So the day one cloud-native companies, bonding companies, essentially, the companies are already in the cloud. They’re not moving to the cloud; they’re already there. We focus squarely on those customers. Mid-market, that’s what made sense given where we were as a company, but once we opened this up in a few days, we also started working with much larger sort of customers now. Once you prove yourself, build it for mid-market, I think it’s logical to make that move upstream really. Right? So yeah, and then coming to use cases, predominantly, we are being used for run-time protection, the right side of CICD, which is what I said, the east-west deep packet inspection of traffic, being able to collect all of these signals, overlay these signals on top of the attack surface that you measured, and giving you that really, really final picture; not 1,000 alerts per day, not 500 alerts per day, just one or two alerts which tell you “this is a smoking gun and here is why.” Right?

So that’s essentially where we are. So DevsSecOps, SecOps are our typical sort of users.

Swapnil Bhartiya: Sandeep, Owen, for thank you so much for taking time out today and talk about not only ThreatMapper, not only Deepfence, but also the wider security and observability landscape. And as I said, wish we could have done this in-person but maybe next time, but I look forward to our next conversation because as you said, the company’s new, a lot of things are happening, so I would love to catch up with you guys again. Thank you.

Owen Garrett: Thank you.

Sandeep Lahane: Absolutely, Swapnil. Thank you so much for having us over. Talk to you soon.