About this Episode:
I believe most teams have a massive gap in their pre-production stage of development. In this episode, Kiran Kamity, Founder and CEO of DeepFactor, and Mike Larkin, Founder and CTO of DeepFactor, will share why Pre-production Observability is critical to ensuring your applications are secure, compliant, and performant. Discover how to inject the visibility you need into your application behavior before it hits production, and go from Runtime Blind to Runtime Ready™. Listen up!
TestGuild Security Testing Exclusive Sponsor
Micro Focus Fortify is the recognized market leader in application security and is the most comprehensive and scalable application security solution that works with your current development tools and processes. Try it today
About Kiran Kamity
Kiran is a passionate serial Silicon Valley entrepreneur and current Founder & CEO at Deepfactor. Head of product at Cisco Cloud BU. Founder/CEO at ContainerX (acquired by Cisco). Founder/VP at RingCube (acquired by Citrix). TEDx speaker.
Author of OpenBSD Hypervisor VMM. Guest Faculty at San Jose State University for 18 years. Serial Entrepreneur Founder/CTO at RingCube (acquired by Citrix). Holds numerous patents.
Connect with Kiran Kamity
- Company: DeepFactor
- Website: deepfactor.io
- Twitter: kirankamity
- LinkedIn:kirankamity
About Mike Larkin
Passionate serial Silicon Valley entrepreneur and current Founder and CTO at Deepfactor. Head of product at Cisco Cloud BU. Founder/CEO at ContainerX (acquired by Cisco). Founder/VP at RingCube (acquired by Citrix). TEDx speaker.
Author of OpenBSD Hypervisor VMM. Guest Faculty at San Jose State University for 18 years. Serial Entrepreneur Founder/CTO at RingCube (acquired by Citrix). Holds numerous patents.
Connect with Mike Larkin
- Company: DeepFactor
- Website: deepfactor.io
- Twitter: mlarkin2012
- LinkedIn: mike-larkin-847a4a1
Don't miss Kiran and Mike at this year's SecureGuild online conference dedicated 100% to security testing. The most tester friendly security conference in the world. Register now!
Full Transcript Kiran Kamity and Mike Larkin
Joe [00:01:54] Hey, Kiran and Mike! Welcome to the Guild.
Kiran [00:01:59] Thank you, Joe.
Mike [00:02:00] Hey, Joe.
Joe [00:02:00] Okay Kiran and Mike before we get into, is there anything I miss in your bio that you want the Guild to know more about.
Kiran [00:02:05] No, I think you did a fantastic job summarizing our bios.
Mike [00:02:08] Yeah. It was very accurate. Thanks.
Joe [00:02:11] Awesome. Cool. So, like I said I just learned about Deep Factor. It seems to do multiple things, so I guess we should start off to call that just a high level. Now, what is Deep Factor?
Kiran [00:02:21] Yeah, Deep Factor is a continuous preproduction monitoring platform that is designed for developers. It provides security performance and behavior visibility seamlessly integrated into your CI/CD pipeline. So that engineering teams can not just release their software at the speed of DevOps, but also release it fast with confidence.
Joe [00:02:48] So as I mentioned, you're both serial entrepreneurs. Before we even go more into Deep Factor. I'm just curious to know why this space? You're obviously smart guys probably looked at what was lacking and then you created a product to fill that need. Obviously, now I'm sure you're getting a lot of good feedback from this. Why this particular tool or product?
Kiran [00:03:06] Yeah, actually it goes back to 2015, which is my last company, ContainerX, which was acquired by Cisco. The product that we built there was a turnkey way to set up a containerized infrastructure so that customers can set up their Kubernetes and other environments in an extremely easy manner without having to put together the hodgepodge of tools required to arrive there. That product is now called Cisco Container Platform. Now, after I left Cisco, one of the things that I had in mind is why containerization and Kubernetes are great tailwinds that enable DevOps at Microsoft as a deployment. When Mike and I got together, we were thinking, what are some other things that might inhibit DevOps from truly being realized in today's organizations? DevOps today is dominated by CI tools and CD tools that are the two pillars which enable organizations to build fast, test fast, and deploy fast. But what is missing today is greater engineering organizations don't just move fast, they move fast with confidence. So you need that fourth pillar, which is monitor fast. That's what Deep Factor provides. And hence we have built a continuous preproduction monitoring platform that is a turnkey way to it. That's essentially a third pillar right next to CI and CD that enables organizations to move fast with confidence.
Joe [00:04:20] Nice so can you just give a flavor for how this would work on a day to day typical developers lifecycle? So they develop code as a part of the IDE. So it's pre monitoring. Is it after the release to a staging environment where all the juice or all the work is done before it goes into production?
Kiran [00:04:35] Yeah, I mean, think of monitoring as having three different elements in a typical engineering SDLC. The first element is you monitor your code and for that, we have good tools today between Sass tools, software composition analysis tools, splinting techniques. We have a good set of tools that monitor your code. The next step is once you've monitored your code, you do Dev testing, QA testing, UAT, and running your application, staging, etc.. And this is an area where a lot of the engineering organizations we talked to and we talked to over 50 of them over the last year or so, a lot of them focus on testing the functionality of the application, but testing the security and the performance of the application usually happens towards the end of the release if that. And in that case, if something important is found, you delay the release or you ship the release knowing that the certain security vulnerability or performance issue kind of exists in your product because you can't delay the release any further. Then the third element of continuous monitoring is when you go into production, you have monitoring tools that are different for performance and for security. You have APM tools that are sold into the SRE and cloud ops teams that provide visibility around performance. You have vulnerability scanning tools that are sold in the SecOps teams that give you that kind of visibility on security. And then you have the occasional pen-testing initiatives that come in every three months, every six months, depending on your organization gives you visibility into how your applications behave. Our goal was, you know, there's this clear blind spot, there are good tools for code visibility. There are good tools for production visibility, but there are not very good tools for preproduction visibility. So what we observed was happening was that in the preproduction world, the buyers only the [??] There's no need to have different tools for security and performance because you're not selling to different buyers. So what we decided was, what if you take the right elements of the performance visibility, security visibility, and behavior visibility? Package them into one simple solution, made it purposefully designed so that engineering teams can consume it and make it so that you can easily integrate it into your CI/CD process. That is essentially what Deep Factor sells for.
Joe [00:06:50] So Mike any more technical details you can give to how this actually all works as well?
Mike [00:06:54] Yeah. The way that we do our instrumentation is a little bit different than some of the other security products that are out there. We do API interception and we monitor what the application is doing and we send that information back as telemetry or event packets to our back in service, which then does an analysis on the events that the application is generated and then shows you and gives you these insights. Kiran likes to say we have three different kinds of security insights that we provide. We provide them insights for defective components. So, for example, if your application is inadvertently consuming a component that is down a level or has known vulnerabilities, we'll tell you about that. And we can also tell you about that at runtime. So it's not just in the build environment. And that helps you for scenarios you built your application properly, but you've deployed it into an environment that's potentially down level or has vulnerabilities known. We also have a set of curated vulnerabilities that we look for. And these are built up from years of research and also talking with security experts, you know, things that we need to look for in applications as developers that sometimes we're not able to do or sometimes we just forget to do. One thing I like to say is if I can give you one security insight into your application that you didn't know before, then I consider that a win. If I can give you two, then that's definitely a win and so on. There are lots and lots of applications out there using lots and lots of vulnerable components. And that's one area that we really shine. The other area of insight that we give you is actually based on the behavioral aspect of your application. So what we've built into our product is we built in a head list OWASP app front end. So we'll allow you to dry off your applications testing externally from our portal so that we can actually monitor what your application does. And we can give you the OWASP insights, as well as security insights, as well as the component level insights as well.
Joe [00:08:43] Very nice. So I think a lot of people may understand the performance piece. But I've been seeing a bigger push now for security. Is there a reason why Kiran you see maybe security being in 2020 it seems like a hot topic and why it seems as if to me it seems to be top of mind of a lot of engineers have been speaking with the past year?
Kiran [00:09:01] Yeah, I think it goes back to where DevOps itself how that has been evolving. The first phase of DevOps was to tie things together, build fast, and make it work. And we've gotten that, I think, with DevOps wave one happening over the last eight years or so. And now the next wave of DevOps is how do you go from DevOps to DevSecOps? Because a lot of these security issues can be caught earlier. Instead of having to wait for the pen testing initiative to happen once in six months, you could catch 80 to 90 percent of them earlier if you're diligent about it and you have the right tools to do it. The ultimate goal at the end of the day is to avoid the number of security issues that show up in production. And now with people increasingly working remotely and all of that, there are a lot of services that are being consumed completely online and therefore the need for security is higher than ever before.
Joe [00:09:50] Great. Also, Mike, you've probably seen this as well. More and more companies, I heard developers that are not really developing software as much as they're grabbing components of GitHub and smashing them together to create a solution. And a lot of those components actually could be infected. This solution sounds like it's a perfect flood as well to scan those different components, to make sure that there are no known vulnerabilities before it actually goes out the door.
Mike [00:10:12] Yeah, that's absolutely right. The way the software is developed today due to the speed that it's developed today, many developers do exactly what you just said, that instead of trying to implement a piece of functionality on their own, they'll simply go and do a Google search or go to GitHub and say, is there a library that does X? Oh, that one looks good. Let me grab that and bring that into my environment. So, yes, that's definitely an issue. There is an issue. You mention the word infected and that's one aspect. So you have to worry about malware, of course, and things like that. We're not necessarily an anti-malware product, but what we will help you find is whether or not the things that you're bringing in are written in a way that the behavior is what you're expecting. So basically, is your application using unsafe APIs? Is your application from a security perspective importing things, even if it's a dependency of a dependency, right? So I imported a module A and it imported module B and it imported module C and so on. How do you actually analyze that? How do you crack that? And today, there really is no way to look at these things holistically from at the build time and say, oh yeah, that this set or chain of dependency is correct. And with Deep Factor we allow you to do that because we have built into that all the dependency checking. So not only will we tell you you're importing something that is potentially doing unsafe things. We'll tell you down the road later, hey, your application all the sudden is making a network connection outbound to some forbidden geo that you've said, you know, my application shouldn't be doing. And you can actually go back with Deep Factor and into the management portal and backtrace where that came from. You can actually say, oh, this came from this module, which was invoked from that module, which was invoked from this module, which was invoked from your line of code that you didn't cause that call to happen. But down the chain downstream, that actually happened based on the modules that you imported. So this behavioral analysis and being able to assign, let's call it assign blame is a powerful part of the platform.
Joe [00:12:03] So, Kiran, I know also I've been here a lot about compliance. I mean, I'm in a mastermind with some other entrepreneurs, and they are always talking about these Google APIs and you have to pay to get this compliance done every month. So I'm just curious to know from your perspective, is this a hot topic? And if so, is this something Deep Factor is also going to focus in on in the future releases or something you have already?
Kiran [00:12:23] Yes, it is absolutely something we're watching for, Joe. If you think about what Deep Factor's goal is we divide our insights into three pillars. Know your app, know your security and compliance, know your performance. The know your app piece is and the know your security piece is what we have built right now. The know your performance and know your compliance pillars are things that we're working on. We are not going to be able to give you a certificate as to a yes, your application pass compliance. But we're gonna be able to tell you your application did X, Y, Z with this piece of data that could prevent you from getting PCI certified later on. And those kinds of insights. It would be good to know that before you ship your application into production.
Mike [00:13:03] Yeah, essentially what it amounts to is we'll be able to give you as an organization supporting evidence that you can give to your compliance auditor. That makes a stronger case for you being certified.
Joe [00:13:12] Awesome. So I assume when you were building this, you've talked to a lot of customers, a lot of potential customers. Why focusing on the preproduction piece of the staging environment? Did you see were there really gaps being released into production that we're being missed and that focusing on this area really would be like low hanging fruit that a lot of people are just overlooking?
Kiran [00:13:32] Yeah. I mean, if you think about we talked to over 50 organizations over the last year, five quarters or so. Our learnings are that most of the head of engineering or head of DevOps type persona is definitely want visibility into their applications, you know, behavior security and performance on a regular CI/CD basis as opposed to waiting till the end of their release. But what we found was that a lot of them, the way they were trying to they were going about getting that insight today, was putting together a hodgepodge of different solutions and still not getting the kind of insights that they wanted. They would have a Dask tool, an IS tool, and then they would think about taking an APM tool that really was designed for the SRT teams in the cloud ops teams, but then trying to put them on the left so that developers can consume these insights. There are a few problems with that. Number one, you're using a bunch of different tools. Number two, you're spending a lot of opaques on trying to put them together and manage all of them. Number three, these tools are really not meant in a way that the engineers could consume. It was designed for the operators, you know, a lot of them. So we felt like there was a clear opportunity here, too. If we took the right elements of security performance and behavior package that into one simple solution, make it extremely easy to instrument your app and then offer the insights in such a way that the developers and the engineering team can consume it. That is a preproduction monitoring pillar, a product that is missing in the industry today, which is what led us to the Deep Factors creation.
Joe [00:15:00] Mike, you're shaking your head. Just curious to know. What makes it instrumentation easy or easier for developers that may be separate you from maybe some other solutions?
Mike [00:15:08] That's a great question. We actually offer you three different ways that you can instrument your application. We have a traditional way of instrumenting application through launching it with a launch program that we offer that we give you. That's for let's call those legacy applications or standalone applications, you know, big pieces of monolithic code that you've inherited from the last guy worked at your company. And you don't know if it's vulnerable or not. You've never done an analysis. You can launch it with a launcher that we give you. The second way to do it and this is by far the most common use case across our customers so far, is we'll actually give you a way to consume a docker file that takes a container image that you've already got with your code in it. And this is probably output from your build environment, from your Jenkins or whatever else you're using. And we'll take that and we'll modify it. We'll insert our instrumentation automatically. So basically, we just give you a docker file in a couple of commands to run. And then now you run our container with instrumentation instead of your other one. So basically what we're doing is we're shimming in our instrumentation library into that container. The third way that we're working on right now. It's not released, but it should be within the next couple of weeks is an ability to seamlessly integrate with Kubernetes. So instead of having to go and edit a bunch of hundred different docker files, we'll simply give you a way to with one single command instrument, your entire cluster. So those are the three ways that we've got for instrumentation. All the ways are pretty straightforward. We have a wizard in the in our management portal. You simply go through and cut and paste commands. And of course, you can always cut paste those commands into part of your continuous build system. So super easy.
Joe [00:16:42] So I guess also when people hear instrumentation they may get a little worried because they always think it's going to add some sort of overhead on their application. Any thoughts on that?
Mike [00:16:49] Yeah, actually. As you mentioned earlier in the podcast, Kiran and I did a previous startup and we did API interception in instrumentation for a virtualization standpoint way back when. And one thing we learned one takeaway from that company is performance is everything. So we had that. We set a very lofty goal for ourselves here in this kind of instrumentation layer. We said no more than one percent overhead. And we're definitely below that. The processing that we do inside the application when we're doing our instrumentation is very, very thin. It's very minimal. Basically, what we're doing is we're looking at your application, what it's doing. Is it opening a file? If so, we collect the file name in the file permissions and so on and we package those up in event, send them to our back end for later processing. Is your application making an outbound network connection? If so, we capture the IP address it's connecting to in the port protocol information. Send that up for later analysis. Is your application listening on a port? So, for example, did you all of a sudden start listening on a port that you weren't listening on yesterday? If so, we grab that information, send it up to the portal for later analysis. You'll see the theme here is later analysis, right? All of the heavy lifting and all of the processing and all of the insight generation is done in our management portal, not inside the application itself. So because of that, our instrumentation layer is super, super thin. We only consume, I think, eight meg of memory inside the application. So it's actually pretty small, not eggs or anything crazy. So eight megs is the number we aimed for and that's the number that we're currently sitting at. And again, we're way, way, way less than one percent. You can count it's down to a small number of CPU instructions to be able to capture all this telemetry. So it's very efficient.
Joe [00:18:27] So how actionable is this insight in the sense that a lot of times developers are overwhelmed? The definition of done, you have to get something off the door. Now, have security performance, a behavior of a lot of things they need to worry about. Is it on a dashboard? Are they going to report? Is there an alert when they go into staging? How does that type of interaction work?
Kiran [00:18:46] Yeah. So consuming the insights is actually very simple. There are a few different ways in which developers can consume the insight and we wanted to make integrations our main goal because we wanted to make sure that we give the insights to where the developers hang out as opposed to having them come to our portal all the time. So the first step would be ChatOps. So we baked an integration into Slack. As soon as you're CI/CD some builds and your CI system creates the build then your automated testing environment runs Deep Factors kind of just listening like a fly in the wall in your application. It sends the insights. The back end analyzes the insights and then if it finds anything, it sends you a Slack notification. Now developers that are subscribed to the Slack notification will see that an insight was found. And our goal is to add a you could comment ID. And that last commenter to, you know, wherever possible for whichever alert is possible so that we can actually do an @ sign to user. And the Slack notification that the user actually gets notified so they can click on it. And they at that point is when they log into the Deep Factor portal where they can see the details of exactly what the alert is and what caused the alert and anything else they need to fix it. From that point, the developer at the next step would be to file a Jira. So we baked in a Jira integration to the product itself so they click a button and file a Jira. And after, the triaging can happen out of hand. And folks in the Jira management team can actually look, go look twice (??) the Jira and assign a thread release and whatnot. So our goal is to embed ourselves seamlessly into the dev field, check-in and build and test the pipeline and the tooling that is used in that pipeline.
Mike [00:20:26] And I think to answer your question, Joe, about actionable alerts, we're definitely aware that tools like ours or in the same space as ours frequently will get dinged for having information overload. So we want to make sure that all of the insights and alerts that we gather and provide to our customers are actionable and that they're easily understood and get not too much information overload. So I'll dive a little bit into how we do that. The first type of alerts that we talked about it, the type of insights that I talked about earlier, we're calling the curated alerts. So these would be like, you know, for example, your application is using an unsafe API. And that's pretty easy for us to be able to tell because of the position we are in the application stack. So we'll be able to tell you, oh, your applications using an API that has been marked as unsafe or deprecated. Now, ideally, you should have caught this with your static analysis or seen the error or the warning in your build system. But let's be honest. Who goes through and looks at build logs, right? I mean, they could be like millions of lines long. So we're the safety net here. We'll tell you if you're actually using this API instead of whether or not it just appeared in your source code. So that's pretty easy for us to give you an actionable statement. We can just simply say, oh, you're using an unsafe API and here's the location and you can go and fix that on your own. There are other things that are other types of alerts like our composition alerts for dependencies that we talked about earlier that may have vulnerabilities. That's a pretty straightforward, actionable alert as well. We'll just simply tell you, your application loaded this library and this library has the following 10 CDEs. So the answer is obviously, well, don't use that library or go upgraded or whatever. So we'd like to make sure that all of our alerts have a how do I fix this kind of description? And to that extent, that's how we give you actionable insights.
Joe [00:22:14] Nice. So this is the security podcast. I've been focusing mainly on the security piece, but like you said, you did you mention three main areas. What did you mean Kiran when you mentioned behavioral insights. What kind of behavioral insights are being monitored with a deep factor?
Kiran [00:22:27] Yeah. Here are some examples, Joe. For example between last Monday's build and this Wednesday's build, your developer, one of the developers that are working on it on your application, created a new web service or started using a new PayPal API, or opened a new port in your application. These are not by themselves security issues. They're not performance issues either. So we classify them under behavior. And these are things that I think you need to know so that you understand clearly the topology and composition of your application all the touchpoints and get a bird's eye view of everything that your app is touching and doing so that you can act upon it in case something needs to be attended to. A lot of the times engineering organizations don't have a bird's eye view of all the touchpoints of an application because there are so many developers working on a given application. So the Deep Factor's know your app. pillar serves as that bird's eye view so that you can go there and you can say, okay, what are all the ports my app is use opening? What are all the web services? What files is it touching? What API is it using? So you get that clear view and then you can act upon it if something doesn't seem right or if something changed between those.
Mike [00:23:31] Yeah. And one comment I'll add there is everything Kurian said is absolutely correct. But now think about that same discussion that he just made. Extend it to all of the components that you imported and all of the components that they imported. So Kiran made a statement. You know, a developer started using a new PayPal API. Well, maybe the developer didn't start using a new PayPal API, and all of a sudden that API started to be used. Where did that come from? How did that happen? So the ability to take two different builds and analyze the behavior between them is very powerful. And that's something we have in the platform. Is your application's behavior drifting over time? You used to be doing this and now you're doing that. So there's the behavioral insights are one thing, but the other aspect of behavior is my application behaving slower and that is part behavior and part performance. But we can actually tell you, you know, your application, the time it took your application to process 50000 requests has deviated from its seven day moving average or its 50 day moving average or 200 day moving average. Or, for example, your application is now opening files at a rate two times what it was last week. Is that something the developer did or is that something that was a behavior that was brought in from the environment or a component or something else? So we'll give you that insight. And those are important to catch before your application moves into production. So this goes back to what Kiran was talking about earlier. There's this blind spot that, hey, I didn't know my application was going to start opening files at 10 times the rate that it did last week. So why is my performance bad? Why can catch that upfront now?
Joe [00:25:03] So I love how you're comparing build to build. So do you have the insight to know the developer check-in code Z and therefore Z is triggering the alert? What the new security issue or the new port open or the new you know some of the examples you give, are you able to do that type of mapping as well?
Kiran [00:25:19] Yeah. Where we are today and where we want to go, I guess let's break that question to [unintelligible]. Where we are today we have built that first kind of instrumentation product. We have released to be one of a product. The next step for us is to take this be one and evolve by adding the flows that you just described. What you just described is exactly what our goal is, because we can arrive there by looking at the stack trace where ticket or issue happens. And then doing, I get blame on that stack trace on that last line of code that was changed. Usually, give us the comment ID, and therefore the commenter that changed that line of code last. And then we could show that as part of the Slack notification and then that developer can look at it and see if that's what caused it. If not, he could he or she could assign it to the right other developer to make that issue. So our goal is to kind of hat build a pull mechanism in the product as opposed to a push mechanism, which is what the first generation of instrumentation products typically have. So here our goal is to build a pull mechanism so that the developer themselves can get automatically notified in their Slack channel of something that they did could have resulted in a security performance issue so they can quickly act on it.
Joe [00:26:26] Nice. So I know it's very ambitious. I know you mentioned performance and performance is not baked in yet, but Mike you did mention something about when your component gets 5000 requests, that able to tell you that is used to perform better than it did now. So is it does it do the performance test or like how is performance part of this tool and what is the performance piece we're talking about?
Mike [00:26:48] Yeah, as Kiran mentioned, we're still building that into the visibility aspect from the portal perspective. But what we gather as part of those telemetry events that I talked about earlier is the time it takes to perform each operation. So let's take files as an example. You're opening a file and you're doing some operations on it. You're reading your writing and then you're closing it. We can actually tell you how long it took to do each of those operations. So, for example, if today you're the time it took to write so many bytes to fifty-five milliseconds and next week it took one hundred and fifty-five milliseconds, what changed, right? Are you writing more? Are you writing less? Did your underlying infrastructure change? Is it a noisy neighbor causing your VM to slow down because they're consuming too much CPU? All of these things are the things that we track. So we have all of that data that we're collecting. And now we're figuring out, as Kiran mentioned, how to visualize that in a way where we can show you these are the operations that are slowing down. And here's why. So today we're collecting that information, but it needs to be visualized in the product, which is what we'll work on moving forward.
Kiran [00:27:51] Yeah. And to add to what Mike said, Joe. You know, things like that are immediately actionable to developers. Is API response time right, or C.P.U memory consumption? So we'll kind of boil it down to those fundamentals ideas, especially in the first cut of our duration (??). Our goal is not to do everything that the APM tools do. We view APM tools as absolute complements to Deep Factor because they are the ones that you need to be running on the production side. They're the ones that you need to be running if you want operators to have a look. Our goal is to provide the right insights so that developers can take a look at it early on dependent and say SDLC pipeline.
Joe [00:28:22] So that's a good point you make. I know a lot of times in production you look and you have all these APM solutions baked in it and cause some sort of bloat. So how do you know like how would developers know or companies know what Deep Factor covers so they know they don't need maybe there's other tool, they'd still need this other tool like how do they know, like what tools they need them when they are using DeepFfactor? What does it replace? What it doesn't replace?.
Kiran [00:28:43] Yeah, the shortest way to think of that is this a piece of insight that your dev needs before you ship to release? Or is it a piece of insight that your SRT team or your Ops team or your SecOp team needs so that you can monitor your production by? A simple example would be, you know, you have received a million requests on your retail e-commerce application. Out of that 10 of those processes, transactions didn't go through for whatever reason. And what we've noticed that you know, is out of these requests, some requests were slow and whatnot. That is an immediate action item for the SRE team because it's an operational kind of question. But if you get a request that says if you get visibility, that says between the last release and this Friday's release, two of your APIs out of your twenty-nine APIs have slowed down more than 10 percent. And that's a piece of insight that your dev needs to look at because it's most likely because of a code change that happened between those releases. So if it's the latter use Deep Factor, if it's the former use your API.
Joe [00:29:44] So now I'm running out of time, but it almost sounds like a unifying tool as well, because you mentioned developers, you mentioned SRE, and a lot of times they're still kind of walled-off almost, but almost seems like it puts everyone together in a dashboard. So everyone has insights. What's going on? It almost seems like that seems like a vision. Am I reading that correctly?
Kiran [00:30:02] Well, with a slight twist, our focus is really to be developer-focused. Our focus is to give that visibility to the engineering teams. Our focus is not as much to give focus to the cloud ops team, which reflects in how we're pricing the product, how we're selling the product. The products also priced based on per developer per month. Our model really is we want to be to the runtime behavior. What Sneak has done to the code behavior? So Sneak took a software composition analysis platform that there's nothing new in software composition analysis. It was always there. But what they've done is it's a fantastic attempt to make it so that developers can consume those insights. And look where Sneak is right now. And we want to build exactly like what Sneak has done but for the runtime behavior. So we view ourselves as a nice, strong time counterpart, a compliment to Sneak.
Joe [00:30:51] Nice. So I guess if your targeting developers, a lot of them seem to be all up into open source solutions. So I don't know. I don't think we touched on this at all. So what is your pricing model? Is there a community addition? How does this all work?
Kiran [00:31:03] Yeah, there are three aspects that we considered from a business model perspective when we released Deep Factor, three aspects that developers care about. One is the ability or the necessity to have a community addition. So we have a free 10 user. If you're 10 users or less, you can use Deep Factor absolutely for free. And that's our community addition. It's actually almost full-featured as of today. The paid edition, which is a standard edition, is charged based on the number of developers so it's twenty-five dollars per developer per month. So if you have a team of 100 developers, it comes to thirty thousand dollars per year, which is way less than what you would pay for a combination of your desk and I asked in your APM and a bunch of other opaques to tie everything together. The second important thing is if you are working on an open-source project that is noncommercial, Deep Factor Standard Edition is one hundred percent free for you. This is our way of making sure that you know the folks that are working on open source we're supportive of them and Deep Factor is useful to those open source initiatives. Number three is we ourselves have created a few developer tools that we have open-sourced just recently, just last week actually. An example of that is what we call a Goaty finance application. It's a goat. It's a vulnerable application that we've created. It's a stock ticker application that has a bunch of known vulnerabilities in it. It's Kubernetes first. It uses the Skaffold like Google's CI platform called Skaffold S-K-A-F-F-O-L-D to make it easy for you to kind of deploy your Kubernetes application, but it's a known vulnerable application we baked in a bunch of known vulnerabilities into it. So that's the kind of app that we use for our own testing. The developers can take that open-source tool and use it for their own testing outside of Deep Factor.
Joe [00:32:45] What's their name again?
Kiran [00:32:46] Goaty finance. G-O-A-T-Y finance. You should find it on GitHub. You can actually go to Deep Factor's, deepfactor,io and you'll be able to see it under developer tools. So they will take you to GitHub link as well.
Joe [00:32:57] Okay Kieran and Mike, before we go, is there one piece of actionable advice you want to give to someone to help them with the security testing efforts? And what's the best way to find or contact you or learn more about Deep Factor?
Kiran [00:33:09] Yeah, the best way to reach us is deepfactor.io And the action item that I would kind of question or challenge some of the DevOps folks out there is you have implemented CI and you have automated your testing environment. That is great. These are things that will help you move fast. Now, in order to move fast with confidence, you need to bake in the SEC into your DevOps to turn it into DevSecOps. And that's where Deep Factor comes in and go check out our community addition on the website. And if there's any questions our customer success representatives, they're happy to help you.
Joe [00:33:39] Awesome. Mike, any parting words of wisdom?
[00:33:41] No, Kiran covered it. If you'd also I'd mentioned that on our website, we have a sandbox as well. So if you wanted a super low effort way of experiencing what Deep Factor is all about, check out our sandbox, which we've got set up on deepfactor.io. As Kiran mentioned, it has our vulnerable app catalog there. So you can see the types of insights and alerts that we would give to your own apps.
Rate and Review TestGuild Security Podcast
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
