EPISODE 1622

[EPISODE]

[0:00:00] ANNOUNCER: Software supply chain security is a major challenge in the modern engineering environment. Many teams are working to establish best practices to proactively identify, fix, and prevent risks in their applications. Apiiro is a platform designed to solve this problem and gives risk visibility, prioritization, and remediation.

Yonatan Eldar is the co-founder and CTO at Apiiro and he joins the podcast to talk about the platform application security, posture management, and more. Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance and general software engineering companies. He has been based in Asia Pacific for almost a decade, and can be found via his profile at vand.hk.

[INTERVIEW]

[0:00:59] GV: Hi, Yonatan. Thanks for being on Software Engineering Daily.

[0:01:03] YE: Hi, Gregor. Thanks for having me.

[0:01:04] GV: Yonatan, it's great to have you here. You are the co-founder of Apiiro. So, could you maybe just describe like, what is your background? And how did you find yourself co-founding Apiiro? 

[0:01:17] YE: Sure. So, my background, I am a developer for the last 20 years, which makes it half of my life, which is kind of scary. Most of my career has been around cybersecurity, and while it was like five years ago, and more, I've worked with Idan, who is my co-founder and CEO of Apiiro, on his previous startup called Aorato, which was acquired by Microsoft, and we worked together there at the startup phase, and then we entered Microsoft, and we grew and we grew and we faced a lot of challenges. We try to run as fast as we can, inside the B Corp, without cutting corners and making things work well. And it was like 2015, cloud was really booming all around, and inside Microsoft as well. Microsoft was pushing Azure. But no one really knew how to balance speed of development and security, AppSec, specifically. And the tools weren't there, the approach, the processes weren't there. Many of the processes were like old world processes, maybe more waterfall-y and mostly manual.

Trying to deliver to the cloud every day, or even every week, with us having to fill out the form, or doing like questionnaires and stuff like that. It didn't fly. On the personal note, Idan is a group manager. He led the business and myself as an engineering manager. It wasn't fun. It was depressing, knowing that like a better part of my week was bureaucracy and trying to shield my team from boring tasks of going through endless lists of vulnerabilities, without context, without any guidance on what they should be doing. There are worse things in life, but it's no way to run fast and deliver value to customers.

So, this was our experience inside Microsoft, by the way, which was a good, like Microsoft was a really good experience for us. I personally learned a lot. But during this journey, we felt that the AppSec market needs a jolt in the system, and when we started Apiiro, we validated with a lot of companies in the FinTech world, in banks, like big companies, smaller companies, and we saw that everyone faced the same struggle. Too many vulnerabilities, too much noise, too many repositories to control, too many developers to know who is doing what, who is responsible for this thing, and for that thing. We knew that a change is coming in the market. A few years after we started, like Gartner coined a new abbreviation called ASPM, and everyone started to see that this is the direction to go. So, maybe this is like, I summarize the few years of my life, but it's still a long answer to how we got started up here.

[0:04:21] GV: I think that's really interesting and I'm glad you did kind of cover all those. I imagine a lot of people listening can relate very closely to what you've just been saying. And I imagine also for many, the relating today with what you're saying that a lot of things you were saying, that was frustrating, and that was frustrating, is actually the present tense for a lot of people listening today. That probably leads quite kind of nicely into, I guess, where you've probably gone with Apiiro, but let's just give us a high level, what does Apiiro do? And why would a developer be interested in going with a platform and indeed, maybe also an engineering manager as well?

[0:05:01] YE: Okay. These are two connected topics that I'll start with the one and then the other. So, ASPM in general, is trying to provide a holistic view, AppSec view into what you have in your organization. Not an aggregation of siloed tools. For 20-something years, we've had SaaS tools, various SaaS tools, scanning for vulnerabilities. The last 10 years or so, we've had SCA tools doing the same thing for open-source code. Lately, other tools like API security and software supply chain. There are many organizations that have dozens of tools.

So, the first, like fresh perspective that started maybe with ASOC a while back, is getting like a complete view of everything in one single source of truth. It's not a single, like I'm saying source of truth, and not single pane of glass, which is a term that I don't like, because shoving everything into one pane of glass, and fighting a table with 100,000 rows, it's not a holistic view. It's noise. So, I think the main thing is having visibility into everything, but with a prioritized approach. And by the way, like prioritized approach doesn't mean that Apiiro or someone else knows the priority for everyone. It depends. An engineering manager might have his or her priority, which might differ from the main AppSec person of a company, like overarching the entire company. They might have a different priority. The priority might even change over time.

Let's say the classic example is in my organization. There is an audit coming our way from GDPR, and privacy is a focus area for me. So, I need to make privacy better at my company right now. My priorities, let's say, when using Apiiro, I will filter, I will find, I will trigger actions based on that priority. So, I think this is the most important thing, having everything in one place, prioritized. What makes us different is Apiiro is doing like deep ASPM. We're not just taking signals from different vendors, and maybe trying to correlate them or sorting them in a smart way. Apiiro analyzes all the code. Every commit, every pull request, going back years live, every pull request that is being opened right now, and everything is connected. We have a huge graph with the developer data, the commit data, and it's real code, right?

So, if, let's say, I'll give you an example, let's say that we connect, like a customer is using Apiiro and they're also connecting like a third-party SaaS tool, that might detect something, that Apiiro does not detect, like some special language vulnerabilities. In which case appear will correlate every vulnerability that says to detected to the codebase, everything that we detected in that codebase, whether it be an API, and everything that we know about the API, which might include what goes on in runtime from the API gateway that they're using, et cetera, et cetera. It will correlate to the actions of the developer. It will correlate to software supply chain security issues that we detected. If there is a secret that is valid and is exposed in that specific repository. I can go on and on.

Everything is connected deeply into the code, not just with a foreign key to a different table or something like that. Which brings me, I think, to your second question is why do I care as a developer, or an engineering manager? So, I have two answers for that. One direct and one indirect. So, as a developer, I always answer it depends on every question. But it really depends on your organization. If you are a developer, in like, let's say, a big bank with 20k developers. Or if you are a developer or a team lead in a 100-developer shop, your processes like your day-to-day work is different. But in general, let's say your organization hasn't "shifted left". So, there's the AppSec person who's doing weird things, and once in every whatever, they come into your room and they say, "Hey, there's a problem. Deal with that problem."

In that case, what Apiiro provides is clear context. The AppSec person, let's say the developer is not even aware of Apiiro, the AppSec person when they come to you, Gregor, and say, "Hey, there's a critical vulnerability in that API." They come to you with a direct link to that API in GitHub, in Bitbucket, in GitLab, whatever you're working with. They come with the entire context, when it was introduced? What is the risk? Is it impactful or not? And you know what you have to do. You can even say, "Hey, I understand what you're saying. But it's irrelevant, because we are planning on removing that API tomorrow", just as an example. But you can say it clearly and not spend two hours researching and then saying the same thing.

So, I say like Apiiro saved you two hours in that case. There are organizations where that story happens daily to a lot of people. So, the time savings are enormous in that case. This is like the classic, less bureaucracy for me as a developer, classic story. For more advanced companies that can and are willing to automate things, we're helping in safe shift left. Shift left is maybe a loaded term somewhat, because not sure if I can say the different variation of shift left. But you can imagine, people often are pushing more responsibility to like left, to the developer, let's say, but without helping them. Without providing them the right tools, without providing them with the power to do things to let's say, override, if your tool says this is wrong. You can't really shift left without allowing the developer to say, "Hey, I understand that you detected the risk. But this is irrelevant, because yada, yada." Shift left has somewhat problematic history in the industry.

In our case, what we like to do is integrate into the pull request, which is, this is the place where developers live, nowadays, at least. And at first provide very clear context as a workflow on the pull request. So, let's say Gregor, you've opened a pull request that adds, makes a change to an API, and Apiiro has detected that something is wrong with that change. Let's say you've exposed PII data. Let's say even, this is fine. It's fine that that API exposed the PII externally, but it requires a review. Even more than just like, if you've entered some whitespace, it still requires a review, right?

So, this, going back to privacy, exposing user PII data, it requires a review. So, Apiiro can add a review or it can comment on the pull request with all the relevant data. So, first, you as a developer are aware. People are not always aware of what they're doing, either by neglecting to notice. Or sometimes it's really, really hard to connect the dots, here as the benefit of being run by a computer, that can do a lot of things really fast. So, this is a really common integration that we see.

[0:13:35] GV: I mean, Apiiro is, it's covering a lot of bases and things like you've mentioned the API piece, and I want to come back to that. It covers supply chain security, as well. We've had a couple of episodes on that recently, as well. So yes, there's a couple things you mentioned that are really interesting. Shift left, obviously, that's an interesting one, and I think every developer out there has their own relationship to what that kind of means for them based on the company they're in. I think the fact that you've also mentioned, especially from your previous experience, just this whole idea of the speed at which things can be shipped versus the security piece. I think that's always been one of the biggest challenges around security and developers because there's often a power imbalance when it comes to who gets the final say on when something needs to get shipped, et cetera.

So, I think the API piece, that's a really interesting one. Maybe we could just dive into that a little bit more. I'd love to understand, because this has always been, as a developer, as a CTO, this has always been an area that I would have always loved to have had more control over, which was API security, effectively. It sounds like a peer was doing that pretty fantastically. Apiiro has access to the repositories. We'll also maybe talk about the access piece in a little bit. But it's got access to everything. How is Apiiro really analyzing the API and analyzing that against given security threats, and are they historic current? How current? Could you maybe just speak to that a little bit?

[0:15:07] YE: Sure. So first, you've mentioned source control managers, I think it is important to understand that maybe we'll dive deeper later. But Apiiro connects to every source control manager you have via an API. So, Apiiro has visibility into the codebase, like the main branch, feature branches, pull request branches, et cetera. This is like the bread and butter for Apiiro, for identifying and analyzing APIs. You could augment that, and many customers of ours do, with data from runtime, from the API gateways, from the cloud vendor. I mean, from Kubernetes, from other tools, and then the data gets richer. When you're looking at an API, you have more data, and you can correlate APIs with different things.

Apiiro, first and foremost, which is, it might sound trivial to the untrained ear, but Apiiro provides visibility into all the APIs. So, just the plain listing of which APIs do I have and where, this is really important. By the way, I was amazed from more basic things that companies were not aware of. A set with, let's say, a 600-developer company, and I sat with their CTO and CISO, and in other managers, and they couldn't agree on how many developers they had at the time. The answer is varied 100% or more. Digging deeper, they were surprised by Apiiro detecting that they are using in production MongoDB and not just SQL Server. This is just the one example.

So, the various technologies that they are using. And to our example, API is something that it's really hard to keep track of. Really hard. What's get, post delete, something that is connected to this database to that database. Is it exposed to the internet? Is it internal between like a REST API between microservices? Is it secure? Is it authenticated or not? All this is really hard to know, in an organization, especially a segregated organization. Imagine a larger organization that has made acquisitions, or in any case, has both GitHub in the cloud, and Bitbucket on-prem, and people are not talking to each other. So, they might have identical APIs deployed in different sides of the organizations.

For every API, we can identify its route, which is not always easy, because usually in Go, and Python, and C#, and Java, and Node, there are a bazillion ways of defining APIs. Oftentimes, part of the routes are defined in a base controller thing, and the API itself is parameterized. All sorts of weird, dynamic things are going on there. So, we build out that route from our deep analysis of the code. And given that what sounds basic, but the basic list of APIs, we correlate it to everything else. Where is it deployed? What risks are behind it? Whether it be open-source risks or vulnerabilities in the code itself? If there is an exposed secret in that is returned by an API that is unauthenticated, we've seen that it's an obvious place to start your digging and remediation. Do that before you go and investigate some generic API. Right?

This is our approach to API security. We've come a long way, the last four years. We started with discovery, which again, is really important. But now we've gone really, really deep into correlating these APIs with everything else that we have in our graph.

[0:19:11] GV: Got it. So yes, that's just the last couple of points that the fact that you start with discovery, and then now going deeper, this is going, I think, as you said, you categorize yourself as really deep ASPM. I would, I guess, interpret the deep part as access, which is that you do have access to more perhaps, than other platforms get access to. Maybe, do you want to just talk through how we did an organization, what kind of access are they giving? How easy is that? What kind of, even, we've got listeners from large, large organizations to startups, what sort of, even legal considerations might they need to think about that they have to get approvals say to use Apiiro?

[0:19:54] YE: Yes. That's my life. So, in our previous startup, Aorato, it was a network security product, 2013, '14, '15. Cloud was not there yet, at the time. We even sold appliances to customers that ran the product in their New York basement of the bank. But network analysis and stuff like that is really, really hard to deploy and to connect. It's really sensitive. In our case, code is sensitive as well. But our deployment is much easier. We are connecting to source control managers via an API, so it differs between GitHub and Bitbucket, and we support even perforce, not only git-based source control managers. But they differ on their permissions model and stuff like that. But we've put a lot of energy into deeply integrating into the various APIs of Bitbucket, and GitLab, and GitHub, and the others. Both cloud and on-prem to give the flexibility to the customer.

So, let's say you're a GitHub-based organization, you have full control into what you expose to Apiiro. You might define a token that has access, read access to everything, and give it to Apiiro. It should take less than a minute to connect. You give the URL, github.com/myorg. I give the token and then Apiiro starts to analyze. You can see the dashboards lighting up in a few minutes, and full analysis of all repositories, at least, the latest status of all repositories, depending on your organization, in a few hours, or maybe even a day. If you have 800k repositories.

So, this is really, really easy to do. We have customers that use our back model. They added roles into their organization. They have two people that they are admins, and they have sub-organizations, and we've divided scope to each organization. So, even you've seen, like, I've shown you before our explorer that can go and explore all the risks, all the code, all the elements that exist in the code repositories. So, in that case, in my example, organization that I'm describing, like John from org A can't see whatever from org B. So, this is really, really important for us to give confidence to the customer, that you're not exposing anything you shouldn't be exposing.

We have one customer that has some of their code base, that are really, really afraid of exposing, and okay, they don't grant access to those repositories. That's fine. That's their consideration. We give full control of what you have access to, to the customer, and we have, I think most of our customers, even what they're doing is they're providing a token to a GitHub organization, let's say, and they check the box of auto monitor, every new repository that is being added. This gives a lot of confidence. This is the other kind of confidence that they are not surprised that, "Hey, a month ago, someone added a new repository and is now exposed to the Internet with customer data or within internal data." It's like Jurassic Park with the frogs. No one was keeping track of new dinosaurs being born in the park. So, this is a really important use case for us to discover, new assets being created.

[0:23:40] GV: I'm curious, just off the back of kind of what you've just been explaining. I could be making a wrong assumption here. But it sounds like it was the enterprise use case that was front of mind when Apiiro started. Maybe that isn't the case. But equally, what has been the order of events, so to speak, with the types of and the sizes of companies that's used Apiiro.

[0:24:01] YE: Sure. So, we've started with both enterprise companies like really large companies, and smaller companies, like let's say, mid-enterprise. For the purpose of us being efficient, we didn't work a lot with small companies like less than 100 developers. In these cases, such companies are not yet mature enough with their security posture. They don't really know what they want yet. I'm speaking as a startup person myself. Oftentimes, it takes them time to figure out those things.

So, we started with more mature companies that can grow with us and with the larger enterprises. By the way, this brought us challenges that we've already dealt with in the past, but still, three, four years ago, even now, larger companies are not yet cloud-based. Even if like all companies want to be cloud-based, but the transition is still going on, it's not easy for them, and we're helping to facilitate that. So, for many companies that were 100% on-prem, and they're starting the transition to the cloud, meaning moving their code base to the cloud, not only their payloads in AWS, or whatever. For them, we've helped facilitate that. Know that we monitor and help you secure both your code on-prem, and in the cloud.

This is why from day one, we supported our deployment, both as SaaS and on-prem, which is, like every developer listening knows that this is a challenge. So, we are Kubernetes-based. We can run anywhere. Obviously, I enjoy running in the cloud more. It's easier for us to bring best-of-class support to customers, it is easier for us to be proactive and see if we have some bug somewhere, or something is not performing right. On-prem is harder in that sense. But we knew that many customers, it would be challenging for them to have all their code on-prem, but Apiiro analyzing the code in the cloud.

By the way, we've developed like a broker solution to help that transition and analyze code from the cloud, glancing into the code on-prem. It is hyper-secure, and obviously, it's opt-in, like the customer with their security teams. It's a process of approval, and making sure the tunnel is properly secured, et cetera. But we do support that as well.

Answering the question, both enterprise and smaller companies, each has their own characteristics, and we've learned a lot from small companies, like 100-developer companies, and larger enterprise. I think our largest customers gained a lot of value from what we've learned from smaller companies. Our agility, like analyzing their new and modern assets, that a year later came into the larger enterprises. Gen AI is just one example that came lately, and the other way around. Our scale that we've built with an 800k repository shop, has helped us be faster for 500 repository shop.

[0:27:43] GV: Yes. I think, that makes a lot of sense, and it's interesting how Apiiro sits in that in that, not exactly a unique position, but a fairly niche position, actually, where kind of what you've just said, what you learn from the smaller companies actually is going to help your much larger clients, because you're trying to say, "Well, if you want to work at agility", from the small to the large work, you want to work with that agility, then this is kind of what we've seen and how we can help you. And then, consequently, if you're a smaller shop, but you shouldn't need a lot of the controls and security that much larger companies have. This is something that Apiiro can then cross reference, which is very cool.

So yes, let's just touch on something you also mentioned there, which was AI. I mean, we how can we ignore that? How have LLMs, AI generally, that I imagined had a bit of an impact on how Apiiro operates? So, maybe you want to just speak a bit to sort of how has that affected how the Apiiro platform has developed in that time, and sort of what is being checked, so to speak, in that area?

[0:28:50] YE: Sure. Two answers, internally, we do a lot of research inside Apiiro. We've been analyzing code for almost five years now, using various methods, and we have researchers here, myself included, that have been analyzing code like going back years. The LLM approach is new and exciting, and we are doing all sorts of things right now with LLM. By the way, it's easy for a lot of people to imagine, "Hey, take something, throw it on an LLM, in ChatGPT, get an answer, ship it, you're done." This is not the case. Usually, we are very conscience, first and foremost on privacy for our customers. We won't, we will never send customer code to a third-party OpenAI whatever service. This is really dangerous and customers have expressed their concern about this thing. Tell me that OpenAI doesn't train their models on my codebase. People are very concerned about that.

So, first and foremost, privacy of our customers, then there's the, can an LLM model solve a problem? And then, scale and cost, right? If you're using for a certain task LLM, like third party, there's unit economics involved, then we're analyzing every pull request, every code base, yada, yada. You can't really do that at scale and have it be with cost in mind. So, we're doing a lot of exciting research. We are developing internally like models that can solve specific problems. We're not solving like general purpose AI right now. But specific models that can solve specific tasks. We're doing really exciting things.

This is my first answer. It's a really interesting time analyzing code right now. My second answer, customers, and we see that. We see customers really afraid of what's going on in their codebase. Who is writing my code? Is it John? Is it Gregor? Or is it some AI that has learned how to develop against my interests for my competitor, or something like that? Does my intellectual property leak to co-pilot, OpenAI, whatever? Every customer, even those who forbid their developers using ChatGPT and the like, every customer environment, we see developers using Gen AI frameworks. Every customer.

I know that because Apiiro, among other things, detects technologies. If you're using MongoDB, if you're using this web API framework or that one, and if you're using clients for Open AI, for whatever, some other things as well. The same answer that I gave you earlier about APIs, like API security, and how we correlate it to different things inside our graph. In this case, as well. So, if in a certain repository, someone is calling out to open API to detect something, this is exposed to the Internet in a really specific way. But if this repository has exposed secrets, or the repository has a third-party developer, that he has right permissions into that repository, then this is what we sometimes, we call toxic combination, right?

So often, a risk on its own is not really relevant. Okay. So, they're using Open AI, it's fine. But if from the source control manager, governance perspective, you're not tight enough, like all developers have admin privileges, or there's a third-party developer, or there is no branch protection, you can force brush, whatever you want into that repository. If you combine this and that, and the other, it might be really, really problematic and actionable by some hacker or even by mistake. As a developer, you might expose something that you didn't know that could even happen. You just might expose something really important to the company.

[0:33:23] GV: Yes. So, let's just switch gears a little bit, just the software supply chain security aspects of things. Apiiro deals with SBOMs, that amazing acronym that is thrown around a lot now. So, software bill of materials. But I noticed that Apiiro has kind of taken that to a new level, XBOMs. So, could you maybe speak a bit to XBOMs, and I'm also curious, given this bit of talk around regulation on this, has that been of so any influence to the approach that Apiiro is taking and how might a current or potential user of Apiiro be able to use it in conjunction with anything that's coming in?

[0:34:07] YE: Sure. So, XBOM, which is an evolution of SBOM, which is derivative may be of bill of materials that I open the container of shipment from whatever, and I know what's inside, or what's supposedly inside. So, in software bill of material, if anyone who's listening don't know, you're declaring what's inside. Okay, if you're supplying something to a customer, as a vendor, you want to provide maybe with a software bill of material, where you say, these are the open source components that you get alongside my solution, et cetera, maybe with its vulnerabilities. So, this is like the basic thing. This is not always true, and we're working hard on having it be live and accurate.

So, Apiiro can go to any repository or application, and Apiiro can define an application using three modules from that repository, and two other repositories, yada, yada. You can go to an application and click a button and download a live XBOM, like SBOM, which has everything, which is related to the inventory. This is our term, inventory of that specific application. The list of APIs, the open source packages, vulnerabilities. All the dots are connected. So, this is really, really important for it to be live and accurate up to date, with not only open source packages lists, rather, everything that we've discussed thus far goes into that. This is really, really important for various use cases where customers are maybe acquiring a company and ingesting like, one day, they have 10k more repositories. What's going on there?

You can download the XBOM, using like various known formats that exists already in the industry. Or you can go in the UI, to the inventory of a certain application or repository, and you can filter, you can browse, you can see a graph, you can explore, you can investigate. Show me all the open source packages that have a certain license, GPL, et cetera, et cetera, et cetera. So, this is really, really strong. It's really, really valuable.

Lately, to your question. Lately, President Biden added regulation with SBOM and it trickles down from the larger companies, like the regulated banks, and healthcare, and such companies to provide the SBOM to their companies, and demand SBOM from their vendors, yada, yada. So, it starts to trickle down to less regulated companies, because it becomes a thing that you do, and we are working hard on providing accurate exports of XBOM from all the assets you have.

[0:37:08] GV: Yes. I think it's exactly platforms like Apiiro that are going to provide so much value in this era. Personally, just from where I sit, I see this only getting more regulated, more looks at from, not just the company level, but the government level, or at the very least, the industry level, industry watchdog thing, if you're an X type of company, you're going to have to do X, Y, Z or you're out the club kind of thing. So yes, I think, an Apiiro platform is only going to be effectively required by actually a lot of companies in this way.

If we just sort of looked to day zero or day one of using Apiiro, I want to look at this, maybe more from the developer perspective. I can imagine engineering managers, CISOs, they're 100% on board with Apiiro. Developers, maybe I can imagine there's maybe some that sort of are shown in the platform on day one, and they go, "Oh, my goodness. There's so much to look at here. Where do I start? Is this like a Supernanny platform?"

[0:38:11] YE: My answer will surprise you.

[0:38:14] GV: I can't wait to hear the answer.

[0:38:16] YE: I don't want to show the platform on day one to a developer. It's a mistake. I'm saying that, as a developer, don't introduce another tool to me. Forget it. Let me just do my thing. If there's a new process, you need to justify it. I'm talking as Yonatan right now, as a developer, and I want to create value. I want to solve a bug. I want to make something work more reliably. I want to make something work faster. I want to develop features. This is what I want to do. Everything else needs to be justified. This is my take as a developer, right?

Obviously, it might be naive for the entire company to think like that, because there are concerns. There are regulations. There's compliance. There's actual security, which developers do care about. But me as a developer, I can't take ownership for 10,000 developers. It's not possible. So, to your question, developers need tools and processes that are, I don't know, 99% accurate. Developer is used to a compiler. If IntelliJ or whatever visual studio, whatever IDE you're using, is giving you 50% accuracy on if your code compiles, you won't use that tool. Taking it to our space, when we start working with a customer, we start by mapping out with their AppSec team, what they want to achieve. Are they focused on remediation of certain types of secrets? How familiar are they with what they have? Do they need to focus on visibility, and do some exploration for a few months? Every customer has their own on priorities in that sense.

After they did that, if they are mature enough in terms of what they identify in what they want to remediate, then they can select to create a workflow. It's really easy, but create a workflow, that comments on the pull request. This way, they get introduced, these new processes gets introduced to the developers. And only then when they have trust, only then maybe introduced the more advanced process of blocking the pull request. But even then, they would block the pull request from being merged, only if a very high certainty criteria is being met. Not like blindly everything. If there is any risk, blocked the pull request, because this would halt an organization. You don't want to do that. So, they're starting with what they are certain of, rinse and repeat.

This is our approach of working with developers. And we are developers. It's really, really important to gain that trust, and not just impose a certain process on all developers at once.

[0:41:08] GV: Yes, I think that's been evident, just everything you've sort of said today about Apiiro, it's clear that this has come from a very developer first place, even though as you said, and of course, it does sound surprising initially. Oh, it's not the developer who's going to see this first. That isn't the sort of person who's probably going to take a look at this first. But unless it has been thought of from that perspective, this doesn't work, and is probably actually where a lot of, I imagine other platforms, companies have tried something in this area and have probably taken the other side. And that's not -

[0:41:44] YE: Yes, or sure. I won't give examples, but yes, for sure.

[0:41:48] GV: Exactly. Yes, why they fail. This has been such an interesting conversation, and I'm sure everybody listening, they're just hopefully wanting to take a look at Apiiro and get their company involved. What's the best way for, if a company isn't using Apiiro now, where should they go? Who should they reach out to, to talk more?

[0:42:07] YE: Yes. I think the easiest way is apiiro.com. It's a short domain. It's easy to request a demo, start talking to us. I'm available as well. Other people in Apiiro would gladly take a conversation and introduce Apiiro to anyone.

[0:42:26] GV: Fantastic. Yes, so that's apiiro.com.

[0:42:31] YE: Exactly.

[0:42:32] GV: Yonatan, this has been awesome. I really enjoyed speaking with you and I love the platform. I'm not going to lie. So, I wish you guys all the best.

[0:42:41] YE: Thank you. I enjoyed it as well.

[END]