I'm A Machine, And You Should Trust Me: The Future Of Non-Human Identity

that I say those slides are there >> mostly. >> No, there's your honestly if you trust if you trust that that tiny world will actually take you to these slides. >> Really? >> That's that's way less than I expected cuz who Okay, who who trusts that my name's actually Dwayne? >> Okay, that's a that's a fair fair amount of trust. >> Yeah. Well, you don't know me yet. So, that's a weird thing to trust me on. The fact that you don't trust Tiny URL, which you can preview at the tiny URL website, but you trust me is weird. Uh, cool. So, I'm going to volunteer. Somebody just raise your hand. You can do it from where you're sitting. Hey.

Hey, volunteer. There you go. That sure. So, ring ring. Pick up your phone. >> Hello. This is the Microsoft customer service center and we need to get into your Windows machine. Can you install remote desktop for us? >> All right. We all got a good laugh. Why is that? Why is that fundamentally untrustworthy? >> Yeah, that is >> corporation cares about you enough to call you. >> Yeah, that Well, that's the same joke. Uh Microsoft doesn't care enough about you to call you. Um but all right, that's how we treat humans. We have really good [ __ ] detectors as humans. We really do. We've developed them over thousands of years of being humans. something don't smell right. The

word phony comes from the fact that when telephones came around, there were enough scam artists to pick up the phone and be like, "Hey, I'm so and so. Give me some money." And people gave enough money that that became a term called phony. What if they said, "Hey, I have this password you gave me and that I have this here's a code now. Trust me." How many people would trust? Like I gave someone a code a long time ago and they you came up called up and used the same code word say oh I I I don't know you but I trust you blindly with that code word. Anybody anybody get give them the money then?

All right. That's how we treat machines. It's like here's a long lived password we built for this API call two years ago and I don't know who's calling me. All I know is you got that password. Here's the database. Humans are not machines. The whole rest of this talk, I'm going to harp on this and non-human identities because this is important because in 2022, this was the data that cyber arc put out like their research said about 45 to one machine identities to human identities. And again, machine identities generally have these long-term long passwords that anything can use, any body, anything can use to get that data in most traditional setups. Right now the estimate is closer

to 100 to one. That's what 100 to1 looks like. But guess what? It's 2025. We live in the world of agentic AI. Who knows the difference between an AI agent and aentic AI? Anybody? Anybody? I just learned this myself. I was at Denniverse a few weeks ago. I in Vegas uh an agent is a single unit of AI worker that does a thing. It's a box that says here's the thing. Give me the thing back. Agentic is the string together the orchestration of AI agents to do a complex thing like build me an attack chain using OSENT to get into this bank. I saw the proof of concept of that a few months ago at RSA and it blew

my mind. It's like this took me 20 minutes and he simulated months of work from one of the malware groups. This is the world I think we're going to live in very soon. I don't know how many's up there. I never counted. I just thought it looked cool. But that's the truth. We're going to this world and if we keep doing the old way of authentic authentication and authorization, we're doomed. I'm Dwayne. I came down here from Chicago. Never been to San Antonio. Love it here. I saw the Alamo yesterday. Went to a punk rock show last night. You got a really cool punk scene here. Um uh I have a repo podcast, the security

podcast called the security repo podcast. Who doesn't have a podcast now? I used to be the co-host. Now I'm just the host. Uh find me on Mastedon and LinkedIn. LinkedIn probably the most professional. Uh, but I crossost everything to Blue Sky as well. Enough about me. I work for a company called GitG Guardian. They'll come up a few times, so I'll talk about them at the very end, maybe a little bit. Uh, Cyber Arc is one of my favorite companies. It sounds like I work for Cyber Arc because a lot of my stats come from them and they're an awesome company. But 93% of organizations in the last two years, this is from last year, so three years.

Uh, 93% said it had an attack. It's 86% according to Sofos and DBIR. It's like about 86% of attacks are in some way involve an identity based attack. What is an identity based attack? Well, there's basically somebody acts on behalf of an entity and does things that that entity is allowed to do but not supposed to do. Is privileged to do but not supposed to do. Here's a great example. Uh this is a great identity based attack that happened in March, I'm sorry, May, uh from people that paid money for this theme in WordPress. I used to be a WordPress developer and a Drupal developer and I hate WordPress. uh on the record um because of things

like this. People bought this theme thing that was safe and anyone could just just reset the passwords if they knew the proper like string to call including the admin passwords. So guess what? Your WordPress site that's running your business, someone's going to assume the identity of an admin and then use it for whatever malicious service they want. On the non-human side of things, these are big things that have happened recently, right? And I could you could go through and look for identity based attacks, credential based attacks, initial vector attacks, anything that involved a credential. And you're going to see stuff like this all the time. These are just two I picked because we wrote a blog post about it at my

company. Humans and nonhumans are very different. Humans pretty straightforward to define and we heard that great presentation uh from the last speaker on if you were here for that room in this room. Uh people have passwords too and it's not I'm not downplaying that but that's not the scale of the problem we're talking about pass keys phto we have some awesome solutions coming out in the development retina scanners fingerprints that unlock extremely long pass keys that get rotated upon every use. These are things that are happening right now and it's awesome for non-humans though non a lot harder to define because how many people are have even heard even heard the phrase commonly used non-human

identity anybody? Yeah. Yeah. Yeah. It's proven a negative. I am been exploring this stuff in the IM space and security space for about a year now and I'm decided it's a dumb term. I am or uh IM is a great term. No. Uh non-human identity is the not human. There's only two kinds of things in the whole world. A potato and not a potato. That's not really helpful for a categorization taxonomy. Versus the IETF, the internet uh internet engineering task force. you know, the people that write ICP, TP, uh, you know, HTML, HTTP, those standards. This is a standard they're working on right now called Whimsy. I'll talk about more about it later, but this is their

actual actual definition. I don't think anyone in the world can disagree with. If you do, please get in their mailing list and disagree with them on this because they're on revision four. Revision five is coming out very soon of this, which again I'll talk about later, but to run a piece of software that does a thing that's pretty straightforward to explain. This phone is a non-human, but this phone runs applications and you're not attacking the actual piece of hardware. I hope not. Please don't take them hurt my phone, but you're going to attack the things on it and what it's those things are connected to. OAS says this uh they hardened it down to this,

which again, I don't like the term, but that's what we said. They followed Gartner uh because Gartner was following a bunch of companies I'll talk about later. And this is what they ended up with. It's well, I won't read the whole thing to you. production software environments got things they're non identities very importantly in the OASP definition they specifically say they're associated with secret that is the core of the rest of my talk is what do we do about this these longived things that we give now they don't need to be longived if you are always issuing brand new jots JWTs with very short expiry times or X509s that like live for 24 hours and expire

and everybody's happy. Good job. You've done it well. You've done it right. The future's looking good for you. If you haven't you've heard of anything I just said and you're still using API keys both like that and you're seeing code that people like look like that. I speak to a lot of different type of of of conference. So I pardon me for assuming you're all developers and assuming you all work in security and assuming you're all I am experts. Uh but I talk to all of these people all the time at DevOps conferences, developer conferences. I spoke at Dev Nexus this year, the oldest Java conference in the world and love it. It was just great uh PHP tech. Um so

when I say you're using this, I don't mean you personally are going out and making these systems, but the systems you're securing. That's what I'm talking about. If the systems you're working on, I always have to make that clarification. If the systems you're working on are still just chalk full of these things that aren't time bound that aren't have an automatic rotation policy. That's the rest of this talk is getting into. So what I want to do for the rest of this is how many people here work in security whatsoever? How many people are developer adjacent or very developer facing? You have just secure developer code. Okay, you are the people I want to inspire

today. I want you to go back and find developers who do this stuff and have this conversation with them that we're about to have. It's not very super complicated. It's pretty straightforward, but it's about awareness. Yeah, they look like that. They look like a lot of things. AI will pop up in this talk such as this. I made this three weeks ago, four weeks ago. I said, "Hey, give me an example hitting an API endpoint." Anybody see the problem with this? I don't know if you can see it from the back. It's very bright in here, but uh yeah, just your access token, not environmental variable call, not any explanation whatsoever. I I truncated it, but there's no explanation

whatsoever to never put thumb something plain text there. Does anyone want to guess why all of Claude and uh cursor and all the GPTs do that? >> It's not just the documentation. Guess what they trained it on? They trained on GitHub. Have you ever seen the code on GitHub? In fact, in fact, we do. That's something my company does. We do this thing uh where we look at every new commit that hits public. You can too if you want to ingest the feed. It's api.github.com/events and it's everything that happens in public and we ingest it and we look at everything that becomes a commit or everything that's a new commit or anything that gets made public. So it

was private, now it's public and we scan it for it's got a secret in it or not. And this is for a prize. Uh a prize. All right. Yeah. Yeah. Here it is. This is for a prize. How many secrets do you think we found added to GitHub public in the year 2024? >> Million. A million other guesses. This is for a prize. >> Two million. >> Two what? >> Two million. >> Two million. >> Billion. >> A billion. >> Come on. For a prize. >> Secrets. >> Yeah. How uh hard-coded credentials, secrets, API keys, anything like that. Just just add in the year 2024. >> You're disqualified, sir. So, the person that said 2 million gets the prize.

There you go. You cheated. I didn't But I didn't say you couldn't cheat. So, I'll give you a prize later. You come down. I got a prize for you afterward. I'm just not going to throw it up that far. I'm worse throw it than this guy. Uh, but that's the report and it's that number because he just looked it up because I told you all to look at the slides. See, actually, you know what? Just for that, are you hacking my rule set? You get the other one I made. I was going to save it for here. You get the other one. I'm just can't throw it that far. It's a crocheted octopus. I make

them on planes. Yeah, but that's a horrifying number. That's why I do this little stupid giveaway joke. That was just in 2024. It's 4.6% 6% of all repos. It's 69.6 million out of the what 400 million or whatever stupid number they have at this point. It's 25% growth year-over-year. I hate this part about my job. This is the thing that I want to stop. I want this to go away and I can go out and do something else with my life. I'm not even joking. I tell my boss that all the time. Like I don't want this company to have to exist and just look at this problem. 70% of the secrets valid. We gota I got to frame that because

that's way too small of an infographic. We've been doing this since 2020. Been looking at every commit and we saw a fingerprint of all of these and the metadata of like where the path goes back to. So we can go back and spot check our work. So 11,000 we found to be valid, meaning they came back with something that said, "Hey, I work." Uh you can do an honor call for most known systems. Um, we look at a subset of the ones we found valid. Over 11,000 secrets. We like, okay, how many of these are still valid? In 2025 and January, it was 70%. Secrets we found valid valid in 2022 are still valid in 2025. Rotation problem is

horrendous. And we ask a bunch of practitioners out there. Oh [ __ ] I got that out of the Sorry, I got I got that in the wrong order. Apologies. Um, like I said, I went to a punk rock show last night. Didn't get a lot of sleep. Um, >> the DBR. Yeah. uh it keeps popping back up. We know this is like a major issue because this is one of the favorite ways attackers get in and not just their favorite way. It's the most common way according to DBDR. This is how most things start. Yes, exploitation of vulnerabilities is still huge. Fishing huge as we saw from previous, but credential abuse, I'm just going to

straight up steal a credential and use it. The math says that's not going to be a humans. The math says that's going to be a database API connection string URL or something. Uh oh, and the thing that keeps getting attacked the category of secrets that what they found this is our data is for web application infrastructure. Guess what that connects to? Your databases. Guess what? Your CIBC CI/CD pipelines have access to pretty much everything. average time to recover or average time to uh rotate is like 94 days once it's known they have this issue. So this goes beyond order. We ask we asked thousands of people IT decision makers us and again cyber arc they keep

popping up. Um I'm promise you I did not work for cyber arc. uh we asked them uh over a thousand people said IT decision makers like director level hire wrote back and they said 75% said we got strong confidence in our secret manager capabilities then the same people admitted like only 44% of developers follow best security practices like what that that doesn't make any sense but this is the one that stands out to me it's like oh yeah our average time to remediate they're reporting to us on a survey for companies that work in this field 27 That's not what DVR says. That's not what the actual fact. That spot checking we did horrified us. We like took it

public cuz we weren't originally going to report that in the report. That was just an experiment cuz we were just playing with numbers and we're like, "Is this real?" And we checked and checked and checked again. It's like, "Oh my god, this is real." So, what do we do? What do we do? What do we do? This is the conversation I want you to start having. Hey everybody, it's horrible out there, but there's a future. First, breathe. I'm not even joking. Security is about protecting humans. Period. That's it. There's a thousand ways to do that. There's a billion approaches. There's offensive security, defensive technologies, uh, blue team, red team, whatever we want to divvy up how we're

protecting the humans. But at the end of the day, we want that developer to go home, be able to spend time with their family, get some rest, come back tomorrow, and do kick-ass stuff. not firefight at three in the morning because production's down and they're the only people that know how that system works. You don't want to get out of bed at three in the morning and fight a fire. You want everybody to take care of themselves first. So step back, breathe, remember, we're all doing this best we can and OASP is on our side. Now I love OAS because I also see the world as everything's an application and so do they application that's what stands for

open web open worldwide application security project who's here as a member any members in this house yeah go OASP but they see the world very much through why do you have a network oh to run the application why do you have users because there's an application to hit why do you have a database oh so you can power the application everything from that point of view so that kind of skews my world just keep that in mind I think too many things. I think it's really just three things on that list. And if you go to a developer like here's 10 things I want you to learn about security and the 10 things I want to

talk to you about, you've already lost. They ain't got time for that. They have do X by Y date or you're fired and AI is going to take your job. That's the world of developers right now. Don't leave me. Go talk to anyone from Microsoft, Amazon, you know, all the other places that are laying off developers left and right. So it comes down to ownership, technical complexity, and long secrets. The good news is one of these is pretty straightforward to deal with. Oh, that's the wrong way. Nope, I just split this wrong side. Yeah, but in order to do the other pieces and even get to that point where you can do the fairly straightforward technical piece,

you got to get on the same page. You got to get everybody on the same boat. You got to like have people having the right conversations about the right things, put the right process in place, get the right documentation made around those processes, and then go and find the right tooling that fits your needs. Don't start with tooling. Start with conversation. And the conversation you need to have is this one. Who owns this stuff? I guarantee you there's someone in your company who thinks they own your human identity and access management program. If not, get out. Literally get out of your company because no one's in charge of uh if no one's in charge of access uh

uh domain admin and no one's in charge of Kubernetes, not Kubernetes, Keraros uh active drive. No one's in charge of active director intra in your organization. That means no one's in charge of it and no one's curing it and you're at risk. Go work somewhere else. Luckily in that most organizations that person exists. There's an IM person. They have a different title. They might not be called the IM person. They don't report to the board of directors until you get to the $5 billion revenue mark. That was data from ANS uh research group last year out of RSA. It's probably a little bit higher than that now because everybody's dealing with this. but an IM owner, but they don't want

this problem because the numbers I showed earlier, it's a 100 to one problem. And they're like, "Wow, I can't deal with the reviews of the people we have now. You've got me 100x the problem." So, it's going to take us all. It's going to take everybody to be like, "All right, I own this." I know uh somebody lead security in a very large platform for music and he's having this conversation with it right now like who actually owns our pamp like who literally owns it? You need to have this conversation. This is the hard part. This is the part where culturally I have no good information and advice for you other than to start reading papers about

how like Ford, GM, uh very large companies have done this. Ownership is very simple if you break it down in terms of you know go and landers golden rules for living. Open it, close it, turn it on, turn it off, unlock it, lock a motor cup. You break it. I'm not going to read the whole rest because it's very simple, straightforward. I'm the person in charge. I'm the one that makes sure it gets done. I am the person at the end of the day will get fired if this doesn't get done right now. It is the developer can just do whatever they want and the CISO gets fired later. That doesn't make any sense to me. That's

ownership. Ownership is the hardest one here and that's all I got to say about it. But you need to have that conversation with the developers like hey when you create this thing what do you think is going to happen next? If they have an answer for that you don't have a governance model in place. I have a whole other talk about governance models but we don't got time for that today. So, long live secrets is the next one. This is the one that's actually pretty straightforward to solve. Not easy, but straightforward because how do we get developers to stop using long live credentials? How do we stop them from just like, "All right, you exposed that credential. Cool. I'll

slap in another one in the exact same codebase. How do we stop this? This this isn't this isn't obvious. This is this is a redesign of some architecture. This is some technology adoption. This is a lot of conversation, some training, some awareness, but developers can't do this on their own. If they could, they they've already stopped because it' be the easy path because they'd stop opening bugs. Just know in your heart, I'm a developer advocate. I will always advocate that no developer in the world wants more bugs. They don't. Every time they do a security issue, make a security issue happen that they have to go and then get involved in, guess what? To them, that is a bug. A

bug is a bug is a bug. It stops them from going forward with their tech. It stops them from getting their job done. It makes them look bad. Oh, three bugs, you're out. There are some companies like that. How How do we help them not do that? Well, long term technology is beautiful and shiny and it's all based on OATH uh or OATH concepts, these like uh concepts. But who here has heard about Spiffy? Cool. Anybody got Spiffy in production? Right on. Right on. Zcaler uses it for humans, which is weird, but it's for everybody. Uh it stands for secure production identity framework for everyone and it is a way to name space and allow list the

very that's very overlification name space and allow list processes or identities basically we can't MFA machines right we can't MFA process Kubernetes Kubernetes pod spins up for literally two seconds to do something and then blows up and goes away. Are you going to give it an API key that doesn't ever expire that has a wide set of permissions? No, that's dumb. What you're going to do is you'll know all the details of how this thing is born, everything around it. And when it's born, you say, "Okay, here's your identification, your name space, your uh spiffy domain, uh the specific path, and we know you're you. And all of the certificate authorities know you're you." And now when you go into a system,

you can say, "Hey, I'm me." and then we'll figure out the au the authorization side on the other side of that trust boundary. That's a really really oversimplification of this. There's an awesome book, one of my favorite tech books I've ever read. It's 198 pages. It's free. It's a PDF. Highly recommend your reading assignment is to go read this book. But why is it called Solving the Bottom Turtle? >> It's turtle stacking literally. uh protecting this is a just two brief sum uh I didn't want to put two entire paragraphs up here but protecting one secret requires coming up with some way to protect another secret and then it's turtles all the way down. What happens

if someone gets access to your uh admin for uh for your vaults? >> That's a bad day because you got to keep guarding that secret. Where do you put that secret? Where do you put that secret? If you want to read a whole book, the best one of the best talks I saw all of last year is this one, Story of Crush. It'll help you understand this stuff way deeper than I can today. But just know that, okay, you're talking about like cloud native security stuff. Cool. What about the rest of us? Well, guess what? The IATF is working on this right now. They're in revision 4 of Wimsy workload identity multi environment systems. It's the same idea

applied to workloads across services, across systems. We're not there yet. Not there yet. But that's the architecture of what I just described. You come in to a gateway and it says, "Hey, who are you? What are you exactly? Oh, I know you. You can come on in. Go talk to the CA service. Go talk to your workload. The workload and CA service will work out what permissions you got and everybody's happy." Again, super super super oversimplification of a lot of really technical stuff. Just know this is coming. And I know it's coming because on May 7th of this year, it came to Kubernetes. This is how you can do image polls right now. This ain't the

future anymore. This is literally how you're supposed to do it from here on out with Kubernetes. Make the pod give the pod an identity. Let that identity get let it exchange its identity token. That should sound familiar. Exchange an identity token for an access token. Oh, that's called ooth. We've been doing that for years. We just haven't done with machines yet. Not at scale. Get shortlived automatically rotated things. Anyway, you can go read the docs on there. But that's how we stopped doing different secret. But that's the long term. The shorter term is a very clear path. If we take this path, then flipping over to workload identity management, workload identity federation, federated identities is

actually pretty straightforward. It's not impossible. We got to live in a world where we think every secret actually maps to an NHI and then NHI mapping and NHI inventories and understanding what you have running and how it all access all the access works makes a lot more sense. So this is going to go real fast and I apologize but I'm starting to run out of time. Find all your secrets, put them in the right place. Adopt better developer tooling. continually scan for more secrets cuz people going to be people and I'm going to have to rotate them. First thing you do with any threat model, find all the things that you need to protect. That's it. How do you do

that? People writing them down, right? You go to developers like, "Hey, what are all the API keys you generated in the last six months?" Right. Right. They make a backup of it. Right. Right. Unfortunately, it's not just code they're putting this in. They're putting it in text files. They're putting it in Jira. they're put in Slack. Fun fact, secrets we find in Slack and Jira, there's only 8% overlap between that and code. So, where do the secrets live and otherwise? Oh, probably are being stored in a vault. Bunch of tools that can help you find your secrets where they are. If you don't have anything in place, start with GPU. Get GP is awesome. Uh,

enterprise tools exist. I have a favorite. We can move on. Uh, secret managers, put them in the right place. This is a super accurate architecture diagram of how you use a secret manager in production. Uh, but basically that's it. You put the secret in the secret manager, it's encrypted at rest, then it's pulled into the application when needed and that's when it's used and then hopefully it's short-lived and it goes away immediately or you rotate it the next day. But that's it. Yeah, you should have some way to centrally report on this and have some kind of access control of like who can even see this stuff and how it's used. If you're all in on one cloud provider,

congratulations. You hit the lottery because this is easy because they all build one of these things. Uh if you're not all in but you are AWS heavy, you can actually use AWS secret managers as a multi cloud system uh or multi cloud authentication tool at this point. It's called secrets everywhere. I've never personally touched it but it's in the docs and I know people that like it. Otherwise, you're going to go with one of these players or somebody else like them. These are just the big four that I know of that I work with. Uh one of them used to be have an open source project. Anyway, they all work the same way. Just just pay attention to this line. This is

how you call into the path to your secret and then there's the full path to the actual secret itself. So calling the service call the path in this case we're actually hashing it out to say yeah this actually says hashy123 and print access granted. Never write a system like that please. But this part use that's all your developer needs to do. And you might look at that like that's all my developer needs to do is learn how to put it into something dive a path and then get it back out. Wow, that sounds awful. There's a really good talk though about what developers need to know about using a system like vaults effectively because it's not just we're

just slamming this in instead of a hard-coded credential. It there's a few considerations for blue green deployments for uh swapping secrets live behind the scenes behind a system like that. Kenton gave the best talk I've ever heard in my entire life about this subject last year at Bides Vegas and the show notes or the speaker notes have the direct link. If you're going after stuff, this is easy to do for Greenfield. And then you're going to see, wow, this works so much better and so much more secure and has so many benefits. We're going to do this for the crown jewels. And then you're going to find this whole bunch of secrets you didn't know you had. And you're going to

start asking, is this still in use? And then you're going to find APIs that no one's touched in two years that are still up and running, still costing you money, and still it's milling to a production database. Happens to everybody. It's called a zombie. You kill zombies. You shoot them in the head. That's how you deal with zombies. But how do we get developers to do this? This is this is the tricky part. This is the magic trick part because developers want to go fast and they hate security tools because security tools make you go slow. They slow you down and they just want to go faster faster. But then we have developers who work with security

engineers security engineers who build stuff for their for their dev teams. Yes, you're a hero. You're a superhero. Thank you for doing it. Uh this is where you can go talk to your developers like what's your git flow look like? because they're not going to talk about security because they don't want to because they're scared of getting slowed down. But like, hey, I'm here to help you optimize your Git workflow. Like, what? Just ask them how it works. Don't question it. Don't just take notes. And you're going to see all these places where you can start using git hooks throughout the git hooks and git automation and tricks and tips of git throughout the way they work and the

way they live to start doing things like this. I can't provide the actual actual script. And I've seen this actual run in prototype. Let them hardcode their secret. Don't let them commit the secret. Stop the commit from happening. Go and register it in the vault or go see if that secret exists in the vault. If it does, whatever happens, bring back a path. Swap that path in using set X. I don't care what bash tool you use. Uh swap it in for the line. Then present a prompt to the developer saying, "We have swapped it for this key. It will be rotated upon push. Do you want to continue? That's a real thing you can

build. Again, I've seen this built. It's a very long script and it takes some very specific technologies. You can also do that at the PR request because devs are still going to be dubs and they're going to end around their own hooks all the time. This is R. Reference architecture for what I just described. We built one with Cyber. Again, I don't work for Cyber. Uh, but this is open source. Um, again, the links are in the notes. I'm almost out of time and I got a lot more slides. So, Next step is to rotate them. Again, if you're all in on one secret manager, this is stupid easy. Uh because all of the scripts look like this. You uh look

like this. You create a new secret, you test it, you swap it in, you test make sure you didn't break anything once it's swapped in, and then you clean up the stuff. I know that because that's literally the AWS script I just showed you. And there's an AWS Lambda script for every freaking service they have because they want you to do this. they want you to do this daily or however often you feel comfortable taking the risk. There's a blog post about this. If you're on multicloud, you really can see if that third party will let you do it, that third party system. Most of them will. It's 2025. If you're dealing with services that don't allow you to do a

remote call rotation of a secret, write customer service and ask when that feature is going to implement it. And if they don't have a plan, it's 2025. They have competitors. This is our last one. Technical complexity. Everybody just described as like getting more and more complex, especially for the developer. We want to make their life simple, but to make their life simple, we need to do something that has a lot of hops. I used to work with Orion Lee, the guy who originally built Star Wars.com. And every time we would like architect something, he would be the guy that step back. It's like, too many hops. Too many hops. That's going to break. Like, we

can't do it that complex. So, we can't just keep throwing these crazy strings of technology at them. we got to step back and like so what are we actually actually trying to get done here but good news is there are some tools that can help us out with that I'm going to point to the CSPM market the cloud security posture management market that can help guide rail us again developers hate these tools but they work awesome um we can start talking about things like golden images uh supply chain stuff that also helps with the secret side but then it gets back to this problem of well how do we manage this at scale if we can't manage it with humans at scale.

Like the IM platforms are great at humans except what do we attack first? Yeah, Oct got breached ever. Um, Intra, yeah, it's super secure. No one's ever Nothing bad's ever happened with a Microsoft product. uh not to throw anyone under the bus, but how do we deal with this non-human problem at this scale and work toward a world of these long live secrets have gone away and machines are properly accounted for? This is a nonprofit group. Um full transparency, I spoke it spoke uh in their little workshop at Idenoverse and my company is a member of of the or supports them. uh were a sponsor. But what they have done is said, "Okay, here are like the four big things. If

everybody just gets on board with this, is how we manage non-human identities, then we're going to be okay." They also keep a directory of all of the various technologies for managing non-human identities at scale. I said a lot of things just now. That's why I give you the slides up front. The biggest takeaway here is we can't go into the future treating machines like we trust them implicitly if all they provide is a long lived string. And right now that's literally how we've built everything. Not everything. Some people do use P uh PKI everywhere uh public key uh public key infrastructure public private. Yeah. Anyway, um but by and large, if you look at how architectures are put together,

it's like, "Oh, just slap the API key here, slap theert here, put the EMV file. Hopefully, it never gets committed." It gets committed. Trust us, we have to figure out how to get ahead of this. Distributed federated ident federated identities and distributed domain authorities uh certificate authorities systems are the future. So says the ITF. So says cloud native security foundation or cloud native computing foundation. So says Kubernetes. Now we need to get in front of that. But to do that we really need to have a conversation with developers like what are you doing right now? How can we help you in the short term? Not just slap another plain tech secret there. How can we get them the right training?

How can we put the right processes in place? And yeah, eventually the right tools. Buy your tools after you have the conversations. Never go vendor first. And if a vendor wants to lead you through a PC and say, "Oh yeah, we don't need to involve the developers yet. Have suspicions." I'm Dwayne. I come from Chicago. Help people figure stuff out. It's my entire mission in life. Hopefully I've confused you enough that you'll need me to help you figure something out later. Uh check out the podcast. You'll like it. And uh yeah, I work for GitGuardian. We are also full transparency one of those NHI platform companies these days but secret detection is our bread and butter claim

to fame and with that I'll say thank you and there are slides up there you can get

and I'm a minute over but I will answer questions until we go get coffee >> so scale.

>> Well, it's the awareness. It's it's every time I I do that and you saw the numbers people were throwing out as someone guessed like I don't know 17,000 once I was like oh you sweet summerchild. Um yeah part of this is the awareness like if I go back here literally like raise awareness is like a major component of this. You can't just train them on like all right use this tool blindly. It's like you know why we're doing this right here's the big scope of the problem. Now, if your executive team, we don't have time for this, but if your executive team is like, "Yeah, but we're not really at risk ourselves, are we?"

This is why I hate the term risk. I hate it. Um I I danger. If they believed they were in danger, that hey, you're in danger that it's a time bomb waiting to go off that someone's going to get in with the credentials that we found in public and we haven't rotated them yet. and the D is clock is ticking, you can get something done. It's like there's a risk for any of this. Like you know what business is run on? Risk and debt. That's why they don't understand tech debt. Tech debt doesn't make sense to a business person because they have net 90s, they have net120s, they owe people money, they are owed money, they

all run on debt. Yeah, you got more debt. Cool. We have a danger that the thing is going to blow up. What's likelihood? Very high. Not. We have a risk. Okay. Risk probability. Give me an actuary table. What's the actuary table that you're going to get targeted by attacker next? There isn't one. Literally isn't one. Sorry, that's a complete separate. You get your hand up first. >> So, from a non-developer standpoint, if you're like, you're trying to manage third party risk for a software as a service. >> Yeah. Everyone you are looking at was willing to sign something that says, "Oh, well, uh, we abide by, you know, all OA's best practices." What are some

questions that uh you can ask that might uh flush out some red flags that they're using hardcoded uh uh secrets instead of using a bulk like they should? >> Cool. How fast can we rotate our credentials quickly? Can we do it over API? If they can't, if their answer to that is like, well, you would have to call us customer service. They're throwing hard code on a list somewhere. Like if they have to give manual involvement, that is a giant red flag. Um, hey, can we point to your S3 buckets? Like, can we get a sample of your S3 buckets? And if they are horrified, beyond belief, you ask that, hang up the phone and call someone else.

Uh, because that means their buckets are open or misconfigured or they're going to find horrible things about that. Don't believe me? There's a bunch of tools to go search their S3 buckets and do the OSYNC yourself. But just ask them and if they're like, "Oh, yeah, here's a list. Hit those all you want." And you're like, "Oh, wow. Can't get in here." That's good. Um, we can talk afterward, but like it's the biggest thing I would ask right now is like how are you dealing with multi- uh multi-system federated identities? Like what what's your future look like of moving away from long live API keys? And if the sales sales rep is going to have

no idea what you're talking about, but uh not to throw a sales rep on the bus, that's not their business. Um, say, "Hey, can I talk to someone in your company about the long-term roadmap for multi-system authentication?" And if nobody in the company can give you an answer, it might take a couple weeks for them to find that right person. Ask for Devrell or ask for um your head of IM like those are the people you say, "Hey, go talk to those people like give me an answer." And if they're like, "We got nothing." That's a horrible sign. If they're like, "We are working on it. What do you want to connect with? How do

you want to do it?" That's a very positive sign because everyone, that's the struggle right now. Whimsy, uh, Spiffy, if you're building your own Kubernetes clusters, straightforward as hell. What do you do when you have to reach out to a third party? That's the question word. So, if they're like, we're figuring that out. Helps figure that out. That's a very good sign. Yeah. Actually, we're go get coffee everybody. We'll talk after this guy. What's your question? >> Oh, it was a comment. Uh, you know, just great talk, but also like I think uh you talked a lot about how you know a lot of this chaos, but just I'm sure you know a lot of organizations