The Future Of API Security With FireTail’s Jeremy Snyder

Jeremy Snyder: "Now, GraphQL that has started to rise in popularity over the last few years reverses the REST paradigm of having a defined backend that tells you what it can do. Whereas, it has this nebulous backend that has potentially access to all of the data. Now, that does introduce some other vulnerabilities around limiting query complexity and depth, and scraping datasets with GraphQL is actually kind of easy, if you know how to issue the queries. But I do actually suspect that more and more services that want to make themselves available for an agentic AI to consume are going to move to that GraphQL model, because they don't know what the AI might ask for. And it's a lot easier to do that and to expose it to an AI through GraphQL than it is through REST.

[INTRODUCTION]

[0:00:51] Guy Podjarny: You are listening to The Secure Developer, where we speak to industry leaders and experts about the past, present, and future of DevSecOps and AI security. We aim to help you bring developers and security together to build secure applications while moving fast and having fun.

This podcast is brought to you by Snyk. Snyk's developer security platform helps developers build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open-source dependencies, containers, and infrastructure as code, all while providing actionable security insights and administration capabilities. To learn more, visit snyk.io/tsd.

[EPISODE]

[0:01:30] Danny Allan: Hello, and welcome to another episode of The Secure Developer. I'm Danny Allan, CTO at Snyk. I am super excited to be joined today by the co-founder and CEO of a company called FireTail, Jeremy Snyder. Jeremy, welcome to the show. How are you?

[0:01:44] Jeremy Snyder: Hey, I'm doing great, Danny. Thanks so much for having me. Really excited to get into today's conversation.

[0:01:49] Danny Allan: Yes, likewise, Jeremy. I am always excited to talk to people who have a depth of expertise in security, and I know that you do have a depth of expertise in security, and especially, API security, and AI security. But maybe, let's just start off if you can introduce yourself to the audience. I'm sure many of them know you already, but just background and how you ended up in the position that you're in.

[0:02:10] Jeremy Snyder: It's been a journey. I think I started like a lot of people in the security world, and that I'm kind of a failed software developer. Early in my career, I, you know, I went to kind of interview for a position and got the job. But then, once I actually got started with the company, mind you, this was a company where half the software development team was Ph.D. So, they were very deep subject matter expertise on something called natural language processing and neural networks. This is back in the late 90s before those were, let's say, like common mainstream terms that everybody would have thought about. But my background is in computational linguistics, had a very nomadic upbringing, lived in four countries and four states by the time I graduated from high school. Then, did half of my university education overseas.

I thought I ended up in exactly the right domain space, and I spoke about five, six languages at that time. I'm like, great, computational linguistics, computational linguistics software company, perfect for me, get into the real world. They're like, "Yes, sorry, buddy, you're just not quite good enough for the software development team." But the company was growing really fast at the time, and they're like, "Look, we have a great opportunity for you here, go down kind of the IT and security route for us, we're growing super fast." So, it was a lot of time spent on infrastructure, a lot of time spent building data centres, time spent tearing data centres down by the way. We went through the build-up and then the dot-com bust. Then, kind of had to rebuild the business after multiple rounds of layoffs to get it to a good shape and company was acquired in 2005.

That was kind of my first foray into very deep, hands on, everything from the 3am trip to the data centre, fix a server swap, a hard drive, a fan, what have you, to responding to breaches and incidents, where one of our servers was misused for a particular purpose for a period of time. Happy to talk about that more if it comes up in the conversation. But I went to another software company after that, and a video game company after that, doing more or less the same thing, IT operation, cybersecurity, security operations, everything related to it.

Then, I joined a little startup called AWS in 2010. They were –

[0:04:20] Danny Allan: Little?

[0:04:20] Jeremy Snyder: Well, it was very little at the time. It's really funny. Just the other day, I was sitting down with a couple of current AWS people here in the DC area at HQ2, at an event over there. We're in this kind of conference room, and I was commenting to this guy, Joe, really nice guy over at AWS. Shout out to Joe. But the entire AWS sales organisation at that point in time would have fit in that conference room, and I know that firsthand, because I was at the very first sales kick-off. It was a global sales kick-off that had the entirety of the AWS sales organisation. We're like 50, 60 people in 2010. So, it was in ways a startup. Obviously, it had the backing of this already very large e-commerce company, Amazon behind it.

But it was like fundamentally a transformative experience, in the sense that I learned so much about, there's very little value in physical infrastructure. Obviously, you need the infrastructure to run applications and services and everything like that. But I don't know, I mean, just thousands of hours wasted cabling, and uncabling, and whatnot, and what Verner Fogel likes to call, the undifferentiated heavy lifting that you have to do, but maybe there are better ways to do it. It really changed my way of thinking around it.

I kind of stayed in the cloud ecosystem ever since. After AWS, I did a bit of kind of consulting for a little while around cloud computing stuff, joined a system integrator that was migrating companies to the cloud in 2014. Then, in 2016 joined a, what came to be a cloud security posture management company. I don't think when I joined in 2016, first of all, I don't think that acronym existed yet, CSPM. Now, it's super commonplace and it's in every Gartner quadrant, whatever. But, that company, we grew from something like four or five customers in that first year to over 100 four years later. We kind of doubled the size of the customer base and the revenue every year. Had a really great run, great teammates to work with.

We were acquired in 2020 by Rapid7. I spent some time with Rapid7 post-acquisition working on M&A, and on some strategic initiatives over there. I was fortunate enough to be a part of the team that did three acquisitions in 2021. One of the things that had always been stuck in my head from my time working on cloud security was that, along with cloud, you tend to see this kind of, let's say, second wave of cloud adoption. You see this first wave where companies are like, I've got to get out of the data centre. You'll hear the lift, and shift, and the whole, let's just migrate up to the cloud. Great, awesome.

Then, two, three years later, they're like, we're just not getting this scalability and flexibility that we were promised that our rep told us about. Then, they realised when you look at like how do you make that a reality, you actually have to spend a lot of time transforming your software architecture to work with that. You can't have it where you have, I don't know, monolithic services or certain cold start services. You really need to do often a lot of decoupling of different parts of an application stack. What we saw as companies kind of realised, that that was something that they needed to do is they would tend to go down one path or another. That could be like, "Well, we're going to break this up and make the service A and service B, or we're going to break this up and like this part will be long live. But then, we'll have these on-demand services on, I don't know, like on a serverless platform, or we go containerise, or some combination thereof" But the end result is always kind of a huge growth in the number of APIs that the organisation is running.

I started looking at this as early as like 2019 and thinking about it, and kind of in 2021, when I left Rapid7, my co-founder Riley and I, we sat down and we started brainstorming. "Remember that API problem?" He had been at a large media company where he was like, "Yeah, we're living that, we're going through that transformation." So, he had kind of, firsthand experience of the pain points around it. We realised that, every piece of data would transit over an API at some point. With that, all of this sensitive information, it could be at risk in any one of those interactions. That was really kind of the backstory and the genesis behind FireTail. That's a little bit about me.

[0:08:44] Danny Allan: That's awesome. Is it true that AWS was API first? That had to be somewhat formative as well, when you're looking at FireTail and kind of API security, because my understanding is, they're always creating an API before they created a UI for it.

[0:09:00] Jeremy Snyder: Absolutely.

[0:09:01] Danny Allan: It's in their infrastructure.

[0:09:02] Jeremy Snyder: Yes. Well, not only is AWS API first, but there is the kind of legendary Amazon API memo that if you just Google that, you'll find that. It was before my time at Amazon. So, I always heard of it second-hand through stories about what had happened. The way I heard the story, and I don't know actually how much truth is in this, It's always through retellings that you hear it. But you will Google it, and if you Google it, you will find results that kind of talk about this. Was that, there were so many new parts of Amazon that were growing up.

You had the kind of classic, what we call the e-commerce side of the house, the amazon.com. But then, you had the marketplace that was growing up on top of amazon.com. Then, you had, let's say, the Kindle business, and there was Amazon Music and an MP3 store. There were all these new initiatives, new things that Amazon was launching. A lot of these new initiatives would want to tap into something from one of the other organisations. Just as an example, maybe Kindle wants to understand the e-commerce user base. So, they would want to go talk to the e-commerce side of the house, and get data, and get information.

The way that I heard it in the telling was that, it was creating so many kind of cross-departmental meetings that were sucking up such amount of time, that at one point – again, apocryphal story or not, supposedly, it came from Jeff Bezos himself saying that, "Look, we have to stop these cross-departmental meetings that are killing productivity. Every department has to create an API so that other departments can consume their data, query their data, get understanding about those things." That was part of Amazon culture, not just AWS. But what you said about AWS services, API first, and then, it tended to be Java SDK would very often also come before, and say like, the management console UI.

[0:10:56] Danny Allan: Yes, and there's lots of security implications that come along with that. When I think of security implications on the API front, I tend to think, and I'm looking for your guidance or expansion on this. I tend to think of number one, probably authorisation, maybe number two, authentication, number three, the configuration of it. What are the big things that the secure developers need to think about when they're thinking about security in the context of applications and APIs specifically?

[0:11:24] Jeremy Snyder: Well, you've certainly hit the top three. That last one has a few components, subcomponents to it. But authentication authorisation are always number one and number two. Authorisation is like, number one with a bullet when you think about where mistakes get made. So, if you ask, "Hey, how does actually data get breached through APIs?" It's almost always through a lack of an authorisation check. To be more specific and more detailed about it, it is typically a fallacy that authentication and authorisation are the same thing, or it's that I can push my authorisation check somewhere else. I can and push it into, let's say like the mobile front end, the mobile app, or into the web front end, or something like that.

What I always tell people is like, first of all, your backend API is so easy to discover. I can – if I'm using your web application, I can just open the console in my Chrome browser, and I can see all the API requests complete with the URL. I can see the full packaging of the request, like that's not rocket science. If I'm using a mobile app, great. I'll just use it from my home Wi-Fi. I'll turn off my 5G, I'll just make sure all of my traffic is going over Wi-Fi. Then, I'll go on to my little internet router, and I'll just pull the logs. I will see all of the API requests. Neither way is difficult. Finding your back-end API will happen. So, that's one thing.

Again, authentication and authorisation, not the same thing. That's kind of the second big point. So, who Danny is, is different from what Danny is allowed to do. Authentication is establishing that you are Danny. Authorisation is like, is Danny allowed to do this action with this data? Just tell people from an API perspective, you need to think about it as a three-part kind of calculation. You have your principal, resource, action. So, you have your principal, which is the user, the requester. The resource, the piece of data that the request is active on, and then, the action, what do they want to do with it.

A good analogy that I like to use for this is like, let's just think about our LinkedIn profiles. Okay. So, Jeremy can view Jeremy's LinkedIn profile. So, principal is Jeremy, resource is Jeremy's profile, action, view. Jeremy can edit Jeremy's profile, very straightforward. Jeremy can view Danny's profile. Jeremy cannot edit Danny's profile.

[0:13:52] Danny Allan: Hopefully not.

[0:13:53] Jeremy Snyder: Hopefully not. Otherwise, LinkedIn have some issues. But that's in a nutshell the authorisation problem. Just to kind of finish up the point around these things, the thing that I always tell people who are asking me, "Okay. Well, what's the single biggest problem?" Well, the single biggest problem is that you don't do a server-side authorisation check. But when you couple that problem with the number two kind of configuration problem, people so often rely on the primary key of a database record as the identifier, and that is very often present right in the request parameter, so very present in the URL, in the API request that gets sent along. Then, people do sequential integer numbering. They just rely on the database to handle that. Why? Because it's super easy and we're used to it.

What that leaves you kind of vulnerable to is when you go on to LinkedIn or whatever service, and you find one of what's called Ebola, a broken object-level authorisation problem, where you're not doing that server-side authorisation check. It's like, "Oh, okay, requester ID equals one, profile ID equals one. What happens when I change it to requester ID equals one, profile ID equals two? How about three? How about four? How about five? Typically, when that authorisation check is not in place, and you have that kind of sequential integer numbering, that typically leaves an entire data set vulnerable to exfiltration. Which is why in the case of API breaches, the number of records breached per incident is actually a couple orders of magnitude higher than the overall, like how many records breached per incident that you'll see from like the IBM report.

[0:15:33] Danny Allan: They're iterating through continuously just up the number stack. Yes. So, you get hundreds of thousands of things breached.

[0:15:39] Jeremy Snyder: Oh, millions?

[0:15:40] Danny Allan: Or millions of things breached. Yes, totally makes sense. There's been a push on the authentication side around two-factor authentication. Do you see that going away in the future or being solved in the future? I know that there's lots of issues with SIM swapping and SMS multi-factor authentication. Do you think it's going to get better than it is today for individuals of services or no?

[0:16:09] Jeremy Snyder: Well, I wish I could say yes, but I honestly kind of don't think so. I think the thing about it that worries me a little bit is that, it's really just the practicality and the human nature side of it. So, first of all, it takes effort to turn on. It's not the default for most services that you go use. If customers sign up for FireTail, we actually require them to set up their second factor authentication on their sign-up. We definitely lose some users who go through the sign-up process and they're like, "Ugh, can't be bothered." We kind of just made that choice, but it is a design choice. But most consumer services don't. You want ease of use, you want simplicity, you want it, so that classically, even your grandmother could use it. It's not easy to convince grandma that as she's onboarding onto whatever email service, social media platform, picture sharing, I don't know, online banking, whatever it is, she needs to pull out an authenticator app, and scan a QR code, or she needs to type in a six-digit code from an SMS.

Then, the other part of the human side that kind of concerns me is, in a lot of SIM swapping cases, it looks like one of the weakest links is underpaid customer support agents at the mobile carriers. That's a real concern. If you're making $15 an hour, and somebody on the side offers you $300, $500, $750 to swap out a number, that you know, eventually that person is going to be able to call in and get their number back by verifying their identity or whatnot. Who cares? You're probably not going to stay in that job for a long time anyway. What's the turnover of call centre agents? It's got to be crazy high.

[0:18:01] Danny Allan: Yes. I always say, the humans are always the weakest link. We used to do red team hacking, and we would call people up, and we would offer them twice their salary if they wanted to come to this new company, and then, you'd start asking them questions, and it was just – they would vomit out all the information about their entire infrastructure, Because you are compromising human greed or the people systems themselves. Do you think microservices, Jeremy, have made us less secure? You talked about authorisation being an issue of the authorisation to the service. One of the results of microservices and segmenting applications into all these tiny little pieces means that you better have authorisation for every service talking to every other service.

Do you think that the fragmentation of the microservice architecture by definition makes this less secure or you just think, you need a common framework and it will be okay?

[0:18:57] Jeremy Snyder: It's hard to give a definitive yes or no to that. I'll tell you kind of like two conflicting thoughts in my head around it. Number one is that, our own research on this, where we've been tracking it, and we have this API data breach tracker on our website, where we do our best to aggregate all of the API-based data breaches that we can find, that are kind of confirmed out in the real world, or responsible disclosures that do get, eventually, made public, et cetera, just to bring awareness to it and so on. But it's interesting because it's also turned into a data set. We analyse it on kind of a regular annual basis, and we look at, "Okay. What's the number of incidents over the last year? What's the volume of records over the last year?" Et cetera.

On the one hand, just looking at the trend lines from it, that number keeps growing and growing, and it grows at not a linear, but not an insane exponential rate, but it's something like, you know, 1.8x year over year, or like 2.0 something x year over year. So, it is growing faster than it should. So, there's part of me that says, yes, to your question, like microservices have actually introduced more and more vulnerabilities around the APIs and so on.

The other part of me says, well, like look, in the grand scheme of, let's say, the Internet. If you look at the pace of growth of the Internet and the number of services that are online, it's maybe commensurate. So, it's maybe not accelerating more rapidly than the growth of the overall internet. The other part of it is, that it's, I think it's to a large extent, just transfer the risk from one point to another. In the case of microservices, I think the risk isn't super well understood. I think a lot of organisations are focusing a ton of time on things that they've been doing for the last few years.

What I mean by that is, if you think about kind of, let's say, rewind five years. We all went into lockdown, mad rush to the cloud. Well, we're still kind of dealing with the fallout from that, where a lot of organisations are kind of buttoning up their cloud security posture now. Because for two, three years, they just like pushed a bunch of apps up, and migrated, and moved workloads and so on.

[0:21:05] Danny Allan: All the S3 buckets are open.

[0:21:06] Jeremy Snyder: Exactly, exactly. So, we're still dealing with like the open S3 buckets, and the open security groups and the RDS Instances that have accidental public exposure, all of that kind of stuff. So, I think it's just, to some extent, I think there's just a transfer to a new attack surface that is not as well understood. Well, I know that you do a study on this. I always look at the Verizon Data Breach Investigation Report, but FireTail does one too on the annual state of API securities. Is that right?

[0:21:32] Jeremy Snyder: We do, yes. We've got our kind of 2025 report that really covers last year, 2024, coming out in about. Well, it'll be coming out in late March, early April 2025. So, depending on when you might be listening to this or whatnot, it may have already come out, who knows. But when we're going to be looking back at, again, what were the growth rates, what are some of the new and novel trends that we've seen. We like to do a mix of things. We like to look at obviously that data tracker and kind of what's happened in the real world. We do some sampling, some anonymised sampling of our own customer data for what's out there, which always proves to be interesting. Some of the most interesting stuff about it is when you look for, like, show me requests that look like no other requests. Just like very oddball requests.

Last year, one of the things that we saw, was we saw attempts to plant Mirai malware, the Mirai botnet malware via API calls. We're like, that is weird. You could look at the requests, and if you look, there was like this request parameter where really, the payload is a bash script. It's trying to execute a series of kind of command-line commands that are saying, "Hey, change directory, change mod, change permissions on this directory, and then, go access this server and download this payload, then execute it. All written out as this like one long aggregated string and the request payload. So, that was super weird.

We're looking at all the kind of new stuff like that that we're seeing, and of course, like one of the things right now that is maybe one of the top use cases for APIs right now is LLM integrations. And how our company is using APIs to integrate with third-party LLMs, and what are some of the security impacts around that, and some of the risks around that. So, some of that will show up in the report as well.

[0:23:26] Danny Allan: I have a question about how AI and API security intersects a very specific one, but maybe, if you can just provide a general overview because AI and LLM-backed applications are becoming way more prevalent, at least that's what we're seeing here at Snyk. APIs are the exposure point or entry point into a lot of these applications. Am I reading that right?

[0:23:47] Jeremy Snyder: Yes, totally. I mean, look, there's obviously the exposure point of what's Danny doing in its web browser with ChatGPT, all well and good. I mean, technically, that's API interactions as well. But I'd say, like the larger exposure is really how are we integrating this corporate data set, this in-house application, or customer-facing application with a third-party engine? That integration is all API driven as well. So, no, I think you're reading is spot on.

There's a bunch of new risks that come about as a result of that. It's interesting, because obviously, very early days, and certainly, if this were the news report, this is the point where I would say, the story is still developing, and we'll be back to you with updates as we have them, because that is the reality of the situation. But what we're seeing already is, we're seeing the kinds of, let's say, call them combined risks, where you have a risk from something like the LLM. And the way to kind of trigger that or to access that vulnerability is through the API.

I'll give you an example of something that was recently disclosed, where there was a vulnerability in OpenAI's ChatGPT web crawler. The vulnerability is in the API, but what it kicks off is an AI function. What it was that, you could hit this one endpoint of the OpenAI web crawler API, that did not require authentication. So, there's already one bad point. Second is, you could then feed it a list of URLs to go index for its web crawler function, and you could actually feed it the same URL, like kind of an infinite number of times. If you wanted, you could put various variations on it. So, you could say, domain.com/a/b/ whatever. Or you could do, a.domain.com, b.domain.com, whatever you wanted to do.

You could just give it this insanely long list that was always hitting the same domain name. It wouldn't do any kind of, let's say, like input validation to check. Is this actually the same domain name like once, or are we getting a bunch of extraneous requests for it? Then, it would kick off a parallelised crawling of the target domain, and it would kick off literally thousands of threads in parallel. The net result of which was to effectively DDoS the target website, because you had thousands of requests kicking off within seconds. Not that many websites are designed to stand up under that level of traffic hitting all at once.

Even if you have a CDN, you might have some ramp-up time, parallelise the requests, et cetera. So, this type of knock-on effect of an application with an API, that then connects to an LAM is just one example of the risks that we're seeing around this. There's a couple of others, but a lot of them really are around. How is the data being passed? Is the data being passed in a sensitive way? That's over APIs. How are the requests being lodged? Are there any extraneous things, or let's say, factors that are contributing to the request? Those are all over APIs as well. There's very tight connection between API security, and AI security.

[0:27:09] Danny Allan: Do you think we need to have a differentiation between AI requests and people requests? Let me give you a specific example. If I go to a website, and I say, I want to consume FireTail and I make a request. You know generally that it's coming from me, it may be authenticated or not, but you can see user agent stage. As we go towards agentic AI, an AI is doing things on behalf of a user. So now, I go and I say, go book me a ticket to the Bahamas, and the agent goes, and does five requests. First of all, it goes to my bank, and then, it goes to the booking site. It's doing it on my behalf.

Should the receiving site know that that's an agent or AI doing that transaction versus Danny directly doing that transaction? Do you have a thought on this? I've been thinking about this a lot recently. The agents now are going to be acting like people, and it's hard to know how to handle the authorisation and – not the authentication, but the authorisation of it.

[0:28:08] Jeremy Snyder: Yes, it's a great question. I don't know that I have a real strong answer yet, because I think it is so early, and so on. What I would say is – what I will say I absolutely expect to happen is, I do expect that some company will build a piece of software that helps website owners make that determination pretty quickly here and does differentiate the services. I think the reason being is that, I think companies will realise that they can charge a premium to an agent.

Now, it might actually backfire, it might work out the other way where companies realise that they actually have to offer a discount to an agent, because an agent is 100 times more effective than a human at going and testing the same transaction on, let's say, like 100 e-commerce websites in parallel. So, let's say, if I'm like comparison price shopping, it could be the case that they figure out like, "Oh, I better offer my best and lowest price immediately, or this agent will go find a better price elsewhere.

But part of the initial reaction that I had is that, if you look at things like websites for airlines right now, you will almost always see a difference in pricing based on where you're browsing. You will often see a difference in pricing based on whether you're logged in or not, whether you're, let's say, authenticated as a user who's member of a loyalty program. By the way, it's often unpredictable. You might think that, oh, a user in this geography would always get a better price than the other. We have a team in Ireland, and sometimes, if we're looking at, let's say, like the company traveling to Black Hat, we will price shop and compare. What is the price for my co-founder to fly over from Dublin to Las Vegas when he searches from Ireland, and when I book on his behalf from here in the States?

It has gone both ways. There are times when it's been cheaper for him and vice versa, and there are times when it's cheaper for me to buy a ticket on United when I'm not logged in, versus when I am logged in. It's hard to say, but I do think there will be that kind of differentiation that you point out, and companies will realise.

[0:30:13] Danny Allan: Well, it's interesting. There is an opportunity there at some level to use AI to figure out where is the cheapest place to come from and the cheapest browser and automate all of that. It's definitely going to be a cat and mouse scheme. On the API front, because a lot of the communication cross systems right now is through APIs. Do you think APIs are going to change because of AI? I know model context protocol and some new ways of communicating across agents is going to take place. Do you think fundamentally will shift because AI is non-deterministic? I mean, it doesn't read an API set, know what's allowable and what's not allowable. Do you see the industry changing?

[0:30:50] Jeremy Snyder: I do. As a matter of fact, it's a great point that you raised there about that non-deterministic aspect of AI. It's funny, and apologies in advance if this gets a little geeky and deep on the API side. If you think back to when API has kind of started as a mainstream concept, weirdly enough, I think Microsoft does not get enough credit for introducing the concept web services. You think about these concepts that were introduced in like early 2000s with like SOAP, and WISDL, and XML, and all that data exchange. Honestly, all of that is kind of the precursor to the APIs that we have today.

They had that vision at the time of like, sites are going to interchange data, and sites will negotiate with sites. Now, we would say, agents will negotiate with agents, or AI bots, and whatever. They had that concept; they didn't really evolve that concept over time. So, what ended up happening was more the open-source community realised that, okay, this is all well and good. But these document type definitions and so on, they're super cumbersome to maintain, and every time I want to add a field, I got to update everything, and then I break all my integrations and whatnot.

We'll just go with a more loosely coupled system and we'll go with JSON, it's a lot easier to write, and read, and takes less characters, more efficient to compress, and transmit everything about it. We'll go with kind of REST as a way to interchange data, and it doesn't have to be like a strong connection that sustained. That kind of became the state of play. But JSON is also somewhat restrictive in terms of what's available, is what's on the API at the backend.

Now, GraphQL that has started to rise in popularity over the last few years offers this kind of like other aspect of how you can do it. It kind of reverses the REST paradigm of having a defined backend that tells you what it can do. Whereas, it has this nebulous backend that has potentially access to all of the data. Now, that does introduce some other vulnerabilities around like limiting query complexity, and depth, and scraping datasets with GraphQL is actually kind of easy, if you know how to issue the queries. But I do actually suspect that more and more services that want to make themselves available for agentic AI to consume are going to move to that GraphQL model, because they don't know what the AI might ask for. It's a lot easier to do that and to expose it to an AI through GraphQL than it is through REST.

[0:33:28] Danny Allan: Yes, I totally agree with you. I remember how transformative it was. I used to write with JavaScript, you'd have to unpack the XML and do the XSL teacher installation. When JSON came along, it was like, "Hallelujah." You didn't have to do all that.

[0:33:42] Jeremy Snyder: Thank goodness, right?

[0:33:42] Danny Allan: Massive. It was just a lot of overhead. I do agree. I think AI is going to take it to the next step where it's even less structured. I think it's the only way really we can go forward. Last question, what makes you most optimistic about the future? I mean, you're deeply entrenched in this AI and API security world. Do you see hope for better security in the next two to five years? Or do you think we just don't learn from lessons from our past? It's going to get worse before it gets better?

[0:34:12] Jeremy Snyder: Well, I will say, if we don't learn, it will get worse before it gets better. But to answer your question about what gives me hope is, I know I said earlier in the conversation that still some organisations are playing catch-up from the mad sprint to the cloud during lockdown. But what does give me help is that, with each wave of technology change, and I've lived through a few of them, right? Let's just say, from cloud to microservices, to now AI. With each wave, what typically ends up happening is that, typically, the business is a head of security. Somebody somewhere will start using this new thing before they've gotten formal approval within the organisation because they're just like, "Dang it, it solves my needs, I got to get it done."

In the case of cloud, it was always like, somebody somewhere would be like, I'm just going to put this on my credit card, and expense it, and we're just going to get started with AWS, Azure, what have you. Similarly, some developer would be like, we're just going to have to break this thing down into services, and look at this as API transactions, et cetera. The hopeful piece is that what ends up happening later is that business gets out in front, security follows behind, and they have to kind of clean up the pieces.

That gap between how far ahead the business gets to when security wakes up and says, "Oh, we better get our arms around this." I think that's shrinking. So, in the case of cloud, we saw kind of like in many organisations, it was like a couple of years before they realised like, "Hey, we better go figure out how bad our cloud state is." In the case of microservices, maybe it came down a little bit. But with AI today, one of the things that we're seeing as we kind of roll out some of our own AI capabilities, and we start talking to organisations, is that security teams now really realise, they have to be much closer to the business adoption stage.

With that said, what gives me hope is like, "Okay, if they can tighten up that timeline so that they're really kind of running in parallel to the business adoption of the technology platform, we can avoid the situations and the mistakes of the past, where you had a lot of, let's say, unmitigated adoption without good security guardrails around it, or without good awareness and understanding about what was going on. We can close that time frame gap. I think that's actually a really positive trend. I think AI is actually where we're seeing it better than we've seen it with previous new technology waves.

[0:36:37] Danny Allan: Ironically, AI helps you in the understanding of the new technology, which helps you again drive down that gap. So, that makes me enthusiastic about the future as well. I mean, even here at Snyk, we're using AI internally at the executive levels, where in the past, as new technologies came through, you didn't always do that type of adoption.

Well, Jeremy, it's been fantastic to have you on the Secure Developer. I know that API is an AI security's top of mind for almost to every one of our listeners. So, I appreciate you having on. To all of our audience, thank you for joining us today, and we look forward to having you next time on the next edition of The Secure Developer. Thanks, Jeremy.

[0:37:16] Jeremy Snyder: Thanks, Danny.

[OUTRO]

[0:37:19] Guy Podjarny: Thanks for tuning in to The Secure Developer, brought to you by Snyk. We hope this episode gave you new insights and strategies to help you champion security in your organisation. If you like these conversations, please leave us a review on iTunes, Spotify, or wherever you get your podcasts and share the episode with fellow security leaders who might benefit from our discussions. We'd love to hear your recommendations for future guests, topics, or any feedback you might have to help us get better.

Please contact us by connecting with us on LinkedIn under our Snyk account, or by emailing us at thesecuredev@snyk.io. That's it for now. I hope you join us for the next one.