SECURE& | “75% of Security Reviews Aren’t Code” with Emily Choi-Greene | S5 Ep5

Speaker A: Emily, thank you for coming on.

Speaker B: Yeah, thank you for having me.

Speaker A: Uh, you've been the innovation sandbox. You've had a booth at rsa. You look surprisingly chipper. Uh, how are you feeling? How was it? Was it good?

Speaker B: Oh my goodness, it was amazing. It was truly so energizing. I think, you know, this is our first year doing rsa. We're less than two years old as a company, um, so we're only a team of 11. We had four folks on the ground here and I think for where we are like our stage and size and stage of company, you know, you can't compare yourself to and, or labs or something like that. But for where we are, I think we did just got the most out of the conference that we ever could. So it was a really great week for us.

Speaker A: Brilliant. Well, I'm very happy to hear it. And whoever didn't, whoever. For whoever didn't see you at RSA or see your talk, the animation sandbox. Uh, who is Emily?

Speaker B: Yeah, so I am the founder and um, CEO of Clearly AI. Um, we automate security and privacy reviews for regulated enterprises. And um, my background is as a security engineer. So I spent my first five years at Amazon, oversaw AppSec for all of Alexa AI. So everything from the models running on device through the intelligent decisions in the cloud, our machine learning, compute platform, data platform, things like that. Um, I then went to a company called Moveworks where I owned data security and privacy. It got exposed to what it means to sell AI in the enterprise. And we applied to Y Combinator about two years ago. Exactly. So like kind of end of March, early April 2024 with the idea. Uh, my co founder is my husband. So we were just like brainstorming at home really thinking about where we are positioned to solve a problem that we've experienced ourselves. And um, this was kind of the obvious answer for us. We met working on a security review at Amazon. So very much romance. Um, yeah, wanted to automate away our love story. Um, and so it was just like the perfect fit for us and got in and that's kind of where we've been going from there.

Speaker A: That's insane. How was, how was yc?

Speaker B: YC is amazing. YC is the hardest I've ever worked in my life. It is the most intensive 12 week period ever, I think, no matter what stage your company is in. And we felt constantly behind because we applied to the idea. We didn't have customers, we didn't have code, we had nothing. Just the idea of this is what we want to Build. Um, and so you're looking around at these other companies that have, you know, few hundred thousand dollars in revenue, million dollars in revenue, and you're like, how do I keep, how do I catch up to that? How do we land an enterprise sale in a 12 week period to have traction for demo day? Um, and it was just so energizing, exhausting, um, exhilarating, all those things.

Speaker A: Is it normal that people go without anything other than an idea?

Speaker B: I think there's a huge range. You get founders with just the idea want to say it's maybe a third or so. And then obviously anyone that pivots, you might kind of start again from scratch. Um, but then you also have founders that are coming in with a fair amount of traction. And I think there's a myth that you can be too early or too late for Y Combinator, but I, I think that myth isn't real. I think any company, as long as you haven't raised like a, as long as you're still in 0 to 1 ish and you're not really at that scale up raised, you know, an A, say size YC is a great fit for you.

Speaker A: Incredible. Okay, awesome. Uh, well, and, and like I said at the beginning of this, uh, before we started filming that, I've done a lot of these, uh, interviews and we've talked a lot about security in the, uh, software supply chain. Um, but can you talk to me a little bit more about the vulnerabilities in the system as a whole and like where the biggest blind spots are?

Speaker B: Yeah, definitely. So when we think about the problem that we started the company to solve, um, security teams don't review software, they review systems. And so systems have many more dimensions than just those code vulnerabilities. I think that's what most people miss. Like there's a ton of noise right now and a ton of folks entering the space from the code scanner or even ticket scanner perspective. Um, but code is just one slice of the problem. So about 75% of the reviews that our customers run aren't code reviews. They're data privacy, vendor risk compliance, AI governance. So, so all of the other pieces and aspects around a system besides the actual code that's running inside it, because you need to understand the infrastructure, the network exposure, authentication, authorization. I mean, I could go on, but a, uh, security engineer is thinking about all those pieces and it's that context overall that really helps you understand how an attacker would attack a system besides just the code and like specific vulnerabilities within it. Whoa.

Speaker A: So when you're doing the other 75% reviews, what's the biggest vulnerability or the place where the most vulnerabilities, uh, show themselves?

Speaker B: I think that the biggest issues that you end up finding are ones where there is systematic gaps between two systems. Like you have someone from a third party risk team reviewing a vendor, but they're not thinking about it in the context of the use case that that vendor is being applied to. And so then you suddenly have a privacy gap or a security gap because let's say you're reviewing a vendor like FullStory. And FullStory is an analytics platform that allows you to kind of see what people are doing on your app. But depending on how you integrate FullStory with your application, you could accidentally expose all of that critical customer data of the customer using that app to FullStory. And was that the scope that you actually reviewed FullStory in? And does FullStory have the security posture to handle that type of data? And so then you end up having what is almost this like system design flaw between how these different components fit together because everyone's only looking at it in kind of their isolated silo.

Speaker A: Wow. So how does uh, and I don't want to make this obviously clearly AI sell, but how do you plug your software into that system and then review it all? How does that work?

Speaker B: Yeah, so we review systems kind of in the scope of the use cases that you're looking for. So um, most of our customers will integrate us in an existing workflow. Maybe it's a JIRA ticketing workflow, a vendor onboarding workflow. Um, kind of at the PR level there's different kind of levels you can put us in. But our goal is to gather all the other context and other information that you need to understand the overall kind of threat model or the overall kind of secure design side of it. Um, so basically what folks will do is they'll say, hey, we want to onboard this vendor. But then we'll say, okay, well what's all the data that it's handling and what's the network exposure and what are the integrations and how do we add compensated controls on the organizational side and what is needed for the vendor as well? And so there's kind of, it's a much more about that holistic set of questions. And traditionally that was done by a human and it would be this big back and forth. People would have to go searching through their documentation, ask a lot of follow up questions. And so our goal is to automate all of that kind of manual review process.

Speaker A: Wow. Is there still ah, a need for human within that process?

Speaker B: Yeah. So we recommend, you know, I think that human judgment, especially around security risk is always going to be required for like the higher risk use cases. Like even with that full story example, you know, at the end of the day, our role as security professionals is to surface the risk to the business and then it's the business's decision whether or not they want to accept that risk. And our goal is to say, hey, this is the risk of using this vendor. And the business can decide whether that's a risk they're acceptable with because maybe there's a huge business benefit to using it. And our goal is really to just do as much as we can to give the information that the business needs to make a fully informed, risk driven decision and that needs to be done by humans. So when things are low risk, when things are very cut and dry, we can make automated decisions. We can say, yes, this is approved, low risk, no problem, or no, this is not approved. You need to do these three things to be compliant with our internal policies. And then if a software engineer wants to escalate it, they can escalate it to a human. If it's super high risk, will automatically escalate it to a human. Um, so our goal is to really help security teams focus on the areas where they want to work on those interesting high pressure, high judgment problems. Like as a security engineer, I did not want to spend all my time giving software engineers the same advice over and over again of like, this is how you set up a secure microservice at Amazon. You just need to do these things. No, I will not give you an exception. You just need to do these things. But then when I'm working with our machine learning compute platform and there's nothing else like it at Amazon that uh, allows thousands of scientists to train on customer voice data. That's where I should be investing my time as a security engineer. Not on all these little microservices that are very like just crud based. Right.

Speaker A: So obviously I'm not a cyber security professional at all, but I um, do know that CISOs are up against it when it comes to budgets. They've been asked to do more with less. Um, you know, people want leaner teams. So this seems like a bit of a no brainer, ah, uh, your products. So when, and I don't, I don't, I feel like I haven't spoken to many people who are doing like the whole, like you said, holistic, uh, approach to this. What's the biggest pushback you're getting when you're speaking to customers about your product?

Speaker B: Yeah, I think that a lot of the sentiment is exactly that. Right. How do we do more with less? How do we make sure that we can enable the teams? I think we get pushback sometimes where a team is almost afraid to turn on the faucet of saying, oh, clearly AI will give us all this additional coverage. We know things are falling through the cracks, but this is going to be going from us reviewing a hundred things to clearly AI can let us look at thousands of things. What will that mean for the team? If we still want human in the loop for some portion of it, will that still actually overwhelm my team? And so how do I, how do I play the trade off of visibility and coverage and the automation slider of control of saying, well, I want to make sure that I do have some good control, some good human loop side of the slider? And where do I set that, um, so that I don't just turn on the faucet and like overwhelm my team completely? Um, I think there's also just the questions around, you know, how do I just fold this in? Like, a lot of these processes are super human to human. And they're like, well, how do I automate a process where we're all getting in a room looking at a whiteboard? And so it's a lot of talking through, well, what would it mean to enable your security engineer to get into that room with the whiteboard and be able to spend only 15 minutes instead of an hour? And what, what would they need to know to be able to have that time with the developer be as high leverage as possible. So we thinking about a lot of those things, it almost becomes this like digital transformation. Like sometimes I feel like a bit of a consultant of saying, well, how could we redesign this process to have it so that there isn't this trade off where you're like, well, you don't want speed to then sacrifice security. And security can't sacrifice speed these days. Right. Like when developers ship in minutes, your security reviews can't take months. Um, like it just isn't working. Um, so I think that's a lot of it too is just understanding what does it mean to rebuild and redesign these processes with AI at the center.

Speaker A: That's right. Okay, yeah. Cause you mentioned that, I mean, you said the concern is that there's a lot of stuff falling through the cracks. Your clearly I comes in, identifies loads of this stuff that needs patching and then the team goes, oh, we haven't actually got time to.

Speaker B: Yeah. And we don't want to suddenly overwhelm our developers and we want to make sure that we're giving them super high signal things. And so there's a lot of these classic concerns because in the past automation has come with a lot of false positives. Right. Has come with a lot of alerts. And so how do we besides, you know, ideally people come in, they do a POC with us and they see it for themselves. But before then, you know, how do we help change that prevailing sentiment that security is this thing that is a drain on devs vs an enabler?

Speaker A: Are you seeing um. Thank you by the way, that was a great explanation. And are you seeing a lot of uh, when you're doing your kind of like um, reviews through clearly, are you seeing a lot of shadow AI popping up that's just like not governed?

Speaker B: Yeah, it depends on the company. Mhm. Um, I think that it depends so much on the company. It depends on what level of what their governance process looks like today. If they have an official AI governance process, how easy it is to get intakes through their AI, uh, governance process, whether they have this problem where someone's like, well this sibling team got approved for it, so I can do it. It's all very dependent on kind of the maturity of controls that they have in other aspects for shadow. Like I think if they have good shadow IT controls, they have very good shadow AI controls.

Speaker A: Got you.

Speaker B: Um, some people go as to as far as to have their Zscaler settings literally block any website that has AI in it. Okay, so we have, which is like every website, right. We have a customer where we had to go through this like Zscaler exception process so they could access our tool.

Speaker A: Oh no.

Speaker B: Um, so it's this like really interesting time right now I think. Um, but I think a lot of what we find from like shadow AI cases is existing vendors adding AI and not getting put through a re review and ah, not having a deep dive understanding of how they're using your data. I think that's a huge one honestly. Um, I think the second one would be approving certain tooling for certain use cases and then having use case explosion. So yes, you can use Gemini to draft your emails or to do PowerPoints, but no, you can't use it for this classification of highly confidential data. Who's checking that that's happening? Right? Yeah, so I think those are where I've seen a lot of the Shadow Occurrences happen is where something, some part of it, some slice of it has been approved, um, be it the base vendor or the AI, the AI for some set of use cases. But then there's all these other use cases that the team doesn't know about or people uh, aren't sharing or get detected. And then it's so much more about the holistic piece. Right. It's not about, well, what this AI is, it's about all of the other aspects of the data flows and what DLP controls do you have in place around your highly sensitive data and things like that.

Speaker A: What are you seeing teams do around non human identities, I. E. AI agents, obviously. How are they securing, uh, them and controlling them?

Speaker B: Yeah, and to be fair, like identity is not my personal expertise space. I think that there's a lot of very smart people trying to figure out how to think through this identity space because it's a little bit different than the traditional service account, non human identity. Right. Because often AI agents are acting on behalf of a user and so there's more of this transitive auth problem. So I think the big piece is to say different agents have different scopes of what they're supposed to run. Clearly, AI runs generally as system accounts. So your IT needs to set up a system account for us in jira and that's where you define all of our roles and our permissions and that is what we have access to. And so that's very different than if we were running on behalf of a specific user and got access to all their private information and then had a, ah, possibility of a confused entity attack. Things like that. Right. Like I think a lot of those attacks happen because there's a possibility of escalation of privilege of data via the AI agent itself. And so I guess I'm kind of focusing more on the authorization than the authentication side of identity because I actually think it's more interesting and complicated, um, of like what are you actually authorized to access as an agent versus are you who you say you are as an agent? Because I think that one is slightly easier because you generally are either going a more traditional service account path or acting on behalf of a human generally. I mean, I'm sure there's people that say it's not one of those two things and I'm vastly simplifying it. But where I spend a lot of my time thinking is more the authorization and the access control side because it's just such a new exacerbation of existing problems.

Speaker A: Yeah.

Speaker B: And we even saw that in my Last job at Moveworks. We are a enterprise, uh, IT support company and people would be like one of our customers. I remember this happened because it was like a security incident to us. To me on the security team as the data security person. They were like the Moveworks bot, like hacked our Confluence and they got access to all this stuff it shouldn't. And it's surfacing all this very sensitive data that should only be accessed by managers to all these other people. And knowing the way that we set up our permissions, I was like, no, we just made it really easy for people to access things they already had access to because you messed up the Confluence permissions. Huh. Uh, and so it's not that we did anything wrong. As Moveworks, we're honoring your permissions, but we made it so, so much easier using AI and using Enterprise Search for you to find those places where you misconfigured who should access what.

Speaker A: Yeah. So where does the confusion come in there? Because again, not cyber security professional, of course, just putting that on there. But that seems like a pretty straightforward fix is like uh, if your AI agents have permission to the things they need permission to, to do their particular job, then everything should be fine. But where does it get hairy?

Speaker B: It gets hairy when you have an agent that's like Moveworks is this cross enterprise agent. And then you have information that should only be for some subset of users. Right. So the just managers can see all this performance information. And the problem was that they thought that the MOVE workspace was accessing this manager only information and giving it to non managers. And that was there for our fault. Oh. But the reality was that the uh. And so there was a more of like a confused deputy attack where we were having an escalation of privilege. Like we were causing the escalation of privilege from non managers to manager data. But when we dug into the problem it was like, no, actually the whole time these non managers could access this manager data.

Speaker A: Right.

Speaker B: That was always the case. But we just made it really easy for them to do it because of this AI layer. Oh. Um.

Speaker A: Okay.

Speaker B: Yeah. And so it's like, it's this interesting thing where it's like there's all these different layers of responsibility and controls and often the first thing that gets blamed is the AI system because that's where the end access came from.

Speaker A: Mhm.

Speaker B: But it could be because of some other like missing controls further up the chain. And so we're just acting from what we know. Like you gave us access to that for everyone. You said this is Everyone data. So we're giving it to everyone. But actually it wasn't everyone data. It's manager only data.

Speaker A: And I guess part of it is you should, you don't know if, if these agents have been compromised at all, right? So, so they could have access to the things they should have access to, but you just don't know what the intent is or you don't know if they've, they have somehow been compromised. That is also an issue, right?

Speaker B: Uh, I think so. I think my experience working at enterprises, the vast majority of security incidents don't happen because of like explicit compromise. They happen because of misconfigurations and like mistakes. A lot of them come from mistakes. I mean there is, of course you have, you have people. I mean you have phishing attacks or you have super sophisticated threat actor groups, you have um, malicious employees. But I would say that that's still a pretty small fraction of the overall set of things where it's just like, oops, I was trying to fix this thing and it made it worse.

Speaker A: Do you think people, uh, don't focus on the fundamentals and the basics? And I hate saying that, but the basics enough.

Speaker B: Yeah, I think that it's just true. Proper hardening is like I'm very. And ah. I think we designed our product in this way and people. It's one of those things I think people would. This a little bit of like controversial take perhaps. Um, I'm very checked with Manifesto. I think that there's so much you can do with like just having that huge set of like baseline security controls. And we've really designed our product to think about that first and foremost. And then you can go above and beyond and get creative. But it's this kind of idea of like raising the floor versus raising the ceiling. And so you want everything up at the same floor level. You want to know that everything has those same baseline security controls. And that's kind of comes from my experience at Amazon. Right. It's like those microservices. This is the list of baseline controls. If you hit them, you're probably good to go. If you're not doing anything crazy, just like do all our baseline security controls. And then I think a lot of security engineers though, and a lot of the fun as a security person is to raise the ceiling. How do I go above and beyond those baselines? How do I think about the most creative attacks, most creative threat vectors? And yes, there are plenty of companies that are attacked by like nation state level folks that could go about that insanely creative Threat vector. But the number of. Just spray and pray. Low hanging fruit. I found an open S3 bucket. Let's see what's in it. That's the majority of problems.

Speaker A: But that's, that's such a nice thing to hear, isn't it? Because it's easy to fix.

Speaker B: Yeah, yeah, yeah. It's like someone, I talked to someone. There's like these like levels of attackers, right? Like one through five or so. Right. One is like the script kitties and five is um, nation state.

Speaker A: Right.

Speaker B: Like all of us should be able to do like one through three with a really good set of baseline security controls. You don't need to be a superhero security team or dev team. It's just about insisting on those high standards of. And that's what we help you with. Right? AI, ah, is amazingly good at checking against known things. AI still is getting very good at some of these more creative pieces. I think humans are better. Um, I think humans are extraordinarily creative and that's where we shine. And so how do we help our customers? And just say we've got you covered for one to three as a security engine. You get to now go to the fun stuff and focus on those higher level pieces and higher order attacks. And then over time we can expand. As AI gets better, the foundational models get better and everything will kind of expand upwards too because attackers are getting better every day as well.

Speaker A: Do you think there's any part of security where humans won't be needed?

Speaker B: Yeah, all the kind of level one, all the easy stuff. 100%.

Speaker A: Wow.

Speaker B: Yeah. I mean you want to pass things on off to machines wherever possible because machines are consistent. They don't make the same types of especially deterministic systems. They don't make the same types of mistakes. And so I think there's even going to become maybe it's also controversial, I don't know because everyone loves AI but I actually think that AI is not the perfect solution to every problem. I know, right? What, um, and this is coming from doing a lot of natural language understanding. Sometimes you want a deterministic system and so you want something more like an FST or these rule based pieces because you know you'll get it 100% right every single time. And like the best you can do in machine learning is 9, non in a bunch of nines. You can't guarantee 100% in a probabilistic system. It's just not possible. So you even might see things move m where some portion of this will always be covered by determinism. And then as you get more advanced, you can maybe encode more things into determinism as well.

Speaker A: How are regulatory changes influencing the security landscape at the moment?

Speaker B: Yeah, I mean, I think it's really interesting. I find regulatory changes to generally be a lagging indicator. Um, it's normally responsive to something. And I think that regulators are starting to understand the importance of threat modeling. Like NYDFS part 500 has always had a threat modeling component to it or has for a long time. But then you're seeing more and more pressure towards doing threat modeling in, um, SOX compliance or as part of SEC regulations. And then you obviously have a lot of new AI acts like the eu, AI Act, EU Data Act. Um, we work with a lot of folks on the devices side just from our history as device people. So Cyber Resilience act is a huge one that's coming out. Um, and I think that the positive thing about regulatory changes is because is it puts a real impetus on companies to actually do the work of securing their systems like good regulations will. And good regulations come with real consequences for companies that choose to shortcut those processes. And I do think that's important because at the end of the day, who gets punished when there's like security or privacy incidents? It's often the consumer. And so I think the goal of the regulations are really to protect consumers and to incentivize businesses to actually strengthen and harden their controls like good regulations do. That not every regulation is a good regulation. Um, but I've heard a lot of really interesting things around the good side of the Cyber Resilience Act. For example, like, semiconductor companies have gone through their own kind of industry certification, for example, called psa. They're aligning PSA certs to Cyber Resilience act levels so that you can actually say, hey, if I was a good semiconductor company and was making sure my chips were up to a certain security standard like PSA level 3, I can kind of pass the cybersecurity, uh, Cyber Resilience act for free, so to speak. Um, so I do think that there's, there are some really interesting benefits to regulation. And I think the biggest problem is for these multinational firms to understand, well, what is this impact on me? How do I Do I apply it everywhere? Do I apply it regionally? I remember at a conference, Airbnb gave a conference talk about how they built out their own cookie consent to be different in every single one of the 50 states. Because for their business bottom line, that made more sense than to just apply the same Standard everywhere. And so I think you'll get a lot of that interesting decision making process. And for us, our role as a company is to help kind of companies think through that and think through what their requirements are from a common controls framework perspective. And how do you change what you're currently doing because a new regulation come in, comes in. Do you need to. How does that new regulation map to your existing controls? Where are there gaps? What systems are affected? All those pieces.

Speaker A: Fantastic. Final question. I know how quickly the world moves at the minute and I hate to ask for predictions, but if you were to give us predictions for the next 12, 24 months, what do you think the security landscape is going to look like?

Speaker B: I think it's going to get noisier before it gets quieter. Um, I think it's going to continue to. I think it's an incredible. It is the best time in the world to start a company. Right. And so I think that there's a lot of folks that want to be part of the new AI native wave. And so I think, you know, I don't envy the buyers in this situation. Like, there's a lot of noise and I think our hope and goal is to help people understand what's happening, help with the signal, and at some point we'll kind of work our way through the cycle and there'll be a lot less of that kind of uncertainty and doubting, can I build this in house or should I build this in house? And what would it mean to build versus buy in the different ways that different vendors are solving different problems and the overlapping problem spaces? Because I do think that we're going through like a seismic industry change. I think everyone agrees about that. I think there'll be a lot of AI specific security tools that people will start to realize that you maybe don't need an AI specific security tool. You just need a security tool that solves for that class of problems that includes the AI pieces and dlp. Do you really need an AI specific DLP solution or do you just need a DLP solution that thinks about AI as part of it? So we're kind of on the bet of like, you don't need an AI specific governance play or risk play. You need something that thinks about the overall risk and some of those risks are AI risk. And that's what we do, the whole thing, not just AI risk, just to be clear.

Speaker A: No. Awesome. Well, thank you so much for coming on. I really appreciate it.

Speaker B: Yeah, thanks for having me.

Speaker A: Uh, and that's it for this week's episode. Thanks so much for listening and I really hope you enjoyed it. Anything we talked about will be linked in the show notes. And if you haven't already, don't forget to subscribe wherever you listen to your podcasts and we'll catch you on the next one.