Akansha Shukla - Modern AppSec: Securing APIs with Threat Modeling and DevSecOps

0:00Chris RomeoToday, we're talking with Akansha Shukla, an information security professional with over 10 years of experience spanning application security, DevSecOps, API security, security architecture, threat modeling, and risk assessment. She's known for her innovative problem-solving approach and has a proven track record of safeguarding organizations against both internal and external security risks. Akansha is also a mentor at WomenForCyber, where she's passionate about empowering the next generation of security professionals. We're going to dive deep into API security today, specifically looking at why it might be one of the least mature pieces of AppSec right now, how threat modeling fits into the API world, and the challenges around securing these often overlooked components of our applications.

0:45The Application Security Podcast is brought to you by Security Journey. We provide diverse training content and easy-to-digest lessons to meet individual learner needs. Learners report improving their knowledge as much as 85% on AppSec topics. Learn more at securityjourney.com.

1:01Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I'm a VP at Security Compass and also co-host of the Application Security Podcast, but Robert is not here today. He is on an airplane, Flying away somewhere excellent, I hope. But I'm joined by Akansha, who is going to help us dive deeper into API specifically. It's going to be kind of the core of our conversation. So Akansha, before we before we start talking API, we always love to jump right into security origin story. So we always love to hear where people how they got started, where they're coming from, all those types of things. So if this was a comic book, episode number 1 of the Akansha security story, what would we find in that first issue?

2:04Akansha ShuklaSure, um, thank you, Chris, for having me here. Uh, about my story, it's a bit, uh, I would say roller coaster. So, um, being a mechanical engineer, I switched into cybersecurity. So, uh, I think, uh, it was very fascinating for me because from mechanical engineering, I really learned how you can do anything, to be honest. Yeah. So, and then I started coding. So I was like, for 6 months I was developer for .NET and then I switched into cybersecurity. So it was a long time back in 2015 when I started actually testing, security testing. So I did vulnerability assessment, pentesting, and used several tools, Burp Suite. And then, then I moved into other domains like like threat modeling within application security. I did a couple of things and then I moved into GRC, like control risk assessment. And currently, like, I'm doing API security. That's a very interesting topic for me at this moment.

3:09Okay.

3:11Chris RomeoI'm curious, whenever somebody describes the fact that they moved from another engineering discipline into cybersecurity, I'm always, I always ask the same question. And that is, are there any parallels between mechanical engineering and cybersecurity? Are there any connection points? Like, did your mechanical engineering background prepare you in some way that helps you be successful in cybersecurity?

3:38Akansha ShuklaDefinitely, I would say, because in mechanical engineering, I wouldn't say it's just all about engines. It's all about maybe like refrigerators. It's also talk about like thinking if you go into CAD and CAM. So I think MATLAB is all about mechanical engineers, so they develop several things. So from there, it correlates towards the coding, towards real thinking, how it works. Because if you talk about computer science, it's like for a mechanical engineer, it's really hypothetical. Like you can't really see everything, right? So when in mechanical engineering you have done CAD, CAM, CATIA, all these things, they will give you in your back of the head, like how these computers work. So from there it correlates to really computer science or information technology and then towards cybersecurity. So yeah, there is a link, I would say.

4:37Chris RomeoI like how you put that, like computer science is hypothetical. Whereas mechanical, now our computer science people in the world are gonna send us lots of mean comments about that. Like, how dare you? How dare we say that it's a— but I agree, it's hypothetical, right? It's mechanical. You're talking about real-world components that have to be connected.

4:57Akansha ShuklaYeah, exactly.

4:57Chris RomeoAnd they have to, and when you turn on power, it has to work.

5:00Akansha ShuklaIt has to— Exactly, exactly.

5:01Chris RomeoIt has to do something.

5:02Akansha ShuklaExactly. For me, at least being a mechanical engineer, it was really difficult for me to visualize things. And then, When I started my career in computer science, that was the reason I spent 6 months in development, that at least I should learn how it happened, like how the website is being developed. So that was the main reason I started with the .NET and Java and then jumped into cybersecurity. Because, uh, to be honest, if you don't know development, it's really difficult to understand how the logic works. And people are just talking about to secure it. not understanding the logic. So I think that's really a good link. And when I said hypothetical, I know people are going to talk about that, that this is not. But if you talk about mechanical engineer, I think they will definitely say how this code has been worked, like how this has been running a long time back. I would say in engineering, if you ask, definitely this is going to be the answer. Yeah.

6:01Chris RomeoYeah, and I think you took the right path, like, understanding development and code and how all those things fit together is a great foundation for application security.

6:12Yeah.

6:13Chris RomeoThere are still folks out there who are in application security and don't have that foundational knowledge, and then they go ask a developer to do something, and it's like, well, the developer kind of looks at them, a quizzical look, like, do you really understand what you're asking me to do? That's a multiple-month effort that's going to be required to make that thing happen that you want.

6:36Exactly.

6:37Chris RomeoWhereas when you've been in development, you know, you know what the challenges are, you know how to interpret and speak to the developers in a way that they're going to be— everybody can be successful. So, I think that's a powerful strategy. Now, I didn't come to security from development. I came from the system administration side. But then I did some development along the way in building products for my startups and stuff so that I, I got that perspective that you gained as well, which I think is, it's very helpful for, for just coaching people and for encouraging people and trying not to be a difficult security person who's always asking for challenges.

7:14Akansha ShuklaYeah, because you have to be in their shoes at some point of time, either at the starting or maybe within in between your career. So it's like some, at some point of time, you have to develop things to secure it. So I think, I think all these concepts, shift left or security champion, they all around the simple topic that you need to understand first what they are developing or what you are developing, and then only you can come into security.

7:43Chris RomeoYeah. So what got you interested in API security and I'm curious why you think it's one of the least mature pieces of AppSec right now.

7:55Akansha ShuklaI would say it's because of the fact that people think that it's a second-class citizen. Like, they are securing UI or frontend, they are securing backend, but what about APIs? So they are not able to, like, especially developers, they just keep building APIs. Developing one or the other for different functionality. And when we talk about security, again, there is a question mark. So it depends on what they are developing, how they are developing, and then are they securing? Do they know actually how to secure it while developing? So I think for APIs, it's really difficult to make them understand what are the security measures. And definitely this is one of the reasons I picked this topic because many organizations, they are still struggling, or maybe they're just relying on some of the other tools which is there in their pipeline or maybe in the network and just sitting behind and, you know, watching their APIs to be exposed, which are not supposed to be public even. So then also they are exposed, they are exploited. So I think that is the reason why I picked this topic because it is still struggling.

9:09Chris RomeoDavid, have you used the OWASP API Security Top 10 in your travels? Like, what are, what are, what's been your experience with that project and how has that helped you in telling others about API security?

9:28Akansha ShuklaYeah. So I think first of all, the OWASP Top 10, if you see the 2019 and 2023, which was the last one for APIs. You don't see like much change, and the focus is towards broken authentication, broken authorization. So basically from '19 to '23, they divided 4 major vulnerabilities which are all about authorization. So what is exactly the reason? Because these are the basic checks that when developers are developing APIs, they are not able to understand how they have to scope the Like what exactly they need to do from access point of view, how they are going to build the foundation of access control list or these things. So for me, and I would also like to highlight this thing when we are, I don't know who are going to be the audience, but these OWASP Top 10 are not just for security people. To be honest, they are developed for developers.

10:29Really?

10:29Akansha ShuklaUnderstand, if you read that, They have cheat sheet. So every, for every known vulnerability, they do have a cheat sheet which can be easily referred. And it's very like, I received this question a couple of times that we do have OAuth, then why do we need authentication separate mechanism? And it's authorization, like authorization framework. You can't just rely on this for your authentication, right? So these are the questions which are clearly mentioned in the OWASP Top 10, and I really like that, to be honest. It's just the fact they are totally dependent on the bug bounty program and all those things like the findings. So I would recommend all the developers to go through that. At least you will be aware of all the existing ones which are not there in the market. Then it's our luck, basically.

11:24Chris RomeoRight.

11:24Akansha ShuklaAt least these are known. So focus on that and work for that. So I think that is also one thing. And I really like OWASP Top 10 2023 list. But yeah, they removed all these injection and many other like 2 vulnerabilities they removed, which I like. It's just opinion that I don't fully agree to that, that you have to categorize 4 authorization and then completely remove one existing vulnerability. But yeah, it's, it's their call.

11:55Chris RomeoIt made me think of guardrails when you were talking about the authorization challenge. And it's always, it's always something that I guess just makes me think with that standard problem in API, like either authentication or authorization. It seems like if we, if an organization just uses the guardrails concept, and the paved roads concept, and specifically paved roads when it comes to authorization. Like, every API should use the same authorization approach. And even authentic— well, maybe not authentication approach. It could be multiple authentication approaches. But when I think about authorization as the core, like, what are your thoughts on kind of the paved roads concept with authorization? Is that—

12:45Yeah.

12:45Chris RomeoIs that a best practice that people should be trying to implement to try to solve so we don't have one API that has this authorization challenge and all the rest of them are solid, but they created something special over here.

12:57Akansha ShuklaI think it will sort a lot of problems if we can have one standardized solution for all these authorization. And definitely the outside source can help. But yeah, it's again, like a lot of decision-making thing which can play a good role in this. So it's not like something which you can do for all the APIs because depending on the functionality, depending on the usage, how many users are there, et cetera. So it's again, I think this is a good solution, but again, it can come up with other challenges maybe.

13:40Chris RomeoYeah. And I've spent the last 15 years of my career in the startup space. where you have one product, you have one. So things like paved roads are a lot easier to do when you have a single product versus an enterprise where you have thousands of applications.

13:58Yeah.

13:59Chris RomeoAnd there's always something that, that won't work. You create a paved road solution and there's something that won't work because it's legacy and it talks to this weird thing over on the side that nobody really understands what it does. And so, I have to remind myself often that the startup challenges are not the same as the enterprise. The scale of the enterprise problem is a lot bigger. 'Cause my, I always think like, well, just do paved roads, but it's not that easy in the enterprise.

14:25Akansha ShuklaExactly. Exactly. Because depending on the organization, it could have so many third-party components, maybe legacy applications or legacy APIs. So, it's really hard to manage everything altogether in one way. So there are definitely, there could be different ways of managing these things differently.

14:44Yeah.

14:46Chris RomeoSo how about threat modeling? One of my favorite topics, and Robert and I talk about threat modeling, not all the time on the AppSec Podcast, but, you know, people will say almost all the time, we're always bringing it up. So how do you see threat modeling playing in with the world of API and specifically on the logic flaw side?

15:06Akansha ShuklaTo be honest, I also have this as my favorite, one of my favorite topics from application security. I did almost 2-3 years of my career like really drawing the data flow diagrams and everything. But from my experience, if I share with you, developers like take this as a burden. So like just, you know, maybe whiteboard exercise, or it shouldn't be the case that threat modeling is just to create a data flow diagram, read from their existing maybe solution designer architectural flow, and just copy paste. So that shouldn't be the case. You really need to understand all the components in the application, and then you really try to understand what the business logic is there, what the flow is there, how many users are there. So if I say from API side, people don't consider threat modeling at all. So that is like, that is one of the things which I would like to highlight when we are talking about threat modeling, that whenever you are having any APIs in your— I think everywhere there are APIs, right? So when you are doing threat modeling, take consider, like do consider these APIs and their flow, their business logic. So it will help you identifying the threats, the risk, at the time of when you are doing threat modeling, not just, you know, drawing, okay, define some pictures and then you are done. No, just think from API point of view that yes, this is the endpoint, these are the resources you have in that particular endpoint, what are the objects, and then think as an expert or maybe threat, whatever. So it's like then you can identify the threats at that time when you are doing, right? And then you can define the countermeasures. Do you have any network-related checks in place to mitigate these upfront, or do you need some other kind of validation in place? So these are the things which are still missing when we talk about threat modeling and API security. So we really need to correlate these and try to understand what we are missing for API security.

17:26Chris RomeoWhat do you think the reason is why people aren't threat modeling APIs?

17:31Akansha ShuklaAgain, they are more focused towards the, like, because they think APIs are just for, you know, plumbing their maybe frontend to backend relation, or they are just for, you know, connecting to other application or small functionalities. They don't consider it as a— because again, again, I will say that, that when it comes to security, it's more towards the UI and the backend. What about APIs? So that is the main reason. And we never think about APIs when we are doing threat modeling. So that is another challenge because I never saw, to be honest, in any of the session which is about threat modeling and they mentioned API-related threats and countermeasures.

18:22Chris RomeoOkay.

18:23Akansha ShuklaSo what is the reason why we are not mentioning API-related? I can agree, like, they— these are not different risk or threats which are not there in application, but because of the fact that we are missing from API point of view, later we get these BOLA and other threats when your APIs are exposed. So, that is the reason I would say, from my point of view.

18:49Chris RomeoDo you think, is it a knowledge problem? Like, are people that are doing the threat modeling, because like we talked about the API Security Top 10, which I find when I mentioned the web API, web top 10, everybody, almost everybody in the world, even developers and things have heard of the OWASP Top 10. They associate that with the web app. version, the big, the big project. Do you think it's a, is it like a knowledge problem where people that are doing the threat modeling, whether they're developers or security people, they just haven't studied the API Top 10, so they just don't know what those threats are? Is that a potential scenario?

19:33Akansha ShuklaI, I don't think so. It's a knowledge problem. They do understand. That's why they are developing APIs. Like every day, I think thousands APIs are being developed. It's just they are not considering it while doing— so it's basically they have knowledge but they don't prioritize it.

19:53Hmm.

19:54Akansha ShuklaSo it's all again about the prioritization. So when they have like web application OWASP Top 10, which do cover some of the APIs Top 10 as well, like there is a duplication or I would say overlap, but again they don't consider APIs when they are doing threat modeling. So that is, I think, lacking behind. And it's OWASP web application program is overpowering everything. So I think we skip sometimes API-related threats, maybe mobile application-related threats. So these things are still, you know, not that prioritized while doing at least threat modeling.

20:34Chris RomeoSounds like we almost need a sub project, a sub-threat model to consider APIs separate from the bigger architecture, just to force people down that path to take care of those things earlier.

20:48Akansha ShuklaI think that would be really interesting to see if these threat modeling exercise can have subprojects considering all APIs. Maybe again, in that subprojects, they can define what could go wrong, are the business logic from API point of view, and what are the threats identified? So that would be really interesting for me as well to see, like, how threat modeling, particularly for APIs.

21:15Chris RomeoHow about ASPM? This is, you know, so you listed it as API Security Posture Management, but ASPM, like, what do you see as the role of ASPM?

21:33Akansha ShuklaFrom my point of view, it's all about visibility and context. So it helps you that what all APIs you have in your organization, like depending on the classification, specification, functionality, all these will help. So I think if you have these kind of posture management, that will help you identifying all the traffics related to APIs, and then you can just document it, or then you will, you know, view that whatever you have in your organization. Because still many of the, like, if you see on LinkedIn or somewhere, like, we still talk about discovery, we still talk about inventory. So what is, like, lacking behind? Why we are not able to do that? So I think these—

22:25Chris RomeoSo people are still struggling with that in 2025? I figured so. I'm, I'm, I guess I'm not in the loop as much as I used to be because I'm not running a big program or anything. But this is one of those ones that I thought people would've solved by now, cuz it does, it doesn't, it's not a hard technical problem.

22:45Akansha ShuklaIt doesn't sound—

22:46Chris Romeomaybe it is. Maybe I, maybe I'm missing something.

22:48Akansha ShuklaUh, I would, I wouldn't say it's easy task or tough task, or it's, it's all about priority. They have business to flow, and they don't want any kind of blocker in there. And again, when it comes to security and business, it's always business wins.

23:09Chris RomeoYes.

23:11Akansha ShuklaSo I think that is one of the major reasons why we are not having these kinds of checks. And it is really interesting for me and surprising that we are still struggling with all these topics. Like, it's been a decade for me as an experienced security expert, and I learned about APIs or application security in 2015, and still there are several things which are almost the same. So I'm also puzzling around, like, what is the reason? We do have OWASP, we do have known vulnerabilities, We have several tools, we have awareness programs, we have champions in every organization or so, people are talking, but still we are getting so many known exploitation in the market.

24:03Chris RomeoMm-hmm.

24:03Akansha ShuklaSo what exactly happening? Not sure. Maybe it's just every time some of the other fancy words come into market like shift left or some other, And then people just, you know, they try to polish themselves with these words and then try to be, you know, first in this race of these words. But actual security is all about empowering your developers. That's where we are still not 100%, I would say.

24:36Chris RomeoYeah, I think about something like input validation.

24:41Akansha ShuklaYeah.

24:41Chris RomeoWhich it seems that this is something we should have solved by now, because even in my limited development knowledge, the frameworks allow me on the backend and to float through to the frontend to define a particular piece of input and then categorize it by its type, its length, You know, all of those parameters are now part of the framework. But obviously, people aren't using that capability because if they were, we wouldn't have— input validation would be eradicated from application security. It just wouldn't be a thing anymore. Sure, legacy apps would take 25 years to be— to go out of service, and we'd have some challenges there. But like, if you're building a new application today, Why aren't people just using those framework capabilities and never having to worry about input validation because the framework is doing it for them? And even Java, like you mentioned, you were a Java developer. Java's had that forever where you could type a particular piece of input. And I don't know why I'm having an epiphany here. Like, why haven't we solved this in all of these years that are out there? What are your thoughts?

26:00Akansha ShuklaIf, if we solve everything, I think then these programs, these bug bounty, and nobody will identify SQL injection if everything got fixed. So I think we are just making space for them to leverage.

26:13Chris RomeoI mean, that's for you, it's job security. Like, because my goal has always been to put myself out of a job. Like, that should be all of our role in application. Application security professionals exist to have the cancellation of the application security program. Because we've done everything, like we've got everything settled. And I know that's not realistic because new things happen and, you know, AI and LLMs have brought this whole new landscape of things, but we should be focused on the challenging new things, not on the simple, like input validation seems like it, I mean, it seems like it's something that's so simple.

26:53Akansha ShuklaThat's true. It's simple, at least for an experienced person. But again, for just, just think like a developer. If he or she has to develop several things, what is stopping him or her to consider all these input validation which are already there? So there is something which we are missing as a security expert. That's my understanding. I don't know if it is true or not. But developers are so like overburdened or maybe overwhelmed with their own jobs that they are not able to, or they are, they don't want to consider all these security checks. So I am also trying to understand their perspective because these are inbuilt frameworks. What is stopping you to use them? Why you are not able to do it? Like, what is it?

27:43Chris RomeoWe made it too, we must've made it too hard is the only thing, the only conclusion that I can draw. Because coming back around to paved roads, right? If you give, if I'm developing something and you as security are giving me a component that I can use that makes my job easier and lets me do my job faster, which means I'm going to get a bigger bonus and I'm going to get promoted and all those other things. Everybody's taking that. If you give me the solution.

28:12Akansha ShuklaYeah.

28:14Chris RomeoBut like with input validation, where, what have we, we must have missed something. Like, why don't we have a componentized version of input validation that developers can use that's easier than them doing the manual way that they define input fields and trace them through the databases and all that type of stuff? Like, I'm just, it's hitting me like we've missed something. I think it's— But I can't put my finger on it exactly.

28:41Akansha Shuklait's not that simplified for developers. That is my understanding, that it is still a bit complicated for them to use because input validation is such a basic thing, at least for us. Like, you don't, you don't have to do— like, it's not rocket science, right? It's, it's simply, uh, validating whatever you are taking from the user. So I think there is still few things which we need to help developers.

29:09Right.

29:10Akansha ShuklaMaybe through other frameworks which are more simplified, or maybe more awareness, or some other thing. Maybe we can think of this, that what is— maybe you can interview some other developers to understand what they are thinking about input validation, or maybe known vulnerabilities, very basic things. What is stopping them to enforce? What is there? Yeah.

29:39Chris RomeoI need to go on a mission or a journey to solve the, to figure out why haven't we solved this yet. So, the last question that we had prepared, I want to discuss the concept first. And so, you mentioned, you know, how do you, a question that we could discuss, how do you shift security left without slowing development? I want to talk about this shift security left thing first. And I don't know if you saw, but one of the Gartner analysts came out with a, a new paper/research report that says shift left is dead.

30:11Akansha ShuklaYeah, I saw that.

30:13Chris RomeoAnd so what are your thoughts on that general concept? Because I'm still trying to work out my own answer to this question. So we're going to workshop this a little bit and see where we land. But like, what are your— what's— because I know I had an initial reaction to that statement because I don't like the term shift left. I never have. I've made fun of it. a long time, but the concept is solid because, as I've mentioned on the podcast before, the concept of shift security left goes back to Joe Jarzombek at DHS back in the late '90s, the concept of build security in. It's the same idea as shift security left.

30:49Akansha ShuklaYeah.

30:50Chris RomeoSo, but what are your thoughts on that? When Gartner comes out and says shift security left or shift, you know, shift left is dead, like, do you agree, disagree? What are your thoughts on that?

30:59Akansha ShuklaI think depending on what they want to convey, if it is just a cultural thing, I wouldn't say it's a dead thing or it's not logical for me. But if it is like just integrating some of the tools in the pipeline, then definitely that shift left. If we are just talking, okay, you have several tools which you can build, integrate in the pipeline, and you are done. So I think that's where my opinion comes. For me, shift left is all about when you are in an initial phase, scratch, like suppose you are building a house. So when you decided to build a house, you think about security. For me, shift left is that, not like in ages or not like in a timeframe or something, but for me, shift left is just when you start developing or when you start thinking about developing something, you should think about security.

31:56Chris RomeoYeah.

31:57Akansha ShuklaSo that is my, my point of view. But yeah, I also read that Gartner report and I also, I think, read somewhere or saw some podcast where people were saying that shift left or shift right, because we cannot test everything or, you know, security is not 100% in test environment or in other, any other environment. It has to be in production. Because, so, so are we saying that shift left is dev and moving towards shift right or somewhere else? So, so my opinion—

32:31Chris RomeoI used to jokingly, I used to jokingly say we need to shift everywhere. Oh, down, left, right.

32:37Akansha ShuklaThat's actually true. Because you, you can't just say shift left is moving security shift, like moving a shift towards left or right or up and down. It's all about mindset. It's all about awareness. So whenever you start thinking for security and calling it shift left, I'm fine with that. But if it is something else, then yeah, I have opinions on that.

33:04Chris RomeoYeah, I'm gonna keep digging into this issue over the next number of months to try to uncover it and see. But I'm curious, Akansha, what, key takeaway or call to action would you leave with our audience here? What type of homework would you give them?

33:20Akansha ShuklaI would say and recommend everyone, especially developers, especially architects or engineers who are like developing anything, think about security. So if you are writing a piece of code, irrespective of whatever it is, if you are designing anything as an architect, whatever it is, any application, endpoint, resource, object, whatever it is, even coding or maybe integrating as an integrator, just building pipeline or something, think about security. Even if you are just not into IT, you are living in a house, think about security because you can't just leave your gate like that, right? You have your logs, You have now we have smart like pin and everything. So just just trying to up try to upgrade yourself, and I think and definitely one one piece of advice which I would like to highlight, which I take for myself: AI is not everything. So just just don't go behind all these market strategies that AI is going to do this that definitely use it. leverage it as much as you can, but it's not everything that you just rely on it, sit on it, and then just think everything will be done by it. No, no, it's just a source. It's just a new intern in the market. So yeah, leverage it.

34:55Chris RomeoThat's good advice. So Akansha, thank you for sharing your practitioner perspective here. I love when we get a chance to speak with practitioners who are actually doing application security in the real world. Versus folks that, that perhaps are, are more kind of strategically looking at this from product perspective or something, trying to sell something. Like, I love talking to people like you because you're in the, you're in the, you're in it, you're dealing with it on a day-to-day basis. And so it's been great to just, just hear your perspectives on API and look forward to a future conversation where we'll talk about something else related to application security.

35:30Akansha ShuklaFor sure.

35:30Chris RomeoThank you for, thank you for being a part of the show.

35:32Akansha ShuklaThank you so much for having me.