 Today we have with us Moti Guindy, Chief Product Officer at APIRO. Moti, it's great to have you on the show. Hey, great being here. Again, so thank you for the opportunity. It's my pleasure to talk to you all the time. Today, of course, we are going to talk about a new announcement that you folks are making, which is about extending into supply chain security. But before we go there, just quickly remind our viewers what is APIRO all about. APIRO is a cloud-based application security platform that helps application security owners and developers and engineering owners to manage their security posture around their software development, understanding how their code is being built, what is the risks that are found in that code, helping to prioritize, remediate and also prevent this risk from ever happening again. Excellent. Thanks for the intro to the company now. Let's talk about what are you folks announcing today? APIRO from day one was focused on helping our customers to secure their application and the way that this application is being built and deployed into the cloud. Today we are announcing a new set of capabilities that are added natively into our platform to help identify, prioritize, remediate and protect from supply chain risks that are generated by the way that the code is being managed, it is being built and being deployed. When it comes to supply chain security, depending on industry, depending on how people are consuming, what we do know is that more and more people are consuming open source these days and when you talk about open source code base, there are different frameworks, there are a lot of dependencies. Even if you are spending containers, they have a lot of things inside those containers. Do people really understand the software supply chain? I think the short answer is yes and no. I think more and more, as always, I think more and more, everyone that is building code is aware today that the large percentage of the code is based on open source and things that are actually getting from the outside and incorporating into their code. They understand that they need to find vulnerabilities, understand risks based on this code is part of implementing secure development. But this is the yes part. I think where is the no part is that thinking about your software supply chain is only about your open source vulnerabilities and risks is a limited view because when you look really holistically on how your software is being built, open source is part of it, but also the way that you manage your code, the way that you build your code which is based on SCMs or CICD pipelines or the artefactories of containers, all of these elements that are in the background helping you to build the code, the application and deploy it and manage it are also a source of attack, are also a source of risk. So when you look on software supply chain, you need to look not only on the property code that you developed and the open source code that you inherited, but also around the entire end-to-end way in which this code is being managed, developed and deployed. To give a simple example, even to take an extreme case, even if in your organization now there is a malicious insider, a developer that decided to add vulnerable code to a backdoor, to your install base, to your code base. This is not a vulnerability, it's not related to open source, it's related to the way that actually your code is being built and developer behavior is part of this way that the code is being built. So being able to detect it and protect from such misaligned developer behavior is in our view, in the peer view, is also part of protecting your supply chain. So the way that we look and we hope the industry and soon the regulation we look around software supply chain security is in an holistic way. The code that is being built, the process in which it is being built, the way it is handled, managed, deployed and built and deployed into production. This is a very good point because when we do talk about software supply chain sometime we do focus on external components, but you are building a lot of code internally also. So that is a great point. I kind of draw a parallel with the analogy of automobile industries because that's where all the components come from. And then if you do not know where the source is of your component you will not be able to fix that problem. I was going through the Prisley's and there is also, you are also natively providing source control manager there for the CI CD. So talk a bit about once again from the perspective of knowing what is the source of the code, it could be external, it could be internal. And also when you are explaining that, maybe also talk a bit about what are some of the core features and functionalities that developers or DevSecOps team will get access to through this new announcement that you folks are making today. I'll answer both. I'll start with analogy. I like your car. I will add another one of like when you look at a home that you built it's clear that when you are entering the home and say hey do I want to live here you need to look at the furniture and the color of the floor etc. But if you are actually doing the right diligence you also need to look at the plumbing that is hidden behind under the floor and also the concrete that was used and the quality of the concrete that was used to actually build the building and how is the if there is a gatekeeper at the building is it someone I can trust and actually and that's really the key thing and connect all of that. So that's the key thing, that's really the key basis and thesis around our software supply chain. We think about it not as a standalone solution but it's another component, another way to look at your risk that is part of the term that is industry called ASPM application security posture management. Now needless to say this is not a theoretical risk this is something that is happening more and more this type of attacks by again malicious attackers that are somehow controlling the way that your code is being built and by that they are blind to the normal app sector that are looking for vulnerabilities and issues within the code that were entered by mistake. So adding these capabilities is really a must in order to provide an holistic view and this is where regulation is also going to. CISA, SSDF, CIS, NIST, Salsa of course all of these are acronyms of regulations that are looking at the same problem from different angles and putting more and more liability and responsibility on our customers to make sure that not only the software does not include vulnerabilities but really the way that it is being built is safe and controlled. So that's really the mission we took when we built software supply chain security into appeal. So within that we divide the set of functionalities that we are providing and announcing today to four parts I will touch them and really touch what is really the places that this approach of looking at software supply chain is part of an holistic SPM solution and not a standalone silo provides to our customer. So the first element as always is visibility. Understand, like I said, hey, you need to control the way that your code is being built. So the first level is understand where your code is being managed, what is the posture of the SCM? Does your repo or branches allow, for example, pushing code without code reviews? Is it something that is happening? How your developers are behaving? Which developers are pushing which type of code to which type of repos and then how this code is being built? What are the pipelines that are providing, that are building code? Are they vulnerable? Are they configured well? Who has admin rights to them? Do you have admin rights to people that have no, that are actually not accessing? You are not actually operating under list privileges. And then how the thing that you built is being managed in artifactory container registries and is being deployed. And can you say that the thing that is now being deployed is the thing that you originally developed? So visibility is kind of the anchor level. And here, last time I've been here, I talked about a concept that is called XBOM. Since then, this thing is, this acronym is becoming more and more known and not only pushed by us, but the concept was that let's take the good ideas of XBOM, software builds of materials and enhance them and say, hey, software is not only open source vulnerabilities, but also API code modules, data models, developers that build the code. So software supply chain is just an addition to this XBOM. Now, you can, in a Piro, via our graph-based risk engine, you can ask yourself, here is a line of code, which code module it is connected to, which dependency it is being used, in which SCM it is being managed, what are the permissions of this SCM, by which pipeline it was built, what are the vulnerabilities of this pipeline and to which container, a production pod, it was deployed at the end. And is it really the line of code that was originally written by my developer? And of course, with the developer that did it, et cetera. So software supply chain is added to our XBOM and to our risk graph engine. This allows, and that's the second layer, a very unique risk assessment. There are many software supply chain companies that are security companies that can look at your posture of your SCM or the posture of the pipeline and find vulnerabilities or find misconfigurations. But this, again, will be siloed. Again, like in the past, you will get 10,000 alerts of misconfigured repos or misconfigured pipelines, but which are the ones that are really important? This is where the fact that everything is on top of a one platform and connected by this connection of graph allow us to create the notion of chain of risks, or we call them toxic combinations, that allows you, for example, to say, out of all of my pipelines that are repos, sorry, that are misconfigured, that allow force push, meaning pushing code into production without code review, I want now to handle only the ones, first of all, the ones that allowed force push and build and have an API that were added lately without code review and that are deployed to the Internet and has no authentication. It means that someone added a risk, imminent risk, an API that has no authentication deployed to the Internet and did it without a code review. This is a risk that is above critical. I need to go and handle it today. The only way to identify it is by connecting code, API authentication flows, et cetera, to the way it was built and deployed, which is without force push, for example, or deployed to the Internet. This is an example of a toxic combination of taking vulnerabilities or issues from multiple domains, pipeline security, source code manager security and API security and combine them to a risk. Understanding that the risk is not a collection of vulnerabilities, but actually the combination between them. This is the only way that you can say, here is a strange developer behavior. Morty is a developer that usually writes in C-sharp on this and these repos and now Morty added an open source vulnerability to a Python repo in the middle of the night to make this example more romantic and this is really different than how Morty is operating daily and now there is now a repo with an open source vulnerability that is exploited from the Internet build and deploy to production. It means that Morty, either Morty is a malicious insider and added a backdoor or Morty's credentials were obtained and now I have a risk in my, like an attacker use these credentials to add a backdoor to my code. No app sector by itself will identify that and yell on that, but the combination of these things be taking multiple medium items and making them a new critical thing. And that's really the second layer of the risk assessment and toxic combination detection that is really unique to an adding software supply chain capabilities into a platform that is doing much more than only supply chain but actually looking across the all SDLC from code to cloud. And then of course come all of the usual code from capabilities of a PROF being able to prioritize, remediate, prevent, stop these threats from entering code at the PR level when you are actually authoring, for example, pipeline configuration files. But I would say that the uniqueness is around adding these capabilities to XBOM to provide actually visibility that is connected and then using that to create toxic combination detection. This is something that I think you wouldn't find in any other silo the standalone software supply chain security product. Earlier, you were talking about regulations. I want to talk quickly about since you folks are based in Middle Eastern for the whole European market is also there. Recently, European Union came out with CRS, Cyber Resiliency Act but there has been a lot of criticism that while the intentions are good they don't fully understand that the responsibility should not be on end developers. It should be more or less on on vendor server developers. They're like, they don't know if my code is Linux kernel. We don't know if the kernel is being used in a submarine or is being used in a rocket or a missile. My job is to make sure that this is the code I wrote. So that's why sometimes when you look at open source code, do you have any comments on that where you see that when it does come to regulations there should be a participation of public, private sector, all the stakeholders. Just want to hear your thoughts on that. I think that at the end of the day owning the security of an application is, I think as you hinted, a combination of both the applicative code owners, the one that are actually writing the code and their suppliers that are supplying the right components which are secured and nothing, you can't do anything by not communicating or by siloing, trying to say the responsibilities either on that or on that. But at the end of the day and I think CISA is going exactly to that direction in the United States and I believe firmly this is the right direction is that the final responsibility of and the security of application which means the components of the application, the supply chain of this application and also the processes that built it is the final ownership of the one that provided this application. And therefore CISA is going under I think there is a call to comments that was launched a couple of weeks ago by CISA to initiative of secure development at the station, excuse me if I'm not saying the right name exactly, but putting the responsibility of attesting that the code that you provide to your customer putting this responsibility to proactively attestation on the CEO or the board of a company which means the company needs to owns when coming back to the home analogy when you are the home owner you own everything even the things you own the responsibility to attest to the quality of everything even if it's not, you are not the furniture but you need to attest to the quality of the table, you are not sorry the carpenter but you need to attest to the quality of the furniture that are within your home. So this means that it will put higher bar on companies that are supplying software they will need to be personally attesting it's not now a vague statement like SBOM was kind of you need to supply your SBOM but the responsibility to consume this SBOM and understand it the responsibility of the ones that actually use that. Now it's going the vice versa you don't need only to supply an SBOM but you need to proactively attest that you have the right processes, you have the right tools and you have the right outcome of providing a secure software. I think that this model which at the end of the day is becoming pushing software application to become much less voluntary and much more proactively like again in a board level or CEO level is exactly it puts a high bar on all of our customers but it's the right way to push quality or security upstream. Again I hope it makes sense, I can understand also the fears of customers of saying but I can't attest but this is exactly what CISA is pushing on putting a higher bar which I think really is the right move to help the entire industry otherwise it's chaos. When we talk about software supply chain security or when you talk about toxic combinations are there any specific industries that you look at and now when we look at industries could be industries which are like sensitive it could be financial or it could be healthcare or it's about the size of the company as well that bigger companies versus our company or you feel no this is a problem it doesn't matter it doesn't matter industry if you are dealing with software this should be your problem. So as always it's option B it's a problem of everyone that is actually writing code no matter the size of the company and no matter the industry or the regulation but as always because there is here a maturity process and regulation is a way actually as we talked just earlier about the CISA initiatives and other regulation is really a very effective way to push companies to do things that are otherwise hard to invest in understanding your supply chain and securing it it's not a trivial thing to do so I the value is a value for everyone I am sure that the first type of companies that will adopt it and be the thought leaders and we show the rest of the industry what is the right way to secure application code and software supply chain so the code and the way it is being built and deployed will be industries that are under regulations industries that actually all companies that are mature and usually it means they are big in their amount of engineers and amount of apps and governance and they learn the hard way that it's much simpler to stop risks from entering the code or entering the application then then instead of figuring out after this thing was exploited SolarWinds as an example and try to handle the crisis so it's relevant for everyone but it will be a maturity cycle across the multiple years that will start from regulated industries and how they can get started with these two solutions from APIRO customers that have APIRO it's simply there it's another capability that we added and otherwise it's really easy to create to ask for a demo and a session with the APIRO representative and then from there go to a very easy installation I need to emphasize here the way to start with this solution is simply by connecting APIRO to the SAS platform giving it read-only access to your SEM and start from there suddenly you identify pipeline configuration files you identify code posture issues connect them to API, code module understand toxic combination simply by giving a read-only access which is a configuration of probably five minutes to APIRO SAS platform and from there you can grow connect APIRO also to your pipeline ecosystem to your production ecosystem to your cloud security posture management system and then get more and more context but the beginning is literally and you can see that in some of the evidence of the PR and the blog is like the time to value is 30 minutes Moly thank you so much for taking time out today not only talk about the improving the supply chain posture but also talk about this new announcement thank you so much and I would love to chat with you again thank you I'm sure we'll chat again we are launching tons of new stuff and fun stuff and thank you again for the opportunity and for your great questions