Application Security Management and the new SBOM with Idan Plotnik

Secure Talk - Idan Plotnik 

Justin Beals: Hi, everyone, and welcome to Secure Talk. This is your host, Justin Beals. I've been building web applications for 20 years at this point, used a variety of different web servers, delivered all kinds of different business cases, and seen just a huge variety of different types of systems. All along that way, in inventing a new web application, we had to think about that application security.

And a lot of times, it was just considered a standard part of development. We needed to set up authentication. We needed to deliver encryption so that the data was private. We needed to think about resiliency of the system on some level.  In big enterprises, delivering a single product odsn the web can take thousands of engineers at times, all working on a variety of different aspects of what they do and the concept of application security management becomes a real issue.

And certainly part of the challenge in getting your software out the door and in the hands of your users realizing the value of it is getting through enterprise security processes. Today, we're going to talk to an expert in application security and application security postures. Idan Plotnick. He is a serial entrepreneur and co-founder and CEO of Apiiro

Prior to a Apiiro, Idan founded Aorato, which developed a network security solution for Microsoft Active Directory. That company was acquired by Microsoft for 200 million in 2014. Following the acquisition, he was appointed to the director of the Microsoft Advanced Threat Analytics and Azure Advanced Threat Protection Program. He served in this position till 2017. These are huge pieces of software that required thousands of engineers to deliver and ensuring that that delivery happened in an effective way. And plus the appropriate security testing as an application was a critical part of Idan’s effectiveness. Idan’s going to tell us about how we solved that problem today on SecureTalk.

—-

Justin Beals: Idan, thanks for joining us today on Secure Talk. We're really glad to have your expertise on the podcast with us. 

Idan Plotnik: Thank you for having me. 

Justin Beals: Great. So, Idan, why don't we kick off with the work you're doing today a little bit? You are at Apiiro. Tell us a  little about your role and what Apiiro does. 

Idan Plotnik:  Sure. So, I am the co-founder and CEO with Apiiro. More than 20 years in the cybersecurity industry. And at Appiro, our mission is kind of simple. We help Fortune 500 companies to design, develop, and deliver secure software faster. We under, we developed a technology called DCA deep code analysis that actually connects to your source control manager, GitHub and GitHub, GitLab and others, and automatically without any human intervention, discover all your software inventory and architecture, like all the APIs, older your GNI frameworks usage, PII, and then allow you to use this software architecture for prioritization of vulnerabilities, remediation, prevention, and define guardrails, not based on CVSS score, but based on your software architecture and the business impact of it. 

Justin Beals: A lot of interesting technology layered in that for sure. Positive. Yeah, 

Idan Plotnik: Absolutely. Absolutely. 

Justin Beals: Well, I always find that there's a, you know, and I think we love telling these stories as founders, you and myself; how, however, did you find computer science in the first place? Cause something drove you in this direction. I'm sure. Yeah. 

Idan Plotnik: Yeah. So, You know, everyone has its own story.

My father, when I was six years old, literally bought, he's so far, so far away from, from computer science, but he bought me a computer, and I think I literally fall in love and from gaming to development, to hacking, to, I was just so curious. And, from that moment, I knew that this was my path in life, you know?

So, I studied in school; I served at the IDF in a cyber security unit, I had my own consulting services company. After that, I founded another startup that I sold to Microsoft in 2015. So, you know, this is what I know, and this is what I love to do. That's it. I think this is my story. 

Justin Beals: What was that first computer and the software language that you used? Yeah, 

Idan Plotnik: It was Pascal. Of course, DOS, but Pascal is the first language, and it was Commodore, but then PC and, you know, Commodore for gaming and then PC for development stuff. 

Justin Beals: Yeah, 

Idan Plotnik: I, I feel, I feel old now because of all these questions. 

Justin Beals: No, no. Well, you're in good company, my friend. Either way, I had an Atari 800, and it had no drive.

You had to program it in BASIC. Um, and I think my dad, 

Idan Plotnik: Yeah, sorry that I'm, I'm interrupting. I literally, I can't say. Which company, but I, I was traveling to a large enterprise to meet a prospect, and they had an Atari, and I took a picture, it's like a piece of art from my point of view. 

Justin Beals: Oh, it was so fun.

Uh, I loved working on that machine and Basic was a good programming language I felt like early on. And I did Pascal too in grade school, some, but I, I think I also fell in love with how they were used. Did, uh, when did you get introduced to security? Was it early on? Were you, were you trying, you know, hacking as we thought about it in the early days, let's say, as opposed to today.

Yeah. Idan Plotnik: So I, I  think it's just, you know, it. It happened like you want to go into a website and you can't, and you are a bored teenager, and you're trying to break stuff, and then you read, and then you understand how things are working, and then you're trying to poke holes in that and this is like early on in my computer's days I try to I didn't know it was hacking or security, I wanted to play games and get into websites or stuff like that.

So I tried with the simple things and, and then I, you know, at school, I wanted to get and see other people’s work on their computer.s So it was just, It's just curiosity, I think. 

Justin Beals: Yeah, it's interesting to think about a network in that way, right? Like, when we first started getting personal modems and being able to connect to other computers, it was, it was opening up a new layer of exploration.

Idan Plotnik: Game changer. I remember I was reading The RFC for TCP IP, and you know, it was intriguing, like who invented this thing and how it works, and hey, I can change a few bytes in the packet, and something different will happen when I send it to another computer. This is fascinating. Like, but you bring me back 20 years, so.

Justin Beals: Well, let's play the story forward a little bit. I have a lot of friends that served in the military here in the United States. So you served in the military in your country as well. Many of them that studied networking or computer science was a big part of the skill set that they practice in the military as well.

Was that true for you as well? Did you work in engineering? 

Idan Plotnik: Yes, absolutely. And I always love to combine between network and software because I was super intrigued on how you write something. And eventually translated into a network traffic that goes to another computer that translated across the OSI, you know, layers and, and yeah, so I did on literally I was involved in network architectures, but also software architectures, and this is how, you know, after I finished my, my service, I said, Hey, I can help other companies with their security posture by trying to find holes and help them fix it. Not in a bad way, like in a legit way. And I got paid for it. 

Justin Beals: Yeah.

Idan Plotnik: It was, it was fun.

Justin Beals: There's a, there's a, a power to it. One of my first professional computer science jobs was for British Telecom, and I worked in the global data center. So we did network operations and a lot of my colleagues came from the military to come and work in the network operations center. I think some of it had to do with this sense of security and the 24/7 by 365.

Right? You're, you're kind of never off duty when you're serving in a way. And I think that it worked really well in our culture and it was deeply about security. Yeah.

Idan Plotnik:  And I, I think one of the, I think the patterns it goes. Again, through my journey is when I felt that I have this power of breaking stuff.

I always wanted to think about innovation, like what we can bring to protect organizations for that. And we literally back then in 2009, we invented an industry. That's called UEBA, User and Entity Behavior Analytics. Why? Because as part of one of the pen tests that I did, I found a way to steal your NTLM and Kerberos, a ticket and move laterally between computers without knowing your password.

And then it was past the hash, which was a huge, huge thing. And then, we worked with Gartner. I tried to convince by the way that this is going to be a huge problem. No one literally, no one listens to me, listen to me back then. And, and every VC throw me out of the stairs and say, no, what do you, what's the connection between Active Directory and security and look about like, this is a 3 billion on me, even more 4 billion dollar industry that the leaders are CrowdStrike and Microsoft.

So, and this was a company that, that we invented back then to identify abnormal behavior of users and computers inside your network. And the second, just, just to explain the pattern, when, when I sold my company to Microsoft, and I was a GM for software engineering, I felt the pain where all these risk assessment and application security processes and tools like SAST and DAST and secret scannings and penetration testing and threat models actually stopped me from delivering software to our customers.

Justin Beals: Yeah. And the, the life cycle of code deployment has gotten shorter and shorter over the years.

I certainly remember more waterfall based methodologies, but I mean, honestly, I think in a way it would have been hard to move to more agile without cloud computing resources and CICD So we always have a chip on, you know, that we're able to run. Yeah, 

Idan Plotnik: So true. And now it even worse because now everyone moved like, you know, the in the evolution of software development, everyone moved to agile five years ago, like implemented Agile existed for many years, but in the large enterprises, everyone are now working based on sprints. Everyone are using CICD pipeline to automatically do the continuous integration and deployments to the cloud. But the huge problem that risk management and application security teams are dealing with, are now AI code assistance.

Because AI code assistance increased like exponentially, the amount of code changes that are getting into every deployment and every release. And now you have the same amount of developers, 100x more code. And it takes many, many, many, many changes that you cannot manually review. It doesn't make any sense.

Okay? so, all the manual review processes, throw them away. They, they, they does not, they cannot handle the load, which means that if you cannot automate security reviews, you will release more risks to the cloud. 

Justin Beals: Yeah, 

Idan Plotnik:  And this is exactly what we are automating with our deep code analysis technology. 

Justin Beals: Yeah.

Maybe you done something that would help me out a little bit. I've released a lot of code, but to be honest with you, there were usually smaller teams. We didn't do that. We definitely weren't as heavy handed as Microsoft with our security processes from a code release. Yeah, let's say, you know, prior to Apiiro, what would you consider to be the required steps from a security perspective before code could show could go to production? 

Idan Plotnik: You need from the design, uh, the ability. To codify your security requirements, you need something automatically that will run on every Jira ticket or on every confluence doc design document and say, this is a potential risk design, a design that will introduce a risk or a feature that might introduce a risk automatically.

So before you wrote even one line of code, so, codify or security requirements. Automate the assurance on top of GR tickets and confluence documents, or if, you are using whatever other systems for feature request and design documents, now you commit code, you commit code to the feature bridge; you need an automatic machine in a programmatic way to take the requirements, and validate them against code and then say, okay, Justin, introduce an API that exposes PII data in a high business impact application. Stop trigger a pen test; trigger a scan. You cannot scan everything, but you need first an inventory and then to codify these security controls and validate them automatically.

Now, second step, sorry, third step, you open a pull request. You passed all these checks, but now the code that Justin developed, plus the code that he done developed, together, introducing a risk. One piece of your code and one piece of my code are connected into a risk, a, what we called toxic combination.

So now with the pull request, I need to tell you, Hey, Justin. This is the risk that he done introduced that impact your code. Here are the steps to remediate it or automatically suggest a fix. Now there is the build, and in the build, we are actually building all the code from all the developers. And it's a different set of security controls.

And now you have the deployment, which takes even more risks from open source, you know, and container registries. So you need to calculate all of that, and you need to like check the box that you pass for a security review across all pull requests. You need to check the box that you pass a threat model after you build it, you pass through a SAS, SCA, secret scan, dust scan, and that you have all the compensating controls in runtime.

And then you can release in a secure manner. This is what exactly Apiiro automates. The design, the development and the delivery phases, and then you release to the cloud.  Or not only to the cloud, you can release to our customers release to a hybrid environment to their own prem plus their cloud, plus their private cloud and so on.

Justin Beals: Yeah, so. Idan, I think that there's three major areas that I'm hearing about. One is, is your own code, right? Like the code we write for the software that we build. 

Idan Plotnik: Yeah. Then first party code, 

Justin Beals: First-party code. Great. Then there is maybe what you might call second or third. Those would be the packages that we include in our code, but they come in as source code, right?

They're not, they're built with the rest of the system. They're not binaries in a way. 

Idan Plotnik: But I will call them like. Open source code, because you can actually see their source code in GitHub or in other places. 

Justin Beals: Yeah, that makes, and then the third one would be the infrastructure that it's hosted on, of course, everything from the operating system or the web server through to the cloud environment or hybrid environment.

Idan Plotnik: I will add a few more. 

Justin Beals: Tell me. 

Idan Plotnik: I can take an SDK. SDK is a closed source component, not open  source. Okay. I will give you an example. I don't know Okta for authentication in my code. I don't know the source code of Okta, but I embedding it as an SDK into my code, which is totally different from log four J, which look four J is an open source logging framework.

So you have the first-party code, you have open-source code, you have SDKs,  which is closed source from a vendor that you use. Now you have the source control manager, which is another attack surface because someone can breach and, you know, breach your GitHub account. Now you have the CICB pipeline, which is a different attack surface, like the solar wind, that I can breach and inject code into your Jenkins server. And only then I can I have the infrastructure in the cloud that actually hosts or run this code. 

Justin Beals: Yeah. So you're, you also see the code management tools that we utilize for the software development lifecycle as part of that risk structure that we're dealing with. I would say this 

Idan Plotnik: Is the same attack surface. Because if you, the goal of an application security or application security engineer or security architect, the KPI is to reduce the risk before your code will run in a cloud infrastructure. And if you look at it from the attacker perspective, then the attacker can go and inject malicious code into your own first party code.

It can inject to open source and then you use the open source. It can inject malicious code into Okta SDK and then you use the Okta SDK. It can breach your CICD pipeline and inject like the solar wind case. So you might, and I think this is the missing part in the industry. Everyone looks at application security and software supply chain as siloed attack vectors.

No, it's the same attack vector and it's the same persona that owns like the accountable and responsible for reducing the risk Off this attack surface. Does this make sense, Justin? 

Justin Beals: Yeah, I understand. I think the struggle, though, is where do you get the data for the viable threats to respond to? I mean, you mentioned the CVS, for example, as being maybe a part of it, but in your perspective, not a holistic way of understanding the threat landscape. Is that correct? 

Idan Plotnik: Spot on spot on. So in our risk engine, we take into  consideration the vulnerabilities, it can be CVE, OWASP top 10, CWEs and more. It can be material changes, material change. Like you added, you, you replaced from Mongo to SQL server. It's not a vulnerability, but it's a risky material change that changed your software architecture.

No one looked at it. Because you  use questionnaire for it. This is the second type. The third type is misconfiguration. You are now configured something that is incorrect in Docker file or in terminal file. This is the third. The fourth is I would say,  mailers or unknown. You, you see, a malicious code exfiltrate sensitive data, no CVE, nothing, but it's still, it's a malware in your code. These are, this is the four. We have, we have more like more types, like design risk types, API security risk types, secret risks types. And others. So we calculate them, and we can because we understand your software architecture.

We say, Oh, just a second in this code module that holds the logic off money transfer in my application. I see a restful API with SQL injection that uses log for J that this API sends data to open AI these three things. Are a risk 

We do not rely on CVSS or EPSS. They are great as small factor in the risk analysis.But CVSS or EPSS does not understand my software architecture in a bank or in a gaming company. 

Justin Beals: Yeah. I mean, it is a very binary analysis, right? You're the CVE is a specific vulnerability. It's like affecting specific technologies. Now I'm always since we should dig into AI a little bit. I think both of us have played with these tools a lot.

I'm I, you know, when we say something like understand, And I think that both of us are struggling, or perhaps I am. I'll, I'll own my perspective. I struggle with the Silicon Valley nomenclature around data science. Like it's hard for me, sometimes he donned to be like, we're using words that mean something to other people that they don't understand when we're talking about how, you know, a data science, a model works fundamentally.

When we say understand, tell us a little bit about what's important about understanding the software. Like what does your system want to know from a data perspective? Yeah.

Idan Plotnik: First, I think AI is a fascinating topic because there are so many flavors of AI with different use cases. Okay, but to your question, We are trying to take source code and to translate source code into end components, not lines of code.

I don't care about lines of code, because these five lines of code in this file and these lines of code in different files can be a RESTful API that is connected to a data model that exposes sensitive data. So we need : to take code, translate that into entities. Like API encode, data model, data access object, a GNI framework, authentication logic, a money transfer logic, and under and connect them on a graph.

And then tell you, okay, Justin, you have 10,000 code repos, but if you look at a code repo in a visual way, or the inventory of the items in the code repo. It looks totally different, totally different. And if it looks totally different, then the attack surface is totally different. And then the threat model is totally different, and then the security controls to handle these threats are totally different. 

Justin Beals: Yeah. 

Idan Plotnik: I think we, we, application security exists for 20 years. Okay?. I remember as a kid, I'm not as a kid, like teenager, I was reading the secure code,  a book by Microsoft.

They didn't tell you that you need an inventory of your code component. They told you, you need the SAS tool to scan the code and identify all the top 10 vulnerabilities. I am telling you that we missed the most important thing in application security and software supply chain security. Everyone are saying SBOM.

SBOM is great, but it's SBOM is only a small piece of your software architecture. It's only a yeah of open-source dependencies. What about the sensitive data? What about the APIs? What about my encryption frameworks? What about all the other components that assemble my software? So, TLDR, you asked me what does it mean and why I need it.

It means all of my components that are connected to each other, and they assembled my software architecture, and every software architecture looks different, and this is why I need to understand that to be able to help you secure your software before you release it and deliver it. To the cloud, 

Justin Beals: I certainly have a high confidence in summarization models.

You know, we've been using them for years, right? I've used them for everything from, you know, just mathematical 3D modeling, you know, to pick out vectors to, you know, natural language processing that we're dealing with today. There's a lot of innovation on the summarization side, and I can see how. Being able to look at a piece of code could give us a summary of what that code is trying to do and being able to catalog the component tree.

I like how you think about that into the appropriate generalized risk areas like, you know, this is an API that represents a different type of risk and scan model, you know, it must, I can see it. Coming full circle, literally done. You must've been sitting in Microsoft going, I have to have an API security analysts look at it, and then I have to have a database security analysts look at it, and then I have to have a, a front end, , five O three C analysts look at it, and a resiliency analysts look at it.

And then, my code gets launched six months later. Yeah. 

Idan Plotnik: I, yes. I have nothing to say. It's accurate. And, and I, between us, I know no one is, you need, you, you are lying in these processes, not because you are a bad person, because you want to deliver softer, faster, so you can meet deadlines. And help your company grow and people do not understand that I cannot answer all these questions because I don't have all the, all the answers and all the data, because I don't have an accurate inventory and it changes on a hourly basis.

Justin Beals: Yeah. So how can I 

Idan Plotnik: So how can I keep up with all the risk management processes and questions? It's, it's like, it's frustrated. And this is why we need automation for that. 

Justin Beals: Yeah, I always think I can tell when a team is non-functional, if they don't use the same language. Like we don't even have to talk about they use different tech, but if they can't use the same words to describe the problem, then we know they're not working well together.

Idan Plotnik:  Totally, totally. And I see it in large enterprises. I see it as a huge, huge problem. 

Justin Beals: Yeah, I, I wanted to come back to, you mentioned SBOMs. I've certainly been hearing about them a lot. You know, my perspective on it is like yours. It doesn't prove any security, but I do think it's a, like a compliance transparency issue, right?

Like my thought about it is that you're supposed to share these with your customers so that they can think about the risk matrix of, well, whatever you share with them, but like, like most things, we decide what we're sharing in some ways. Yeah. 

Idan Plotnik: Yeah, first and foremost, I think that SBOM is and should be mandatory in every transaction.

Unfortunately, I think that you said it a few seconds ago, it doesn't represent your application security posture. It's only represent your open-source security posture. And what we are trying to, like, we are trying to influence the industry and some of the frameworks, and we're trying to say it's an extended SBOM/

It's SBOM. What does it mean an extended SBOM? SBOM means that I, I'm, first and foremost, it's a graph format and not a list format. And then you have a graph that represents your APIs, your open source dependencies, your SDKs, your exit points, your sensitive data, and you connect them. Now, when you present This format to a security practitioner on the other hand, on the other side of the transaction, he or she will be able to actually assess if your software architecture has risks or not.

Now, now we support today any type of format of SBOM of, of, you know, generating it. But we also suggest our customers to generate SBOM, an extended SBOM, with all the components in their software architecture. I personally think that it's a great sign, or maybe not sign, it's not the right word, but it's a great progress in our industry of transparency.

I want everyone at the procurement at the, uh, you know, sellers at the technology divisions to understand that they need to be transparent. And if you need to be transparent, you are more, I would say, put more security controls on yourself so other people will not see the problems that you have. So you want to catch them earlier.

Justin Beals: Yeah. I think I'm a big fan of transparency over a number of different concepts in trust. Like, well, like the blessed  modality of trust where someone special or some entity has blessed this other entity and therefore you can trust them. I don't like that as much as you can just see, you know, the right level of information for that entity to have some sense of trust for them.

Idan Plotnik: I think this is one of the Core values of our company in appearance, and I think it should be a core value of every software vendor. We signed the secure-by-design pledge by CISA. Okay, we provide evidence, evidence that, that we are implementing secure by design control security controls. In apparel, and I want every company to do that because we have a very, very sensitive data for, you know, a lot of very large customers.

Okay? and we are responsible for that. And I need to sleep good at night that I have all the security controls, and I have continuous monitoring, and there's no way that any one of our developers can access our customer's data, and we have a multi-factor authentication and we have encryption at rest and encryption and transit and more and more and more.

And I want the customers that sells a pure software. To show me and prove me as well. And this is transparency. And I think we're not there yet as an industry, but I feel confident that in the next, in the next few years, with the proper software inventory, which will be updated automatically without relying on people or, and on based on self-attestation processes, I think we will be in a good shape in the industry because we will at least know what we have, which is a huge problem. If you will think about this, every CISO that goes and build a security program, they start from inventory, inventory of all their endpoints, all their servers, all their cloud assets; why they do not start with understanding your, their software assets, software components?

And if you think about this, it changes much more often than your endpoints and servers. 

Justin Beals: Yeah, I mean, it's interesting. I, I see the, the dilemma too. It's when I think about CISOs, they do that. They're going to go look at how many computers they've got to deal with, what the networking situation looks like.

Maybe those are the areas that have more been a historical issue, you know, just from a percentage basis, because maybe for a while we were okay as software engineers and, you know, generally getting security close to the mark, but we're it's out of our control. Now, maybe that's what I think few that don't write code understand anymore.

And a big, I think an example of that is a crowd strike issue where it's like, You're managing or deploying code to an infrastructure, but you're completely reliant for up to 75 percent of the, the, the, the data that runs your software on third parties and you, it's impossible to keep track of it all. Uh, I don't know if you saw.

Idan Plotnik:  I totally agree with you on the CrowdStrike event, unfortunate event, which again, they are an amazing company and they manage it in a very, very professional way, but Satya Satya Nadella. Okay. It's on LinkedIn. You can see it. He said we need as an industry. I think George courts interviewed him interviewed Satya Nadella because, they form kind of a,  you know, a forum to share more information on how to prevent these things. And Satya Nadella said “secure and safe deployments is a business goal, not a CISO goal”. 

Justin Beals: One of the questions that I wanted to ask you is you have a deep expertise  in writing secure code, I think, and a lot of folks that are coming up as engineers. They,  I did this, so I'm gonna, I'm just gonna own it, Idan. That the reason that some of my code was secure is that we picked a framework to write our code in that helped us align with some important decisions about where variables were stored or how to share that information, uh, what the interfaces for objects look like, things like that.

If you're a young architect, software architect, first, let's say your first gig, how do you want them to approach security from design in the beginning?

Idan Plotnik:   I think  I will say one word: automation. If you think as a, as a young security architect or an application security engineer, that you will be able to buy SAS tool or SCA tool or, and, and check the box, and you are done, No.

At the design phase, you need an automatic programmatic machine. Now, AI can help us and ag as, and again, this is the core, one of the core. Three components that we have in Apiiro, this is the core thing that we are doing. We're saying you can codify your security requirements. For example, you cannot use any encryption framework in high business impact repo, repos or applications except that one.

How can you validate that? You can't go to the developer and tell them from tomorrow, you can't, you can use only one security. No, you need an automatic way to validate that. And if someone is doing a, is violating your policy, you need the guardraining. So automation, automation, and more automation, you need to codify your security requirements.

I don't care if you decide to use five encryption framework on or one encryption framework, by the way, in an organization with 20,000 software engineers, you cannot use one encryption framework. You have 20 different programming languages. You have hundreds of different technologies stack. So you need a encryption framework for each one or for each stack.

This is the complexities. It's a matrix. That becomes multidimensional metrics, and without automation of your security controls and requirements, you will not be able to implement the secure-by-design program. And because. It deviates every day. 

Justin Beals: I, I can definitely, I mean, I think this is a trend we've seen.

 I, remember the days when we had systems administrators, and the only reason they call them DevOps now is because they write code more than they go into the server and change the configuration by hand. And that's the only major difference. And so I think what, what broadly we're seeing is a trend towards programmatic interfaces.

And I, I, I see it in the security side. I see it all over the place. I was reading an article today how Jupyter Notebooks grew by 98 percent in GitHub repos. And they're just such a, you know, those, those things are little code tools. They remind me of the old days of just running basic in the command line.

And I'm seeing it in application interfaces because no matter what your job, you need to know a little bit of programming, I think. We've seen it jump from the Excel spreadsheet into almost all of our software. 

Idan Plotnik: By the way, I, I would say that you don't need to know programming. You can ask CGPT today, even if you don't know how to program.Literally it's, it's insane. It's a beautiful technology. Okay? 

Justin Beals: I'm so careful about describing them in an artistic fashion. 

Idan Plotnik: I don't know. It's exciting. It's 

Justin Beals: exciting. Yes. Sorry. 

Idan Plotnik: I'm taking it back. 

Justin Beals: Oh, I love it. I'm glad. I'm glad to hear others. Perspective professionals. 

Idan Plotnik: You know, my wife, she's not coming with, she doesn't have any engineering background.

Can ask chat GPT to write macro code for Excel or, um, she needed something for her website and she did it without understanding code, which is kind of fascinating, but also scary. 

Justin Beals: I think that use case is really valid. I do, I do like using it for, it's funny. I'll,now I'm going to use an emotional word.

I like using it for inspirations, like little inspirations. So I can give it a topic and be like, “show me some ideas on how to solve this problem”. And I usually take one and we'll extend it some, but it does get, get a couple of ideas kicking. Yeah, 

Idan Plotnik: Absolutely. We are doing fascinating things. You, you talked about the design phase.

We are now, we trained a private model,  to be able to identify like design risks. At the feature request level or, or design document. But the thing is where the magic happened is that where, because everyone can train, you know, a model,  but we have a core intellectual property of understanding your software architecture.

When you combine these two together, the magic happens. I'm telling you, Justin, We saw all, sorry for my French, all the garbage out there that, that startup thinks that they can run a model or, or send all the tickets to check GPT and they will give them high quality. No. When you enrich that with your software inventor and architecture, suddenly you see the threat modeling stories in a different level of accuracy; the mitigation suggestions are becoming because they know that we're that you're using this framework for authentication and this for framework for input validation.

So if the threat is that and, you know, you can be much more contextual in your mitigation approach.  

Justin Beals: I think this comes full circle to what you mentioned about graph data models. It's interesting to me. I work in graph data models for our product design work all the time. It's a very important way of understanding.

I found it a very powerful way. To think about the foundation of a piece of software we're going to build. And so just a little bit like a graph model to me is we have multiple objects, but we have a third piece of data, which is the relation, a definition of the type of relationship between the objects, right?

Like this object has a relationship with this object, they are, they're a brother and sister or they're sibling, or, you know, if you want to use a classic way of data modeling. What I think is really intriguing is that. It's a very powerful way to look at complex systems because you can't hold it all in your head.

So, you need to have a perspective. Right?. Um, are you guys seeing a similar? 

Idan Plotnik: Yes. And I think that people are visual visuals like they understand exactly what you said. It's hard for them to read so many data points in tables. And when you visualize something for them. But. It's so hard again. I don't know.

I'm not, you know, from your domain and what, like what you are doing with graphs. But in our case, if you just take the software inventory and visualize it, it will be a mess. It'll be a mess because the graph is so busy with so many nodes and edges. So you need the domain expertise on how to cluster them and how to connect the right things and you need to understand threats because then you want to highlight the threats and maybe put them, it's, it's a very complex progress process and, and I think we got into a very, Good shape in Apiiro on how to visualize things and, uh, across different use cases.

Justin Beals: Yeah. Similarly, like we're trying to catalog the security posture of an organization and it's broad as possible definition. So it might be HR, financial fraud or cyber security, right? And no one person can really grok that whole security posture. The CISO it used to be their job, but it's too big. And that's why everybody needs their own lens.

And if we don't understand the relationship of data to data, we can't create the right lens for them.

Idan Plotnik: Yeah, I totally agree. 

Justin Beals:  What an exciting conversation, Idan. We really appreciate you sharing your expertise and your experiences. Thank you for joining us today on Secure Talk. 

Idan Plotnik: Thank you, Justin. Thank you for having me.

‘