BSides Buffalo 2026: Secrets That Survive Everything: Finding Runtime Credentials in Web Apps

secrets that's survival thing. So this type is from uh two production exploitation chains that we found for scanning and applications and we found a couple of uh explorations that reported by bubble researchers. So this talk is about exploration chains and how to find credentials in runtime production applications. So I'm ga global pentest lead working in one of the funded organizations. So I kind of penetration tests and a new enterprise bond programs and I built a secret system. It's a tool to scan live applications traffic and find cores because the patterns in this talk kept recurring all. So last year we see two bug bounty submissions. The first submission came in and the reporter entered credentials

in JavaScript bundles and he flagged exporter he stopped there and he did not proceed there. So a few months later we received another sub and this time the reporter again flagged the same pattern in the same JavaScript bundle on an entirely different application and he did not investigate it further. So two submissions we recorded over the last year course is we found credentials in JavaScript JavaScript bundles nobody asked the question actually what actually these credentials belong so we started so I started reading JavaScript bundle not to read it as just looking for just to map it to understand how to map that as the application how it's designing the application how it functions so with the four with the four

uh values that I found I call the a token endpoint and you come to the system or reach mode just from the four. So you're going to see um you know exploitation one and exploitation two. So exploitation one. So the azure age what for values if you find in the javascript portal what can you actually do with that? So you're going to see references to the uh portal. It's a dummy intentionally built purposely built wonderful application just for the live demo. So if you see come across it's just live nothing anything that you see the credentials the data is completely state you know it's fake. So um so this is a main js file that's get shipped to every

user of the application. So when you open an application so you have to you can use view the view source with that's where you can see the javascript files. So uh you know this is the main main file and you can start reading the file and you see four Azure values the Azure AD configuration values. So what actually this values are so the tenant ID is the public identifier which you would find uh you know in the login direction that uh you know within the connects to to the AD app ID is a public identifier. So which is available you know which is a resource identifier uh just in you know it's not right like a

real secret if exposed to you know on the on the JavaScript files or anywhere you see it on the uh you know any place but the next one app key that's a secret so that secret should never be exposed to front end sources if you see that anywhere like an app key on the front end JavaScript file or any API configuration you see that that's That's where so where the tree right so that should live in the back end but with the four values that you were seeing here app ID app key resource and subscription key so what is the resource key so resource is like you know the identifier that tells what access tok

what access it has the token has access to so it tells aure that hey I want access to this specific resource or any API so subscription subscription key look you know more like a key path to pass through Azure API management gateway. So Azure uh you know API management gateway validates the subscription key before it has to pass down that request back to the back end API for validation. So for API management gateway to you know pass down the request. So it validates the uh an active access token and also subscription token. So with all these four values what can you actually do? Anyone anyone can actually do. So let's see that. So this is the Azure APM

architecture. So how exploation chain one has done. So the the browser holds the JavaSc ID, app key, resource and subscription key. That's all anyone uh that's all anyone can you know they need. Um so what I did I started reading the JavaScript bundle. I started calling the I started uh I craft a request to call the Azure AD token endpoint and with the app id. So once once an Azure AD receives the specific request so it validates whether the app key or rail right it validates it and then it pass it generates an access token once it uh you know once the credentials are successful. So it generate an access token and then I call the backend API.

The backend API is called now the backend API I call for that specific service is to get the user information on the entire tenant. Right? So I I put together the subscription key and then the access token. I sent back that request to backend API. AVIM validated subscription key and the access token and then every account in the system was written in the response. How was that possible? Because the access token that was generated it's not a user token. It's a service principle token. So what's a service principle token? Service principle token is the app you know it had high power permissions within the entire Azure Azure directory. So it has the user impersonation level. No sign in access

is required. So with that access token and with the subscription key and all the four values that's available in the JavaScript file, we call the back end API and every content system. So was authentication was working correctly as a design? Yes. Except that the service has to be calling from the back end. It's a service to service call. It's a server to server service call except that I call this token and point from the front end because API we have all the details and the API is still there you call the back. So this is a standard documented oath to request where you anyone having those four values can use it and plug in those

values and they will be able to get uh generating access to it. So let's see this on a application now. So this is the portle that's built for live demo app. So it's all sed. So it's insecure shield port, right? So it's all with the starts with the view source. You can see the main.js file and the app.js file. The important thing for any pentester is to read this through the main.js file to see what information it gives back. So just not like just like I mentioned before just not like looking for secrets or known details just read it as a map to understand what actually the application is giving you back how it was built right so this is

the uh AP uh APM configuration that we have just seen in so it has all the details so that's the AO 80 configuration subscription key and um I put into office. So that's the age configuration that so I took all these four values and then crafted a purp. So I pasted in all these four values and then generated an access token. So and then I got the access token. I have the subscription key and where to find the backend APIs and luckily it's the bad practice of developers writing the API configurations as well exposing on the you know on the APIs sorry on the JavaScript bundles itself. So I read carefully the JavaScript file again on

the different JavaScript file. Now you can see what actually it can do like you know it has all the users all the u different API profiles and document within the JavaScript. So I call one specific interesting endpoint where it's called API/ users.

I sent the request to the back end. So age over 80 validates these two values in here and then immediately it returns backs all the all the data that living at that time.

So it has over like 49 4,999 records or so every account in the system you can see like you know it has this password hash and solve that's written the response. So I'm going to use this. So once I have this information

I put together a decryption key just for the time being just to save uh some time. So I use the decryption key uh just in here and I crack the password and use that password to log into that particular account.

there. So every account in the system was reachable. So it returned almost an entire all the all the details including inside the tag like I said. So this was because purely because the access token generated it has the super high level permissions that has the you know that has the super impersonation permissions level permissions. So that's exploitation chain one and the next exploitation chain is pretty much the uh cryptojs chain. So this actually is kind of creates a false sense of security because developers some developers thought that you know uh you know documenting the secrets inside the JavaScript bundle itself they think it's a problem. So they have read almost you know articles blog posts and pretty much

everything. So they realize okay I don't need to do that because it becomes riskier one day right. So what they thought was they can they try to encrypt the entire configuration object using cryptojs encryption and what they created is like you know a cryptojs cipher text blob storage that's sitting just inside the javascript bundle. Now if the browser has to understand that browser can't understand it because it requires keys and it has to send to the back end backend server itself. Now back end has to decrypt decrypt this entire configuration. So where does the actual key live? >> If the browser has to decrypt it, the key has to live in the browser. So how

is it secure, right? So it offers zero protection there. So there are three options by which the keys has can be fetched by a browser is because you know the one just like I mentioned it has to uh the key has to live inside the the JavaScript bundle itself or the key has to be fetched from an independent API configuration or the key has to be fetched from one of the API encryption calls the app has to make. So these are the only possible ways that the browser can do and this is not safe because this is happening on the front end before authentication and any anybody can really uh capture the traffic and really see the data inside.

So this is exactly what it looks like. So the cryptoj no cryptojs encryption uh blog storage and the configuration sorry the decryption key just sitting three lines just below it and the function that joins both the keys so that the browser can use to decrypt it. So I'm going to go back again to uh demo portal. So that's the uh cryptojs encrypted block storage and then the decryption key and then the function that joins them in the browser so that the browser can decrypt and understand it and construct the query to send it to the packet. Now since we since I have all the details so I just use the decryption key uh put together the uh you know a script

so that I can immediately reverse it and all four accounts are still reasonable. you know, I was able to retrieve the four, you know, all the Azure AD configuration back in response. So, I didn't stop there. So, I have the credentials. Now, that's what a pentest or a bomb or anybody an attacker can do. They won't they're not stopping it. Since they have it, they're going to look for more details like to know to do, you know, more exploration of what they can find, right? So I crafted I used these details and again I wrote the JavaScript JavaScript file again and uh got a generated token and that token I used it back to the um internal

configuration that generated the um database connections and corrections. Oops. There we go. So both exploitation chains. So especially this one is really uh you know it creates a false sense of security because all secret scanners that are reject based patterns they scan all the you know JavaScript bundles API configurations or APIs headers and lazy loader chunks and everything. This one gets skipped through because >> it's encrypted >> based on the based on the configuration they're encrypting. you are looking at like a big chunk of encrypted blob storage the reax you can create a specific reax for that specific pattern itself so that creates a false sense of security of you know and most security tools miss this

so those are the two exploitation chains and then um so this is the decrypted dump that we have just seen and the important thing both applications had shift So the source code repository scanned by every single shift scanner they had the organization has. They had git leaks on every commit request and they had SAS C SAS scanning on every pull request but the credentials all the credentials that we have seen they went live all scanners give a pass how right so this is you know that's what we're going to look at in next slide so they have git leaks in CI/CD pipeline the the source code repositories scan for both entire three applications Gitly said okay we're good to go and

then SAS scan happened and then gave a check mark everything is good and you know GitHub secret scanning it runs an active pattern matching across the entire uh you know based on the based on the uh patterns it scans all the repositories. It had all these shift left scannings in place but that credential still went long. Nobody could explain it at the time and we figured that out later. So where actually the gap would lie right? So if we if you take the current look at the stack we have pre-eployment scans and post deployment scans. So for the pre-eployment scans industry has heavily you know heavily invested into the pre- shift you know shift left

scanning. So we have git leak SAS solar cube uh you know and other you know GitHub advanced secret scanning and they all scan the source code. So it scans what you commit. They don't scan what the application source. So if any secret is getting you if any secret is committed by developer into one of the source code this uh you know this scanning works just like engine and it flags it. So it stops the build right. So all the pre-eployment scans works exactly as intended as it will as it's designed but once the uh once the pipeline has started right once the sift shift left scanning has completed the build pipeline runs. So what happens

shiftlift scanning completed it gives a green check and then pipeline runs it creates a bundle artifact. So what's an artifact? artifact is just a JavaScript file. You have just C for conf for the application to function, right? So the build pipeline runs it uh you know it creates the J it creates the artifact bundle and then merges the bundle with the secrets. It makes the secrets into the bundle and then applies that to the production artifact. So once it is done once it's deployed what we have today in this scanning is pretty much like you know vulnerability scanners. They look for injections, crosset scripting, errors misconfigurations everything. They're not pre-esigned and built for specifically for SQL scanning.

So the gap is between the pre-eployment and post deployment. Exactly the merge panel. So if you take a look at this like you know developer writes the code comes to the git repository history and then CIC's pipeline scan checks in. So that's the last stage where it have gets the automated scan cards just like we just talked about right. So once shift left scanning completes the pipeline begins the artifact is produced credentials are baked into the bundle and then the bundle is served. There is no coverage on that specific build between the build and deployment. That's the gap. That's the gap that we have today. So what are the five structure? So we have come across and we have you know I

read some more pieces articles and uh you know this is what it comes down to that five structural paths by which credentials are baked into production JavaScript bundles today or even configurations. So buildtime and management injection CI/CD pipeline variable substitutions and lazy loaded chunks SSR stage utilization and runtime configurations. So what are actually these? So these are exactly the uh inner configurations that happen once after a shift of scanning completes and exists. These are the five possible ways by which credentials reach JavaScript bundles to the production applications. So build time environment injection is pretty much like you know um a developer writes an environment variable starts a secret in environment variable environment file sorry and that

environment file he commits it to the repository the c the github the github or the github you know the shift scanners will catch it and they will flag but what happens how the credentials is getting bundled is because you are committing so the developer writes that uh developer writes that uh stores the secret inside a g sorry stores the secret in an environment file at build time the webpack defined plug-in will read the environment file and pre-bakes the uh real values using the combined javascript that's how the credentials are baked and that's how they're getting delivered in uh you know production applications so these are all the five possible paths So in seven stages how you know um how

uh how how a secret gets escaped by passing all the scanning layer and gets delivered to uh you know the final production application right just take an example developer writes a secret into the g environment sorry developer writes a secret in the environment file if the environment file gets connected to the source code repository we have all the shift left scanning shift left scanning will capture that. So the build pipeline is blocked. So what they do they get to ignore the environment file and then once they uh you know they commit the placeholders to the GitHub repositories. So once the placeholders come into Git repository all the shift left scanners will look inspect every single line of the code and they will

see the placeholder token. They do not see the real uh real credentials because credentials were not really connected to the source. They're just the placeholder check comes inside. Every scanner once the you know once every scanner gives a clear check the pipeline runs. So once the pipeline runs the artifact is bundled the pipeline builds the bundle and then bakes the secret into the um you know in this uh stage four. That's where the secrets get baked into because that's where the define plug-in will call the environment file and uh you know baits the credential into that particular artifact and directly dumps that into the uh production application. So secret went from stage one to stage

seven escaping bypassing every single step. So if you take a look at this like you know two different uh two different paths. So the one path we have just seen is um if the environment file gets committed or if the one of the configuration files get committed to get repository. So the shift scanning will be captured and it blocks the build. So these are the five structural paths that we have just seen. So these will not be captured and they won't be so they won't be captured by secret scanners because it doesn't have an automatic coverage today. So looking at the landscape so industry has like you know invested so much in the shift scanning glycardian

sonar they all well deserve a spot in there on the right side once the credential escapes and gets you know gets lived in the production application that it's getting served so there is no scanner today that can really flag that particular kind of credential. So the runtime the runtime gap sorry the runtime security gap on the right side the shift right side is almost nearly empty because there's no specific tool that's going to do that. So if we take a look example of how you know we put together all the tools that we have. So we have repository scanners, we have shift rate scanners and truffle truffle hog has its own place own layer of like you know identifying the

credentials and it does live verification of credentials if it come across right and the other the others are like you know active crawlers and the others um there are new plays which run based on the template they have they have like you know huge huge number of uh templates and they have like almost 50 to 60 secret scan products inside as well. But they do not find all you know all all the API configurations. They do not scan the headers. They do not scan the specific uh you know JavaScript bundles lazy loaded chunks and the secrets in the HTML resources as well. They all going to they're solving a different problem. They specifically designed for something but not for

secret scan. So we burp has burpuite has more plugins and some of the plugins it has it also you know JS minor sensitive discover truffle hub extensions they they do have some sort of rejax based scanning they will find subsequent but no no scanner is going to find you 100% of your credentials if it's exposed so what actually runtime secret scanner should have so it should see all the four values. It should see it should have all these four values. It should see what the attacker is supposed to so it should see what the attacker is seeing. It should observe the traffic. It should capture all the XML content types, JSON content types, lazy loaded chunks and SSR states

and pretty much the encrypted block storage. And um once a secret scanner starts it uh starts scanning the JavaScript window or a production application itself right we know that the front end application is completely of user interface they're intentionally putting public client IDs to find across all the JavaScript files right so without all these four values together your scanner will either fire too many false positives or it will miss completely what the scanner is serve or sorry what the application is serving. So two external researchers have you know two independent studies show that the internet scale has not been scanned for secrets right you know this all happened in the last six months these are the only two articles that I can uh

find in the internet so far today because shift shift right secret scanning is something new nobody knew the concept nobody believes that you know uh secrets really get connected to runtime you know living in the parks and applications so intro.io IO they conducted uh you know they conducted uh they scanned about like 5 million application uh patients they found 42,000 and Nurola he's a Stanford University professor so he published a paper on March 2026 they scanned 10,000 million pages sorry 10 million pages and they found 1748 tokens live tokens so 84% of them living in JavaScript bundles Right. So this shows that you know this shows that the industry scale industry has sorry the all the internet scale is

not scanned. This proves that you know all the credentials they reported the flag credentials to the appropriate uh organizations respectfully and they have some of them have most of them have the findings they have captured. So attackers always all you know they always see the front end of your application. They will not see your source code. They will not see they will not have access to your source code. So all they will see is just the front end of your applications. So they already know this. If you want to scan if you want to start scanning your entire organization today for secrets, there is no answer to because the current day dash scanners we have they're not

equipped with secret scan caps. They do not have that. So the runtime layer is the only layer the attacker always sees. That's where they start. That's where they always look on 4x7. They look at your applications. They see what you know they will find every single they they will read every single line of your JavaScript code. They will find credentials. They will find APIs. And once they find the explanations that the change that we have seen, that's the result. So we're going to see this in a live uh demo portal application. now. >> Um, so this is the tool that I built.

Get the target.

So what it's going to do, right? So it will load the application in a uh you know in a chromium browser and it will start inspecting all the traffic. So it's going to it's going to fire up the application in the Chrome browser. It's going to inspect your traffic for JavaScript files. It will capture the API configurations and it will find every single credential. It's going to inspect every single line of code and it'll just find the credentials that's living in your API configurations or the uh you know dows components. So I plugged in like four other tools just for comparison so that we can see it. So Titus is one of the recent most

security sc open source security scanners. So it finds a few vulnerabilities. is not going to find everything because it's missing it's missing you know secrets in the headers it's missing secrets in the configurations it's missing secrets in some of the regist patterns that it doesn't have so we have truffle hog as here so truffle hog also does the live inspection so it's going to look for the secrets it found so that's the so far credentials it has

So there's another um bird plugin it has. So it will find a few part. So this is not like you know this is not a complete project based patterns. It will find sensitive information like you know uh IP addresses or um you know email addresses that's living in the that's living within the application uh JavaScript file also. So there is no one single application tool you know uh the tool today that's going to scan for your credentials just like the shift left secret scanner does because they are purposeuilt and no purposeuilt today we have to scan specific your specific your uh specific assets for your enterprise organizations. So, what's the radiation?

I got to make it work.

So that's the total overall numbers that we you know within the uh scanner plugins that we put together using the burp script uh extensions. So that's the comparison model of how it looks like. So what's the remediation for it? So the first two back end for front end secret managers saving your secrets in the actual key world and then artifact scanning and the runtime secret scanning that's the solution why because back end for front end and secrets manager number one and number two are going to remove your uh those two are going to remove the credentials documenting in the front end itself. Why? Because secret manager saving your secrets in the secrets manager and have the application call

the back end you know BFF back end for front end server and at runtime what it does is at runtime application makes a call with the cookie it's not going to use credentials anymore because with that's how the BFF works so your credentials will leave on the server end on secret key wall and then um the application makes a called to the back end and the back end uses the credentials get fetches the credentials runtime from the secret manager and sends to the back end API to generate an access token then send it to the front end user so there is no more secrets exposing you know there's no more of maintaining secrets or getting secrets

bundled into the uh you know on front end so if you compare the model so before and after so before the JavaScript files the bundle sorry the secrets are within the JavaScript files here and after the secrets are maintained at the key store and then the you know when the browser makes a call it makes a call to the backend API with the cookie the cookie is only the 16 you know client identifier that's going to send it to the backend user sorry the backend uh server and the back end is going to make a call at runtime to fetch that credential and send it back to the backend API generates an access to it

and sends it back to the front end. So there is no way of like you know um exposing secrets throughout this traffic between the client and server communication. So what else can we do right auto artifact scan this is where you know this is very underrated and most security teams do not know this why because the scan at the front you know the source source for scanning that's where it you know every security team will look into hey my code is scanned it's cleared that's what they're going to look into and see so once the artifacts are bundled and then the artifact is you know that's where the artifact scanning layer has to be merged

and github GitHub advanced secret scanning. They also have this capability of doing artifact scanning, right? So artifact scanning is the piece where it can find all the it can scan for the artifacts you know that's getting getting bundled with the secrets. So runtime secret scanning has to happen 24 by7 because nobody knows like you know if I'm a developer if I have an application I'm making changes I run like you know I run the deployments 24 times a day. So something may go wrong all the time. So pentesters and application security teams, vulnerability management teams, they do this scanning all the time. They have to scan this all the time. So three layers of scanning. Source code scanning,

artifact scanning and runtime secret scanning that will solve the problem of identifying credentials. Sorry. Yeah. Identifying credentials and you know getting those secrets uh you know fixed by the teams. So what's this for the application pesters and bug hunters, right? If they find a credential, do not stop at the credential. See what permissions it has, what it can be, you know, what it can give you access. Do you have like user access? Do you have like service principle access? And what can you further do? And important responsible disclosure. If you find secrets, if you find credentials, if you find any specific information, responsible disclosure only can go to that property team because when the you

know when you when the credentials are getting discovered or published to the uh you know on the live applications today only three things are captured. One testers, two by researchers and three hackers. Two of them report one. So, so this is the secret system tool that I built. It's completely open source if you want it. So, you can just load it to the application. So, um it can scan up to 30 URLs or 50 URLs based on your uh machine size machine you know hardware complexity it has. So, it ships in different forms. So it ships in Burp Street extension. It ships in browser extensions like Chrome and Firefox and it ships in desktop applications both

Mac and OS. I'm still working on the MCP edition. It was halfway there. So you load targets into the target URL and scan the applications with it's going to find based on all the rejects it cast and it has more capabilities of how you can load custom custom reex reax patterns so that you can find uh you know a custom uh credential that you're specifically looking for. Question time. It's >> not a question, but I'm I'm pretty shocked that modern day dash scanners can't find these secrets hiding. >> Yeah. >> It's it's because like you know they ever since from the beginning they heavily invested into finding vulnerabilities. >> Yeah. They are like you know you find

injections, SQL injections, you find processes, they will find missing hackers, they will look for secret and they will look for sorry session. The shift will never look for they're not designed. So there is a you know there are a couple of um companies that now make this as a profit. We know that. So um there are more and more runtime secret scan tools that's going to come up in the future because the industry is looking at at it right now and more uh you know runtime exploitations that we're seeing is based on credentials. >> Go ahead. >> Oh yeah I I think I got a little confused. So, are you saying that the the shift left scanners that are

scanning for vulnerabilities, they're not looking to see if there's credentials in like the front end files or is it like um you're putting it in the environment variables and then you're also and then like well I'm asking if it's the latter where it's like they are standard credentials but they're not finding credentials because you put them in the environment variables and somehow the environment variables is leaking is the bundle and the artifact. >> So is it both? >> No, it's it's the first one where like you know they scan what you commit. You are not committing your environment variable environment files to source code. >> Yeah, it's the developer two step. >> Okay. >> So that that's what happens if you

commit the so if you commit the environment file secret scanning tools just like you know the shift scanning tools they will find the building is blocked. >> Yeah. Okay. So there there is a different you know there are different ways like I said like you know five different mechanisms they will there are environment files they kind of get get ignored but the frameworks that they use react angular you know they are like you know white blue they are all the frameworks they have specific documentation of how they're calling the prefixes they have a prefix like you know react app that means that's naming the convention and the build pip begins the plug-in automatically calls it. It understands that hey it's a react

app that means this variable has to live in the browser front end. >> Yeah. So then that's when the bundling happens. >> Yes. So it all exactly >> it happens once after every scanning completes exits the pipeline that's when the artifact gets bundled. >> So there is no scan happening between the build and the deploy. So that's the scandal sort of the gap that's how the credentials are you know baked into artifacts or configuration files and getting delivered to production applications and and it seems like part of part of another part of the problem is culture the security team should be reviewing the API's permissions to be least permissive as well as looking at the

main js to make sure that these don't exist in that front end which would be artifact scanning but on the manual side right? >> Yeah, this is that that Wow. Okay, now I'm scared. Thank you. Great great pres. Yeah. >> Is this similar to how claw codes uh source source code got leaked through a npm package which didn't go detected through the C3 >> maybe somehow but may not entirely be just because of this you know um thread thread actors doing source code exploitation though will stuff credentials in environment variable files and release them. So you can if I can inject something through your npm layer, I can have that code execute at build time, take secrets out

of your environment and dump them into the environment variables and then get compiled in real time hidden in your website as a way of exfiltrating secrets and tokens. It's pretty sophisticated. You're not going to see that as a normal attack pattern, but it's something that they can do. That environment variable file is miserable. >> Yeah. >> So it's enment files, configuration files. Yeah. >> Anything that you do get ignored. That's how because that's the documented layer. >> Yeah. >> That's how the document says like you know you get ignore these files. >> Yeah. I've seen I've seen people intentionally concatenate in var environment variable files to create a secret that they've used to embed in

there because it would bypass the scanners like it. Yeah. It's like are you my threat actor? Yeah. So once I have found these credentials, I was working with a couple of developers as well to understand what exactly happened. >> Yeah. >> So they have they all give different reasons because it's one of all these reasons. So there are scanners that we see more almost all the time >> scanners will find it and they'll say uh it's a test token. >> So >> yeah. Yeah. >> Yeah. the the what was that B was it called >> back for front end >> is basically you're basically creating an API layer between the client side and the server side and it's all just cookie

it's cookie session and then the back end the the truth security token remains server side >> yeah everything is happening the scanning the fetching of the credentials and generating of the token is completely happening on the back end so front end users can never see

And I've been working on a paper uh research paper based on all of this. Um so you can find that in Zando. It's all about like how this is happening at SC. >> Yeah, this is really good.

Did you mention that like using something like Azure key vault could be used and then the front end just calls that and then it gets the secret in place. Is that a >> relevant uh fix for this all? >> So there are a couple of fixes right? So >> back end for front end and then your key wall >> that's one layer of like you know how you can store secrets and fetch your secrets on the run time. >> Mhm. And the other layer is like you know scanning your artifacts and 24 by7 scanning your production applications if somehow something gets tipped. >> Yeah. I just know like I'm going to go to an app team if I find someone who

says like oh we don't want to spin up an API server to handle all this. So having that key vault option yes >> is definitely something that they can work with and they're familiar with. So >> exactly. Is this somewhere like giving application role based access using something like that like I guess Lambda can do it and some of the AWS serverless I can give the I can give the application either the lambda function or the container access to those specific secrets make those calls and then the back end >> backend front end. Yeah. >> Yes. Exactly. That's how it should be done. >> Yeah. And then it's credentialless. Yeah. 100%. >> Yeah. And the reason all these

explanations happened for this for the first one is pretty much because >> the service principles keys were exposed completely. >> So that got elevated access to the you know to me when I was doing it and I was able to read every account in the system in the entire tenant. >> So when we worked with the specific provider they said they couldn't find a way to see what and who uses those keys. So that's a gap as well because if you're an enterprise company, global company and somehow your applications are exposing that >> well that that that's actually an interesting point too. what does your IDS IPS see when they see that you know um

>> yeah those calls should have an origin and that backend front end should just reject anything that isn't coming through there and then the gateway like your Azure environment should just say no I only trust the back the BFF >> because everything you expose now it's it looks like your application your any thread actor that's you know working on that using that keys it will look like >> it's an application >> yeah Yeah, they will not find what specific. >> Yeah. And that's what that session that's what that session ID is supposed to there right is supposed to that last step of >> Okay. >> Wow. >> Because when we met like I said when we

met with the provider they said there is no way you can distinguish like who is logging in, who is accessing and who is authenticating your system. >> This has to be way deeper than I mean even those numbers that you posted. This has to be way deeper than that just in the developers I've worked with. Yeah. >> Yeah. And it's not their some of it is not their fault. They just don't know a better pattern. >> It's not their fault. It's >> knowing and you know how the frameworks are getting how the frameworks are working because developers you know they see the documentation of git work. >> Yeah. >> And they see how the documentation of

react applications work or your white out applications work. They do not understand when you combine both together what the problem is going to create. the radial black radius one. >> Yeah. Yeah. The impact the impact side of that is huge. >> Exactly. >> Yeah. >> Any other questions? >> Thank you. Awesome.