Securing Non-Human Identities in CI/CD Pipelines: The Next Major Attack Vector

Hello everybody. I am Diva Bala Subramanion. I know just go by Diva or divs. Uh and I'm a mom with a huge passion for cyber security specifically identity and access. And I get the privilege of doing what I love day in and day out as a cyber security leader at Southwest Airlines. Well before we start couple of disclaimers. We are here out of our own personal interest and not representing that of our organization. Second, this is a talk about non-human identities and we would love to cater to like you know a broad spectrum a broad skills of people. So we're going to start with very very foundational concepts. So this is a more beginner really beginner

friendly session. So if you are a person that does CICD in your sleep, you kind of you know know the ins and outs. You may feel like a Shakespeare watching racial on YouTube. Go a for a apple. So just the other reminder just to make sure you're still in the right room. This is a foundational course about deopsy. I say they're non-human identities. So just want to make sure you're in the right room. They'll be worked out. Well that's awesome. Then let's get started. All right. Uh the agenda the first 30 minutes we're going to cover foundational concepts of what is DevOps, what is CI/CD and then we will drill this further into just the CI/CD part

where we will talk about non-human identities and then we will talk about how it gets exploited in the wild about the breaches that happen every day and hopefully by the end of 30 minutes I'll send you enough to listen to him talk about how do you secure this? How do they stay safe? Right? So that's going to be what your next R is going to look like. And then finally to Q&A over the recent years, you know, um everywhere I turn, anybody I talk to, this feels like CICD has become the new normal, right? Everybody is kind of using it in one form or the other. And I hear people brag about how transformative it is.

During one of my lunches with one of my good friends, we had a pretty intense conversation about this topic and I went, "Hm, I'd love a good transformation. Maybe I should hire a DevOps engineer, too." She looked at me and goes, "Okay, what problem are you trying to solve with DevOps?" I kind of went speechless. I'm telling you, my husband would have enjoyed or paid money to watch me go speechless in the middle of an intense conversation. You know, that never happens. That wasn't his lucky day though. But I did speechless not because I didn't know what problem I had. Of course, I knew what problem I had. No, I wanted less friction between cyber security teams

and know the rest of the company, right? And I wanted things to go smoothly. I wanted less manual work, more automation. But is DevOps a solution? Beyond all of this buzzwords, what does DevOps actually mean? So if I run a CI/CD pipeline, does it mean I'm DevOps? I actually had no clue. So I started my research like any good student. I went straight to Chpt and other genai tools and I also used search in I know I know don't judge me. Okay, I'm still a little old school. But somewhere between Chad GPT patronizing me saying that's exactly the kind of question you should be asking for. I know Chad GPT are listening but no offense and me taking Chad GPD

responses and checking with Google. Hey, is that guy telling me the truth or is he just really rooting? Right? Somewhere in between this world, I figured I need a better way to picture this in my head, you know, and I'm a person that learns better with analogies anywhere. So I ended up picking that's something that's like common for hopefully all of us restaurants. The more I thought about it, the more I realized that restaurants are not just a place that serves food. It's a system of coordination, speed, quality, and it's surprising in many ways. It made me feel more relatable to DevOps and CIC. We say like you know you go to your favorite restaurant, you order your

favorite food. What happens in that kitchen is actually a very structured workflow. The order gets placed in the system. Someone's, you know, getting all the ingredients ready. The chef is preparing the food and hopefully checks it for taste. The dish gets plated and it's ready and inspected. The server takes the food and delivers it to your table. that box area that's CIC. It's automatable. It's repeatable. And once your dish is out of the kitchen, the CIC is done. But let's zoom out because the kitchen is obviously not the entire restaurant, right? The restaurant is much more than that. Restaurants includes things like the menu design, which is like our product decisions. It also includes hiring the right people, the right

chefs, you know, the right uh servers, managers. Let's take our or design. It also involves the fact that all of these people that we just hired kind of work well together. The cross functional team collaboration. It also includes handling customer complaints like an incident response. It also includes consistently monitoring the foot for its quality. that you're observability because if you go into the restaurant one day the food's amazing the next day you go it's like me and the next day it's like I don't know what this is well the probability of you going back to the crest has declined it also includes health and security standards right that's just security and compliance without one stomach after a

meal your probability dropped to near zero of going back to that If you notice something, most of what I just said involves more than just usage of tools. It has a shared sense of ownership instead of hattops. It's accountability as a whole instead of playing. Let's say the kitchen messes up, right? Your servers, the managers there, they're not just going to stand back and say that is that guy's problem, that guy. It's not going to help anybody. They all come together. They fix it together. That mindset shift of shared ownership for a great customer experience. That's DevOps. Once it works beautifully together, you break a great customer experience. If it doesn't, no amount of automation

is going to help fix that. DevOps is not about speeding up the kitchen. It's about aligning the restaurant to deliver value. And if I keep talking about food, the smell of pizza, they talk about food, I'm going to walk out of my own session. So before I do that, let me switch to something that is less interesting than food work. Good. >> Well, as engineers, right, all of you write code day in day out. Instead of checking stuff in at the end of your sprint or whenever your PM bugs, you're like, "Hey, I need that code right now." Right? Just continuously check it every day. Make sure that your code is constantly tested and integrated

multiple times a day. That's continuous integration. And as a team, if all of you are working together in a shared code base, just make sure that that code base is continuously tested, checked for security, and it's always in a deployable state, not deployed, deployable state. That is continuous delivery. The ultimate goal of most organizations, you know, most engineers is continuously being able to deploy the production without the need for human intervention. That is continuous deployment. And DevOps, DevOps is kind of the foundation. It runs like all over. It's an operating model that aligns people, processes, and technology to enable continuous value delivery through automation measurement and crossunctional ownership. Well, today we know CICD has become the

backbone of almost all organizations, right? But was that the case like 10 years ago, 20, 30 years ago? Well, some of you in this room were like, "Yo, I wasn't even born 30 years ago. What are you talking about?" Well, yeah, life wasn't the same 30 years ago. In order to truly appreciate what you have today, let's take some steps back in time and look at all the stepping stones that helped us get to where we are today. All right. How many of you all in this room have installed or upgraded software using floppy discs or CICD? I mean, your CDs. Thank you. I was I'm so glad I'm not alone at this room. I was so scared

to ask this question, hoping I'll be the only one doing that. And everybody's like, "What's a floppiness?" So, thank you for not making me feel alone. >> Oh, those good old days of agile. I mean, not agile, waterfall, man. Um the law of planning, the even longer documentation that people barely read or write, >> the big bang releases, that was a whole different lifestyle. Well, I'm so glad, you know, we're not doing that anymore. But in the early '90s, Gdy Woods coined the term continuous integration. He meant no small bank races, guys. Don't wait for a big ban. But that term did not pick up much speed until extreme programming came and said, I don't know why they

called it that, but it felt a little extreme probably at that time. It said, integrate early, integrate multiple times a day, and run automated tests. back >> 2000s came thank god for agile the way that we delivered started changing but the friction between development teams and operation states we're still there in 2007 a builtin engineer called Patrick Dul he was working on a large data center migration project and he felt the obvious friction between development teams and operations teams as in the developers will write the Right? They'll ship it to the ops team ops ops team as like our system admins, network administrators, database administrators, they will ship it over for example and then let's say they

deploy it, it doesn't work. Operations team says your code's bad. Developers like your infrastructure sucks. So that divide was getting so so obvious. It wasn't helpful for anybody, right? We are all working to the same goal. What's the point in just like blame gay? So Patrick really wanted to bring these two worlds together and help reduce the friction. But that idea wasn't Paul Vigor back then. He did not get one track. In the year 2008 in an agile conference in um Toronto Andrew Shaper he proposed a topic called agile infrastructure under something called birds of feeder. Those are kind of concepts where you know you propose an idea people with similar minds they come they talk about it right. Of course,

Patrick was excited. He showed up and he was the only person to show up as in literally the only person because Andrew wouldn't show up himself. He got so much negative feedback for Star that he ended up canceling his own session. My god. But Patrick caught up with Andrew in the hallway and that their discussions led them to form their systems administrators global group. Still not much traction around, you know, DevOps yet. And in 2009 at a velocity conference, John Albog and Paul Hammond they presented the famous 10 deploys a day be dev and arms cooperation and seeker. That was exactly what Patrick was looking for. He was so excited about his idea coming to life at Singer.

Motivated by that talk, he actually in Belgium formed his own conference called DevOps Days. Pretty sure some of you are familiar with this is still running but that's when it started people from around the world came for the conference and that's when the grassroot movements of DevOps actually started this group that came together the milit and they continued the conversations at Twitter because of the hashtag liven the word devops days hashtag went to #deops and that's how you know all of this evolved while this concepts were going on in this side. The other side CICD tools were starting to evolve. In 2001, the first known CI tool cruise control came into existence and then came

generic CD tool because most of these existing CI tools, they were just extended to allow CD capabilities. But the first known CD native tool was Go CD. And in the same era a lot of more tools came into existence like shift puppet and so so on 2010 era that is when like know the book continuous delivery was released which gave developers a blueprint to make CI/CD scalable and operable in 2011 Gartner's Cameron Hayes he predicted that by 2015 a lot of organizations will start adopting DevOps In 2030, the research group called Dora was smart. Today, they are part of Google Cloud and they publish Dora mentorings. So, anybody in DevOps, you're pretty familiar with Dora Metrics. It makes

DevOps measurable. You can't just say like, hey, it's great. It's got to work. If you don't measure it, nobody's going to buy it. So, Doral metrics made DevOps actually measurable. Same book called Phoenix Project, which is still very popular. And that book if you haven't read it I would recommend you all to read it that made DevOps applicable for executors for leadership because it showed how much the flow of work is important for an organization. Then 2010 was an era which was very transformative technology wise. As you all know, cloud came in, right? As much as all of these concepts were coming together around this time, the explosion of cloud and containers made a lot of

these things actually possible. Really large organizations like Amazon, Netflix and you know all of them, they were very early adopters of React. But around this time lot more organizations actually started following sweet and here we are. So what's next? What? >> I managed to go 20 minutes without talking about >> AI. Yes, that should be a first. But I'm going to like you know uh at least the security front, right? We've definitely shifted a lot of security left to dev sec ops to sees, especially introduced a lot of security into our pipelines. As for AI, we have a lot of updates are coming up. MLOps, ops, dev sec, dev ops, dev sec ops, so many

things that I am very excited to see where AI is going to or how AI is going to shape our future. Hopefully the last time I use that word today. >> Well, this is source credit for James Bowman who put this together like quite a few years ago. But this is just a rough idea of you know how many tools exist in the deol landscape. So for a lot of years we have paid a lot of attention protecting human identities right most of the organizations today have evolved to use like pals phytobased MFA you know just make sure that humans you know act more mature but in that process we ended up generating pack tokens like personal access tokens that

just never expire >> that's like locking the center you know adding so many layers of security at the side door and leaving your back door and windows open. >> That's not secure. And the more you do it, your attack surface expands exponentially. So what we want to do next is take a look at how these energize get exploited in the wild or I mean before that let's just look at what these NHS are before exploring them. So in order to keep a kitchen running, you need one or two ships, right? In order to keep your pipelines running in an automated fashion, you should keep the ships out as in the humans out of the loop. And you need to bring in this

invisible workforce. This invisible workforce is like everywhere. It's in your build stage, it's in your test stage, it's in deploy state, it's like everywhere. And if you haven't done it right, sometimes this workforce runs with admin privileges even when it's not needed to. And there's barely anybody monitoring this workforce, right? And there's barely a sense of clear ownership for this. So what is this invisible workforce? Well, some call this non-human identities, some call this like you know machine or workforce identities. remember when I was, you know, talking to my pre-teen nephew about it. When I said non-hub and I showed this picture, I was like, "It's non-cubling. Why don't you have a cat and a dog up there?"

Well, great question. I might the day it starts coding and deploying to production, I may put that up here, but not yet. So that's why this term you know non-human may be a little controversial but we're going to ignore the name for once and just focus on the issue at hand because the problem and the concerns that we all have around the space is real irrespective of what we call it right and by no means that this is the list of nonhuman identities. This is just a list for some of you all that may not be familiar with what it was up here. We'll just cover a couple of it pretty briefly. Uh and then do pay attention

because some of this is going to be exploited in a breach that we will cover next. Perhaps let's pick AI case. Yeah. Let's say like you are a developer al you know an API. It's providing such awesome information. Everybody else we in the room we really like what our API is providing for us and so we want to consume her AI programmatically. So what she's going to do is genet an API key and give it one per app. Using that key, she will now be able to track which of her applications are calling her and also throttle limits. You know, that way I don't end up launching a DDoS attack on our API, right? You can think of API

keys like um your library cards, if you will. You get a library card and it's going to stay there with you. It doesn't expire until you cancel it or you end up never returning the books and the library suspends it for you. I can neither confirm or deny if that's happened to me. But that's your API keys. Tokens on the other hand, they are like your movie ticket, right? It expires right after the show. For example, npm tokens, pat tokens, oatc tokens, jot tokens, enumeral token just keeps going. But tokens basically give you temporary access for people or processes. A token can represent a user identity. For example, personal access tokens that enumerates the p you enumerates the

privileges of the user to whom it's issued for. The token can also represent a non-human identity like your services, your pipelines, your bots, so on. Two things I want you to keep in mind when I use tokens. Police do not take a token issued for a person and stuff it into your right way. That's a big no because that token is going to probably run with more permissions than it actually needs. Second, do not make your tokens static, long lived or broadly scoped because it's convenient. If you lose so then it's just an API key where other name what's the point third service accounts so just like you know we all have our unique identities right

that's way if we go f they know like hey you ID number 1 2 3 you cooked it up so just like that we need an identity to figure out what service did what so identities of service accounts I mean identities of you know this name and machines or workloads they are called service items next. So like I said if we haven't paid close attention to all of these or like you know any of these not human identities the probability of it getting exploited in the wild is so real. So in the next few minutes we're going to look at some real world incidents that have happened because of this non-human identity attacks. What's listed here is just some

of the breaches that have happened in non-human identity specifically in the CICD pipeline and I really wish I can go into details of all of these for your awareness but for your sanity I'm going to just become one. So we will focus on the npm attach in the session and in this slide we've only shown the 2018 one but the next we're going to see how often npm is being compromised. But before I go deeper for people who may not be familiar with what is this thing? Well, developers never write every single line of code from scratch, right? We are always going to depend on an external package to help us, you know, do that job. For JavaScript developers,

npm node package manager is the repository that holds all of these packages. Think even as of 3 years ago it had about 2.1 million packages making this the world's largest software registry. What would go wrong with well as you can see it becomes the most favorite target for supply chain attacks. Again this is probably non takes also with we've already not called out the singularity or the quicks compromise but we will focus only on the most recent attack that for this session. Well, one more audience question. Any sci-fi movie addicts like me? Oh, good. How many of you all watch Dunes? Okay, awesome. Well, for those of you all who haven't, that will be your most

important takeaway from the session. Watch Dunes if like, you know, sci-fi interests you and it has anb rating of 8.10. Yeah, if you go watch it, you don't like it, don't just me. Now, there are more people to play, right? So for those of you all that have watched this movie, you know what a shy hello is. That's a desert world, not a pretty little one. As of September 2025, our software world, we have our own version of this shy word. So what is this? This is a self-replicating malware that targets npm packages. Its selection of targets is so strategic and aims for you know the highest most heavily used npm packages to kind of you know uh you know

get cause maximum damage. Yeah, for the sake of this conversation we're actually going to really deep dive into the specific hack. And for this conversation I'm going to pretend I'm the hacker. Trust me and definitely not. See no black hoodie and I'm from Texas. I don't live in the basement. So you're saying if you could just to make it more easily relatable, we'll just do a role play so that it'll be easier for me to explain hopefully easier for you to understand. All right. So here goes. Let's say all these guys up front are you know developers of some npm packages that is most widely used. What I'm going to do I'm going to compromise all of your

accounts. Now I and you everybody else in this room you guys are JavaScript developers relying on their packages and you have auto install dependencies enabled in your developer machines or on your CIC. Yeah. So I take your package I unpackage it put in my malaious script package upload to the rep. Y'all have graciously done an auto install. So you're going to pull in my tainted package and the installation begins. As soon asation begins, my malicious post install script is going to kick off. And what's that going to do? Well, you've heard me talking about the non-human identities few minutes ago, right? That's my target. That's what I'm after. So, I'm going to scan your repos

and look for environment variables and configuration files that has np tokens, GitHub tokens, you know, your credentials, anything and everything. And I've also deployed truffle hog know the legit secret scanning tool for me to get as many secrets as I can. While in the process of gathering these secrets I don't trust that all of yall have like all legit tokens. Maybe you have a token you just never bother touching it up after used it once. So while I'm gathering your tokens I'll validate if what I'm gathering has publish or push proof pages. I only need things that work. So I that is how I'm going to gather all the valid credentials from you. So while I'm in the process of

gathering this information, if I come across uh let's say like a GitHub personal access token, a PA token, right? Here's what I'm going to do. As I said before, PA token enumerates the permissions of the user that's issued for right. So let's say like you are a user of their packages, right? So you ended up installing this package of mine. So now I have your token. You as a user, you've installed this in one of your repos, but you have access to 200 other repos. I have your token. You have 200 other repos for me. I'm going to iterate through all of your other repos. And in all of those 199 repos, I'm going to install my malicious workflow which

get triggers on push. So once somebody pushes something to those other repos, my strip's going to kick off. It's going to exfiltrate all the secrets from that repo and it will publish into a web hook site. It's kind of like a driptop location for me to come and get your secrets later. See how I traverse through your environment using your non-humiven identity. So be careful about that. Second as in doing the scan records an LPM token. That means you are not just a user of somebody's package. you are a publisher of more packages. Yay for me. >> I'm going to take a look at all of those packages that you are a publisher of and

I'm going to sort them by the most highly downloaded ones. You may have a package that nobody uses. That going to be of use for me. I will sort it and I will take the ones that's most often downloaded. I'll take that package, put in my script, repackage, upload. And that's exactly why this is called a verb. That's how your cat of moves to the environment and end up infecting more npf packages. So since I've gathered all of this information, I need access to this, right? So I am going to create a repo, a public repo in your account, call it shyut one, take all these secrets I harvested from you, put them in a B 64 encoded file, JSON file,

and put that in the repo. So now I have access to all of the secrets from all of your repos. Well, you found me. You stumped me. That September 2025 was done, but this is November. And I'm back again. Let me poke you. Well, this time, what are they after? Same thing. Their secrets. Unlike some phones giving version enhancements, I've actually really had some enhancements in my version two. So as and when I am scanning for your secrets this time I'm going to deploy an official SDK your cloud provider's official SDK right. So if I find a valid cloud credential that you have I'm going to use that credential I'm going to look at only secrets manager tools the stuff

where you think your secrets are safe. So I'm going to scan that and extract more secrets from AWS from Azure from GCP and could extract all of those secrets. So now I'm sitting on more secrets than before. What I'm going to do similar to last time take all these secrets create a public refer in your account but this time I'm going to name it with a random UU ID but the description sha follow the second coming so this time I also have like three more enhancements one cross victim acceleration if the token I have for your account is no longer working you know I'm sitting on a treasure trove of more tokens right I'm going to take that and attempt to see if

any of that works Second, I'm going to install a backd dooror because sometimes, you know, this can be like a one type thing, right? So, I'm going to install a backd door. So, what I want to do is I'm going to inject a GitHub actions workflow on discussions.yammo in your repository. What that's going to do is going to install a self-hosted runner in your machine. Right? So, whenever I open a discussion in your repo, this will initiate that self-hosted runner to kick off. And now I can make that runner do what I want. So AI control one command that executes. You guys have not found much evidence of me using this back this back door. But

be aware. Third thing this time if I did not find a GitHub token or you know an npm token, I'm going to turn into Hulk and destroy your repositories. I know of me but that's what happened. Well, again, you all found me and you stopped me. But by the time you got to me, I got about 25,000 graphos and it's still sitting on all of those secrets that I've harvested from you guys. So, if you haven't listened to the good guys and taken the action to rotate the secrets and do your reset, then time will tell what's next. >> End of role play, back to real life. I don't know about you guys but when

this came it was mighty scary at least for me this is just a whole another level right because it's not just us telling that you know identity please protect your identities so many industry reports like the Verizon DBI report parallel report identity is the most common initial attack vector not just humans also not humans and if you're wondering so what's the big deal we are doing so much to protect human identities You're saying this is not human identity. Why don't you just apply the same concepts for this? What's the big deal? >> God. >> Well, I'm so glad you asked. That's what we're going to cover next. Oh, well, this is just a screenshot from

posted by Guardian as to how much credits in the second attack. So, if you have a personal access token, please rethink your Saturday. All right. Well, traditional IM, you know, I would think it to be covered under like four broad pillars. Yeah. First up, directory services. Um, in most organizations, the managers, poor humans, there's almost always a centralized repository, right? Like your HR system. You get hired, your information gets put into a central system, and that same process is repeated for every person that gets hired. For non-humanities, we fail right there. There is it is possible just not in the same way as what we've been thinking about for like you know traditional identities. Second pillar, identity

governance and administration. Again, when people join the company, right, there's something called a joiner neighbor mo process. What happens when you join? What happens when you move? What happens when you leave? There's a pretty clearly defined process to handle people. And we also have like periodic access reviews that people use to make sure that you still have the access that you need. For example, if I have like 10 people on our team, right? So periodically can do an access review to make sure that they have the right access. Nothing more, nothing less. Painful, very painful, but doable. Now imagine if they ask me to do that for 500 non-human identities periodically. Well, I'll either periodically need a

double paycheck or I'll quit before I lose my mind. >> Definitely. It's not practical or scalable to apply the exact same concepts that we done for humans for non-human too. Right? Third pillar of IM access management, right? As humans or adverts, it feels so weird constantly referring to us as humans, but let's just keep going. As people, we all log into a UI, right? And most organizations, we just slap SSO or MFA on top of it to protect people from logging in. How's your inner tie going to MIP? For all I know the future it may well but at least not yet right for your privilege as that is for protecting you like a highly

sensitive highly superpowering users but most of traditional paths have been secretentric rather than identitycentric. Yeah. Well, I have been nothing but a doomsday girl in this conversation so far. >> After giving you the foundation, I said, "Oh my god, there are potentially non-human identities that you did not know existed, and hackers could exploit them 10 ways from Sunday, and you're doomed." What a bust. Well, but our industry definitely has a lot of amazing smart people who have built incredible defenses against these attacks. So, I'm going to let the smartphone on the stage take over and bring back hope and light into this conversation that I've successfully killed so far. >> All right, over to you Vicas. The group

will limit the patient and then have the bike going on. You want this.

All right. Hello again everyone. Well, thanks Dia for setting the context in the ground here. I always like to talk after the via because she sets the ground and takes most of the time. So I have very little time. every day or what he has to deal with every day. >> All right. So as Dia mentioned earlier, so we plan to do this for a very beginner level, right? So we wanted to pick GitLab as a CI/CD tool here and show it to everyone like what what what CI/CD is on a high level and the PAT tokens that Diva was talking about and where exactly we create them and how how it can be used in a good way and also in

a bad way. Right? So firstly uh for anyone who haven't seen GitLab so here it is this is GitLab for you one of the CI/CD tools and I had a demo version for now but when you have this in enterprise you generally have a login before this you have a SSO page that's how you log in and you have roles tied to it and yeah you make sure what repo or what top level group you should be part of and that's stuff you get into this. So once you get into this, this is exactly where everything happens. The CI, the CD, all of it, your code goes in here, your deployments and everything would live in this

ripple, right? So what I would like to show quickly is uh when you go to your profile as you log into this app and when you go to your profile we had like pad tokens reference that we had earlier right so there are different ways you could use to connect to GitLab APIs via either pad tokens or SSH for this demo we'll be using pad token as an example And we'll be generating one. And as you can see here as the permissions that you have whenever you generate the pad token, you would literally have access or ability to create the scopes, right? So just be mindful uh whenever you create these PAT tokens, you could

literally have any scope and GitLab wouldn't allow you to retrieve the PAT token once. So it would force you to either store it somewhere or right make sure you guys store it in a secure way like either secret vault or somewhere do not save it in a notepad team themes message or slack we'll we'll get to it what happens in case if you do so all right so for this demo I have used a quick example of a hello world application that you can deploy through CI/CD And we have two ways uh that we have built the YAML file here, right? So one is through a way where you have your application token or API key stored like

through development environment. As a developers when we test we always tend to use secrets locally, right? And we tend to accidentally push those, right? So what what happens is when you have these secrets stored locally and when you push it like and deploy this through CI/CD the logs and the commit history everything would have your secret exposed in it. This technically like is an API key which you are exposing and which is vulnerable. So what we recommend here is try to limit the usage of secrets and go through the OIDC way of implementation uh which is like generating your ID tokens or access tokens and using it for a token exchange for your API endpoints. So you could

either rely on your IDP to generate those tokens or git has ability to give you IDC tokens. Now, so you could use those which would have a user context and you could pass those to your next APIs and still pertain the user context in it and propagate it to your next hop. So you know where exactly uh the request is coming from, right? So you have both the agent context and the user context. So wherever you can just make sure to eliminate the static secrets and use OIDC and yeah so the this example shows like how you can have your IDP integrated into your pipelines right so you could have these integrations and as you deploy right in

the previous example we have seen what what happens when you have a static E And now with a short-lived OIDC token, all all they could see is a token which is short-lived. Even in the worst case of an exposure, it would just expose for the type short lifetime of that particular token. Right? So this is the ways that we could deploy. And moving back to the example I was saying when you have generated your pad tokens and you have accidentally stored it uh into a text file uh in a repo and you have accidentally committed. Now that's has been pushed and as you see here like you have pushed your pad token into your repo. Now I would like to quickly show

like as we have created pat token earlier what what would this mean like right so let me quickly run some commands and show what what these pat tokens can expose and cause right so the very first thing is like you could literally be able to clone the whole repo using just that single pad token right That's the first thing like uh

so that would be the first thing any attacker would like to know to read what exactly is in the repo. Right? So well technically you now exposed a pad token in your repo and attacker has got hold of it. All he would have to run is a git clone using your pad token and that would technically give him access and would be able to download using that pad token. Right? And now let's try to see. Let's do analysis and navigate to that

repo and do analysis. Now you can see whatever you have on your repo is now in this attacker's local machine. Right? That's the very first thing you might think. Uh what's what's the big deal? They can just see the code, not push anything. But here's the thing. If you have generated that pad token with right access or or the stuff you never intended to, right? So let's see quickly on on like what are the permissions this pat token could do. It could literally connect your G APIs and do a curl command, do a push read, everything. Technically, it could like literally do stuff that you never intended or wanted the attackers to do, right? So,

thanks

Yeah. So, one of this example is like the command that I ran would give them the ability. It's a screen full. So, they're so this would give them the ability to see the whole repo, right? It would give them all the commit history that they had, every everything that this PAT token has access to. they could literally see every action which we never want, right? So hopefully this would give you an idea on how powerful these PAT tokens are and how mindful we have to be whenever we store them or yeah so here are a few more stuff that you could do. uh like I won't run through that but we'll get into the defense layer of it but

technically like as you have the permissions on your pad token it could technically have those like impact now let's go to the defense framework right so how till now we talked about uh what what what would it mean right from an attacker standpoint like uh how how we could expose all this but how can we make sure to defense right how do we make sure to secure so here are some of the stuff we have researched and these are some of the ways you could do uh this is not the explicit list but just keep keep this stuff in your mind whenever you are designing stuff or building your repos just try to double check or triple check you are following

all these defense def layers, right? So, the very first defense layer is discovery and visibility. So, how many non-human identities do you all think would live in a simple CI/CD repo in an enterprise, right? Maybe tens, hundreds. You all think that might be the number. But in an ideal enterprise, right, at least there would be several hundreds to thousands of non-human identities in a single GitHub repo. So, well, yeah, this includes not humans, right? Machines, pipelines, bots, access tokens, all all of these non-human identities. So without knowing how many number of non-human identities we have, how do we secure? So that's the problem that we have today. We do not know and have an idea of how many non-human identities

that we have. So the defense layer one talks about shedding the light, right? Turning on that light and giving the visibility on to identify them to have all these non-human identities bring into a centralized place. do this periodically, discover them and have these like uh have the tags on these non-human identities. Whenever you create a non-human identity, have a purpose to it, right? And have a owner tied to it. So that way you can just easily flag whenever you find a non-human identity which is either stale or has no purpose to it. So the defense layer one should always be on the discovery and visibility of it. Right? So make sure to run the secret scanning

regularly. Right? The example that we have seen there might be accidental ways the secret could be deployed and pushed. So if you have a better secret scanning tools and have those scans run regularly, mistakes do happen. But with those tools in place, you could definitely find them and do the fix that's needed. Right? So quickly on the defense layer one if we have to give an analogy to it and put it in a simple terms uh whenever I clean my garage right I always find stuff which I never thought I had and like and I surprise like what what's uh what stuff do I have and do I really need why did I even get this

right so that's the same analogy here make here to discover all those and whatever you think is not needed get rid of those and whatever you think are needed just secure them and have this ownership tied to it. That's all about defense layer one that we wanted to emphasize. Now coming to the defense layer two as we have seen what a catastrophe a static secret would do right. So wherever possible make sure to replace that uh with OIDC tokens right. So, how many of you have have ever seen AWS key or a secret that has that you have shared in a team, Slack, email or stored in a notepad, right? So, we never think about it. We just think that it's an

it's a one-time thing. No one would ever know unless an attack happens or it gets to you, right? You never know. So, it's better be safe than sorry. So make sure and think twice before you share those secrets and always think through and see can't we just eliminate that secret and wherever possible federate it right this shortlived tokens would give you a lot flexibility on like even if the breach happens or that token exposes you could control you could hit the revoke endpoint you could revoke those tokens and do stuff and Yeah, defense layer two emphasizes on that stuff. So if I have to put this into an analogy here, right? Think of it like you have a key to enter

a house, right? Well, technically anyone could have that key. There's nothing proving that it's your house and only you are authorized to enter. But imagine there's this fancy house, right? Only with your face ID. It would scan you and allow, right? That's what defense layer 2 about is about in the ODC tokens. So you could only enter your house if it proves that if it's either you or an approved party and only for a certain period of time. So that's that's all on defense layer two. And coming to defense layer three, what we want to emphasize is lease privilege, rotation and integrity wherever possible. Make sure to have lease privilege. You don't have to tie all CI and CD

together. You can segregate them. CI can have a different set of permissions and CD can have a different set of permissions. Make sure your prod and non-pro doesn't have same set of permissions. Right? Wherever possible look at for those least privilege stuff and try to secure those. Rotation is the key. Uh we know sometimes it's hard to eliminate secrets. I know we are going through passwordless but it's not easy to adapt and go right so I know there are times yet we would need a secret whenever you would need that make sure you do rotate them very frequently so similar to tokens right which has shortlived not that amount of frequency but try to maintain a periodic rotation

on your secrets and w them securely right So that's on the defense layer three list privilege rotation and integrity. Integrity make sure to sign all your requests and only those signed request uh six stores and signatures right. So that way you know like the integrity aspect of it is stored. So the outcome of the defense layer three would be reduced privilege footprint and the shorter compromise windows. And if you have to put into an analogy on the defense layer three, it would be like a TSA agent sitting and checking you and your identity for you to able to enter into the airport and get to your flight. Right? So that's all defense layer three about and lastly on the defense layer

four governance. Man, I do have a very tough time on this, right? Coming from the security background of it, when I deal with different teams, they see security as uh a workaround, right? So security should be a lifestyle. It should it should not be one team's responsibility. It should be a shared responsibility, right? Like every team who is developing should have security embedded into it. So I can't emphasize more coming from a security team and IM team defense layer 4 will be your strongest strength governance right so make sure to have governance around your CI/CD that's an important thing and follow the N standards there are standards out there like how to secure your framework

and pipelines make sure to follow those standards and develop uh your CI/CD and stuff that you are getting into. So yeah, uh putting defense 4 into an analogy, it would be like you would go to your dentist, right? Have your regular checkups and all so prevent major things. So that that's what governance is all about. So like I said these are all the defense layers that you can try to adapt but these are not just limited to it. Uh we felt these are the four defense layers which we wanted to emphasize and make sure you all follow in your day-to-day practice. Well, that's about defenses and quickly on the next frontier, AI agents again, right? Who would end the demo without

talking a AI and AI agents? So, just with CI/CD, we had so many non-human identities. What's coming up next with AI agents? We have co-pilot agents, we have bots, we have different LLM tools which want to connect your repos, open MRS, do reviews and stuff, right? Just be mindful about those. Make sure you are planned and prepared for the next frontier and have a plan in place, right? How do you tag identities to those? How do you make sure those LLMs and boards don't impersonate you and they have a clear definition? Right? Just try to think about those stuff uh while you're designing or getting into your next agents. With this, I would like to thank each

one everyone and over to you the view.