Avoid Being Runtime Blind using DeepFactor with Kiran Kamity & Mike Larkin

Welcome to the Test Guild Security Podcast.

Where we all get together to learn more about security testing with your host Joe Calantonio.

Hey it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we'll be talking with Karen all about pre production monitoring for developers and testers using a new tool that I just learned about called Deep Factor. Karen is a passionate serial Silicon Valley entrepreneur. He was the Head of Product at Cisco Cloud BU, founder CEO at ContainerX which recently was acquired by Cisco, founder and VP at RingCube which was recently acquired by Citrix and TedX. Speaker Mike is the author of OpenBSD Hypervisor VMM, guest facilitator at San Jose State University for over 18 years. He's also a serial entrepreneur and founder CTO at Ring Cube, which was acquired by Citrix and he also holds numerous patents. So really knowledgeable folks on the call today. You don't want to miss this episode. Check it out and if you haven't already, head on over to securegale.com and register today we actually have the folks from Deep Factor joining us so you can get a hands on view on how to discover how to inject visibility you need into your applications before it hits production and avoid what they call being runtime blind. So to learn all about that and see all our other speakers and topics, what you need to know to succeed with security from a tester friendly perspective, you really don't want to miss it. You only have like a week left handed over to secureguild.com register today.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components, components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to microfocus.com app security hey Karen and Mike, welcome to the Guild.

Thank you Joe.

Hey Joe.

Okay Karen and Mike, before we get into it, is there anything I missed in your bio that you want the Guild to know more about?

No. I think you did a fantastic job summarizing our bios.

Yeah, it was very accurate. Thanks.

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 the call just at a high level. What is Deep Factor?

Yeah, Deep Factor is a continuous pre production 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.

Nice. 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. You 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?

Yeah, actually it goes back to 2015, which is my last company, Container Expert, 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's now called Cisco Container Platform. Now after I left Cisco, one of the things that I had in mind is while containerization and kubernetes are great tailwinds that enable DevOps and microservices deployment, when Mike and I got together we were thinking what are some other things that inhibit DevOps from truly being realized in today's organizations? DevOps today is dominated by CI tools and CD tools. Those are the two pillars which enable organizations to build fast, test fast and deploy fast. But what is missing today is great 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 pre production monitoring platform that is a turnkey way to. That's essentially a third pillar right next to CI and CD that enables organizations to move fast for confidence.

Nice. So can you just give a flavor for how this would work in a day to day typical developer's life cycle? So the developed code is a part of the ide. So it's pre monitoring or is it after they release to a staging environment where all the juice or all the work is done before it goes into production?

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 SAS tools, software Composition analysis tools, linting techniques. You know, 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, et cetera. 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 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 a 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, 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 into the SecOps teams that give you that kind of visibility around 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 application's behaving. Our goal was there's this clear blind spot. There's good tools for code visibility, there's good tools for production visibility, but there's not very good tools for pre production visibility. So what we observed was happening was that in the pre production world, the buyer is only the head of inch. 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 performance visibility, security visibility and behavior visibility, packaged it into one simple solution, made it purposefully design it so that engineering teams can consume it, and make it so that you can easily integrate into your CI CD process. That is essentially what Deep Factor solves for you.

So Mike, any more technical details you can give to how this actually all works as well?

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 backend service, which then does an analysis on the events that the application has generated and then shows you, gives you these insights. Kieran likes to say we have three different kinds of security insights that we provide. We provide insights for Defective components. So, for example, if your application is inadvertently consuming a component that is down level or has known vulnerabilities, we'll tell you about that. 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've 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, 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's 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 headless OASP zap front end. So we'll allow you to drive 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 the curated insights as well as the component level insights as well.

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, Karen, you see maybe security being in 2020, it seems like a hot topic to me. It seems to be top of mind. A lot of engineers have been speaking with the past year.

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 there. 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% of them earlier. If you're diligent about it and if you have the right set of 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.

Great. Also Mike, you've probably seen this as well more and more companies, I hear developers that 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 flat as well to scan those different components to make sure that there are no known vulnerabilities before it actually goes out the door.

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's an issue. You mentioned 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, this the set or chain of dependencies. 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 of a sudden is making a network connection outbound to some forbidden, forbidden GEO that you've said, you know, my application shouldn't be doing. And you can actually go back with de factoring 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.

So Kieran, I know also I've been hearing a lot about compliance. I'm in a mastermind with some other entrepreneurs and they're always talking about they use Google APIs and they 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?

Yeah, it is absolutely something we're watching for. Joe if you think about what deep factors 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 yeah, your application passed compliance, but we're going to be able to tell you your application did XYZ with this piece of data that could prevent you from getting PCI certified later on those kinds of insights. And it'd be good to know that before you ship your application into production, you know.

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.

Awesome. So I assume when you were building this you've talked to a lot of customers, a lot of potential customers. Why focus in on the pre production piece of it, the staging environment? Did you see were there really gaps being released into production that were being missed and that focusing on this area really would be like low hanging fruit that a lot of people are just overlooking.

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 Personas definitely want visibility into their applications, you know, behavior, security and performance on a regular CICD basis as opposed to waiting till the end of the release. But what we found was that a lot of them, the way 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 DAST tool and IAST tool, and then they would think about taking an APM tool that really was designed for the SRE teams and the cloud ops teams, but then trying to put them on the left so that developers can consume these insights. So there's a few problems with that. Number one, you're using a bunch of different tools. Number two, you're spending a lot of opex 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. It was designed for the operators, a lot of them. So we felt like there was a clear opportunity here if we took the right elements of security, performance and behavior, packaged that into one simple solution, made it extremely easy to instrument your app, and then offered the insights in such a way that the developers and the engineering team can consume it. That is a pre production monitoring pillar product that is missing in the industry today, which is what led us to deep factors creation.

Mikey, shaking your head. Just curious to know what makes instrumentation easy or easier for developers that maybe separate you from maybe some other solutions?

Yeah, 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 an application through launching it with a launcher program 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 inherited from the last guy who 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 the 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 and we'll insert our instrumentation automatically. So basically we just give you a docker file and 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 a 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 our management portal. You simply go through and cut and paste commands. And of course, you can always cut and paste those commands into part of your continuous build system. So super easy.

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?

Yeah, actually, as you mentioned earlier in the podcast, Kieran and I did a previous startup and we did API interception and 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, we set a very lofty goal for ourself here in this kind of instrumentation layer. We said no more than 1% 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 and the file permissions and so on, and we package those up in event, send them to our backend for later processing. Is your application making an outbound network connection? If so, we captured 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, 8 meg of memory inside the application. So it's actually pretty small. Not gigs or anything crazy. So 8meg 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 1%. 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.

Nice. So how actionable is this insight? In the sense that a lot of times developers are overwhelmed the definition of done. They have to get something out the door. Now they have security, performance, behavioral things they need to worry about. Is it on a dashboard? Do they get a report like is there an alert when they go into staging? How does that type of interaction work?

Yeah, so consuming the insights, 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 at as opposed to having them come to our portal all the time. So the first step would be chat ops. So we've baked in integrations into Slack. As soon as your CI CD some bills and your CI system creates the build and your automated testing environment runs, dfactor is kind of just listening like a fly in the wall in your application. It sends that insights. The backend 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 your git, commit ID and the last committer to, you know, wherever possible for whichever alert is possible, so that we can actually do an ad, sign the user in the Slack notification so that the user actually gets notified so they can click on it. And they at that point is when they log into the de 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. The next step would be to file Jira. So we baked in the JIRA integration into the product itself. So they click a button and file a JIRA and after that the triaging can happen out of band and you know, folks in the engineering management team can actually look, go look, triage the jira's and send it to the right releases and whatnot. So our goal is to embed ourselves seamlessly into the dev.

Check in and build and test pipeline and the tooling that is used in that pipeline.

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 at 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 application's using an API that has been marked as unsafe or deprecated. Now, ideally you should have caught this with your static analysis or seeing the error or the warning in your build system. But, you know, 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 then you can go and, you know, fix that on your own. There's 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 CVEs. So the answer is obviously, well, don't use that library or go upgrade it or whatever. So we 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.

Nice.

So this is the security podcast. I've been focusing mainly on the security piece, but like you said, you do mention three main areas. What did you mean, Karen, when you mentioned behavioral insights? What kind of behavioral insights? Being monitored with deep factor?

Yeah, here's some examples. Show, for example, between last Monday's build and this Wednesday's build, your developer, one of the developers that's working 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 touch points 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 touch points of an application because there are so many developers working on a given application. So the factors 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 opening up? What are all the web services, what files is it touching, what APIs is it using? So you get that clear, clear view and then you can act upon it if something doesn't seem right or if something changed between builds.

Yeah, and one comment I'll add there is everything Kieran said is absolutely correct. But now think about that same discussion that he just made extended to all of the components that you imported and all of the components that they imported. So Kieran made a statement. You know, a, 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. You know, 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 applications 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, your application, the time it took your application to process 50,000 requests has deviated from its seven day moving average or its 50 day moving average or its hundred day moving average. Or for example, your application is now opening files at a rate two times what it was last week. You know, 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 you, your application moves into production. So this goes back to what Kieran 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? Well, I can catch that up front now.

So I love how you're comparing build to build. So do you have the Insight to know that developer A checked in code Z and therefore Z is triggering the alert with the new security issue or the new port open or the new, you know, some of the examples you gave. Are you able to do that type of mapping as well?

Yeah, where we are today and where we want to go. I guess let's break that question into two. Where we are today. We have built the first cut of the instrumentation product. We've released the V1 of the product. The next step for us is to take this V1 and evolve it 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 particular issue happened and then doing a git blame on that stack trace on that last line of code that was changed, which will give us the commit ID and therefore the committer 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 or she could assign it to the right other developer to make that issue. So our goal is to kind of 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 will get automatically notified in their Slack channel if something that they did could have resulted in a security performance issue, so they can quickly act upon it.

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 5,000 requests, that it's able to tell you that it used to perform better than it did now. So 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?

Yeah, as Kieran 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, you're writing, and then you're closing it, we can actually tell you is how long it took to do each of those operations. So for example, if today.

The time it took to write so many bytes took 55 milliseconds, and next week it took 155 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 Karen 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.

Yeah, and to add to what Mike said, Joe, you know, things like that are immediately actionable to developers is API response times. Right. Or CPU memory consumption. So we'll kind of boil it down to those fundamentals at the. Especially in our first cut of our iteration, our goal is not to do everything that the APM tools do. We view APM tools as absolute complements to De 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 in the SDLC pipeline.

So that's a good point you make. I know a lot of times in production you look and they have all these APM solutions baked in 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 this other tool or they still need this other tool. How would they know what tools they need then when they are using Deep Factor, what does it replace? What doesn't replace?

Yeah, the shortest way to think of that. Is this a piece of insight that your dev needs before you shift the release, or is it a piece of insight that your SRE team or your ops team or your SecOps team needs so that you can monitor your production button? A simple example would be, you know, you have received a million requests on your, you know, retail E commerce application. Out of that 10 of those process, you know, transactions didn't go through for whatever reason. And what we've noticed that, you know, out of these requests, you know, 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 last release and this Friday's release, two of your APIs out of your 29 APIs have slowed down more than 10%. Now, 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 D factor. If it's the former, use your apm.

So I know I'm running out of time, but it almost sounds like a unifying tool as well. Because you mentioned developers, you mentioned sre, you mentioned. 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 insight to what's going on. It almost seems like that seems like a vision. Am I reading that correctly?

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 product is also priced based on per developer per month. Our model really is we want to be to the runtime behavior what Snyk has done to the code behavior. So Snyk took a software composition analysis platform that there's nothing new with. Software composition analysis was always there. But what they've done is it's a fantastic attempt to make it a so that developers can consume those insights and look where Snyk is right now. And we want to build exactly like what Snyk has done, but for the runtime behavior. So we view ourselves as a nice runtime counterpart or complement to Snyk.

Nice. So I guess if you're 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 Edition? How does this all work?

Yeah, there's three aspects that we considered from a business model perspective when we released Deep Factor, the three aspects that developers care about. One is the ability or the necessity to have a Community Edition. 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 Edition. 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 $25 per developer per month. So if you have a team of a hundred developers, it comes to $30,000 per year, which is way less than what you would pay for a combination of your DAST and IAST and your APM and a bunch of other opex to tie everything together. The second important thing is if you are working on an open source project that is non commercial, Deep Factor standard edition is 100% 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 godifinance 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 Scaffold like Google CI platform called Scaffold 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. But developers can take that open source tool and use it for their own testing outside of dbat.

What's that name again? Cool.

Godeep Finance. G O A T Y Finance. You should find it on GitHub. You can actually go to deepfactor IO and you'll be able to see it under Developer Tools so that it'll take you to the GitHub link as well.

Okay, Cannon and Mike, before we go, is there one piece of actual 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?

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've 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 De Factor comes in. And go check out our Community Edition on the website and if there's any questions, our customer success representatives are happy to help you.

Awesome. Mike, any parting words of wisdom?

Now, Kieran covered it. If you Also I mentioned that on our website we have a sandbox as well. So if you want a super low effort way of experiencing what Deep Factor is all about, check out our sandbox which we've got set up on Deep Factor IO has. As Kieran 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.

Thank you Kieran and Mike for your security testing awesomeness. For links to everything value we covered in this episode, head on over to testguild.com S36 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. And if you haven't already, I highly recommend that you register for Secure Guild, an online conference dedicated 100% to helping you succeed with all your security testing efforts. It's geared towards testers, so if you're new to security, if you really don't feel like you know enough about OWASP or AppSec, or feel like you'll be overwhelmed at a conference that's more geared towards hardcore security professionals or hackers, this is the event for you. Like I said, it is tester friendly. You don't want to miss it. Register today. Head on over to secureguild. Com. So that's it for this episode of the Test Guild Security Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack security testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast.

Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences.

Don't forget to subscribe to the Guild.

To continue your testing journey.