Name: Secret Leaks: Trends, Risks, and How to Respond
Uploaded: 2026-07-28T17:30:10.749Z
Duration: 1 h 54 s
Description: Secret Leaks: Trends, Risks, and How to Respond

Transcript for "Secret Leaks: Trends, Risks, and How to Respond": Alright. Welcome everyone to the GitHub Advanced Security session today. We're gonna start off with a quick round of introductions before we get into today's agenda. I'll start with introducing myself, and then I'll let Leo introduce himself. Just to give everyone a quick idea of who we are, why we're here, and a little bit of our background so you get a sense for why we have our perspectives on the specific topic we're gonna be covering today. My name is Lupita Carrades. I've been with GitHub for about three and a half years now, but my background started out as a full stack software engineer. I give you this context because as I'm talking through some of these details, it'll give you a sense as to why my perspective is what it is. So when I started out as a software developer, I came in with classroom code experience. That meant security was at top of mind, but I actually ended up on a security team building out what is known as a static analysis engine tool. That's not the topic for today, but it will become relevant as we talk through some of the issues and risks we see with building code faster with the use of AI. So with that little bit of knowledge, I'd also like to add that one of the reasons why I'm at GitHub is because I've seen the trends of technology and where developers like to live is specifically when it comes to flow state. When it comes to security, we found that there's silos. There's development team, there's security team, and, typically, there's hasn't been a great sort of bridge to connect both of those teams' priorities. And the topic that we're addressing specifically today has to do with secret leaks. What does that mean? Well, we know with the generation of more code and with the speed of code being deployed, things are getting missed, things are getting dismissed, and most importantly, things aren't getting fixed. So with that, I'll let Leo introduce himself, and then I'll talk a little bit about what you should expect to see going into this webinar. And then we'll open it up to a demo and some questions. But feel free to take a peek at the poll that we've put out just to kinda get a sense for every for where everyone thinks we stand on what we've seen in the industry. So, Leo, over to you. Hi, everybody. My name is Leo, and this is gonna be a short introduction. My name is Leonardo De Kembayo. I'm what's known as a field security specialist here at GitHub. So my role is to focus on GitHub advanced security and helping customers understand how that can bring value to their businesses. If I wanna go a little bit into my background, I graduated a degree in English with an emphasis in creative writing, and now I work in cybersecurity. There's a big story between now and then, but you don't have to worry about that. So let's go ahead and get started with all the other content, Lubita. Yes. Absolutely. Well, I think it's important to let people know where you're coming from, to see that journey of where you've landed, specifically where we see the overall trends of technology going. I myself was an electrical engineer, and here I am now working with computer scientists, engineers, c level executives to help them harden their security posture. So I think what we wanna start with is just I I wanna get a poll for how many secrets you think were leaked in public repositories over the last three hundred and sixty five days. So if you're online, if you could take a moment just to submit your answers. Wanna see where everyone stands. That way we can talk through where we are today, where we see things going, and then how GitHub specifically can help you with that journey. So we'll give everyone a couple of minutes. And as we go through that, just to kinda set the stage so everyone knows what to expect, what you'll walk away with. First, we're gonna start with the current state. Right? The number of secrets that we saw actually leaked, and and then we're gonna give you an understanding of how we help you prevent those secret leaks from the start. We say the cheapest flaw to fix is one that's never written. So we're gonna talk through what we do and how you can assess that exposure, how you can actually go in, remediate, and mitigate any sort of findings, and then overall, just like how you can get started if you've never used our product. It looks like we have the poll results here, Lupita. So how many secrets do you think were linked in the in public repositories over the last three hundred sixty five days? So about 9% saying 2,000,000. We have about 24% saying 7,400,000. 19 saying 12,000,000. And right now, the vast majority of people are saying 18 and a half million. That's a lot of secrets that are potentially out there, Lubita. I mean, 7,400,000, is that the right answer? That seems like an oddly specific number, doesn't it? Maybe it's at 12,000,000. What what are your thoughts? Where where do we stand on this? Well, my favorite number is 12, so I would have assumed that it was 12, but let's a good number. take a look. Let's first see where we were at last year versus this year. As we all know with the use of AI, more code means more risk, and more speed means more potential secrets leaked. So if we go back to our slide here, Oh, and with that, I will go ahead and, pop off. But if you all have questions, there is a q and a, place for you to submit those questions, and we can also answer those, asynchronously as well. So, I will see you all soon once we get to the demo portion. Awesome. Thank you, Leo. Yeah. So let's just start with what we've seen in terms of the growth. So if some of you said 2,000,000, if some of you said 7.4 or even 12 like I did, It's actually grown over 303%, which is crazy, but also not surprising. And so if we look at what the actual number of secrets leaked just in public repositories, it was actually 18,500,000, which is absurd, but also not surprising. And we're not just looking at the leaks within the code, but we also saw 423,000 423,000 in noncode items, so, like, documents and other sort of wikis, etcetera. So this is insane. And what does that mean for you all? Well, one of the things we talk about is when you're going through your flow state of creating your software, security isn't always top of mind. Hence, why I talked a little bit about my background and going in through learning how to write classroom code, but not enterprise grade security code. And with that, what we've aimed to do is to help users like you, whether you're a new software developer, experienced developer, and or security manager or c level executive. There are controls in place to help you prevent some of those secrets from ever being leaked by blocking them earlier on in the development process, what we call push protection. There's a lot of tools out there that will allow you to sort of run your own scripts, do some, I don't know, webhooks or whatever sort of hack jobs to get it done. But I always say it's better to kinda set it and forget it and not have to give that ownership to developers to ensure that they're doing their part in making sure some of those secrets don't get leaked. With that being said, I I think we still see, even though secrets are detected, there's not a whole lot of remediation that happens. They're still alive. So the that means secrets aren't being revoked. They're not being rotated. They're not being stored in key vaults, and that can possess a problem in itself. So what does that mean for you all? I think context matters. When a secret is identified, putting that ownership on the developer makes it a little bit tedious and sometimes complex for them to decide. Is this something I really need to fix? Is it just a test secret, or is it actually live? Is this something that could affect the organization? But because most developers are focused on their own KPIs, like making sure buttons work correctly or the experience is right for users. They don't always stop and think, like, this is something that's important to the business. So with extended metadata, we're seeing that it's a lot easier for developers to actually take action and know exactly what to do, when to do it, and how. That's where we come in. So if you've never heard of GitHub secret protection solution, I'm gonna give you a little bit of a high level overview on what it is, what we provide, and then in a few moments, Theo's actually gonna walk you through the platform, show you how to turn it on, use it, consume it, and take action on some of those findings. And then we're actually gonna give you a chance to turn it on yourselves if you have the right roles, of course. So let's start with what is GitHub secret protection. If you have heard of us in the past, it was actually called secret detection, but we've since changed that name because we really wanna show you that the approach is to be proactive, not reactive. We wanna take your experience from chaos to clarity. So beginning with a native experience of push protection. You might have caught that I said earlier on, folks might have had experience with other solutions where there is, like, a script running in the background or they've put in some blockers or white list, to make it easy for them to kinda go through that process, but not everyone has the experience to do so. So when you're using GitHub natively, we make it super simple where it's kind of like plug and play. You turn it on, and with push protection, what it does is it'll automatically detect if a secret is accidentally being committed. What that will do is it'll flag it, stop you with a big red banner, and say, hey. Is this something you really wanna do? And then from there, you can take that information and say, no. That was an accident. Let me go back and fix that. Or if there is, for whatever reason, a need to push that through, there is the opportunity for you to submit that, obviously, with a comment where someone can review and approve or reject that. Sorta that's the first kind of, like, big sort of value add I like to highlight within GitHub because not a lot of solutions out there provide that native experience. It really just helps any leaks from going through. As I said, cheapest flaw to fix is one that is never in, so we prevent you from the start. Above just prevention, we go into the comprehensive coverage. So we're not just looking for the text password within your code, which is what I've seen traditionally most solutions do. We go further than that. We look at not just within your GitHub environment. We're looking at issues, pull requests, wikis, discussions, and we also support a wide range of patterns. So not just looking at generic passwords, but provider specific, you know, tokens, keys, and so on. So what that means is we can actually validate and see, is this a real secret? Is this a real API key or token? And then from there, what it helps you do is detect items that you can actually go in and fix and remediate with more concrete confidence. And so with that, there's a little bit of an extra sort of layer of protection, which is the ability to even create your own custom secrets. So, like, if you're putting in, say, a string of characters that's just relevant to your organization, you're able to use AI to kinda create those queries and add an additional layer of security. So that high detection accuracy comes from being able to validate that those are real and true secrets that have been identified. They're not just in test mode. And then beyond that, it also allows you to prioritize what needs to be fixed first. So if you know this is an AWS, you know, token or key or or whatnot, or it could be Azure or it could be Datadog, you name it, because we have over 250 provider relationship, I wanna say partner programs, what we can do is automatically tell you this is valid. This needs to be fixed. Focus on these first. And my favorite piece of the puzzle is that there is enterprise grade policies. So this just helps everyone stay on the same page because it gives you strong confidence of making sure that there's governance in place and that there's policy driven enforcement. So when you have a secret and you wanna push it through and you're saying, I wanna bypass this policy, there's an audit trail. There's a history. We can go back and say, okay. We did our due diligence. We might have messed up. Here's how we fix it, or we blocked a lot of things that could have potentially impacted our brand, our reputation, and so on and so forth. So that being said, hopefully, this gives you some insight on, like, what GitHub protection actually gives you natively within that experience. And now to give you guys a little bit of insight on how it all works, gonna actually hand it over to Leo so you can see that. And after he's done, we're gonna come back, and I'm gonna show you how you can get started with it. So I'm gonna drop off. Leo, take it away. Excellent. Thank you, Lupita. And just for y'all's edification, I did put a link into our chat that contains all of our secret protection patterns that our product currently support. So, before or rather after this webinar or during, you all can take a look at that to see what sort of patterns we do support as in, like, what sort of features are also supported with that particular pattern. So if you all could please allow me to share my screen or share, some windows, that will be really helpful, because I'm getting a circle with a line across it whenever I try to hover over the screen. There we go. Thank you very much. And I'm going to so I'm gonna do a couple of things here. So first and foremost, what I want to do is I wanna showcase to you all what the experience looks like in the user interface. Then I'm gonna jump into my terminal, and I'm also gonna show you how push protection works from the perspective of a developer in this case. So first and foremost, there was a question that at least I wanted to to touch on earlier. This was a question on to what extent is AI contributing to the secret leaks in our AI tools the main cause? Or are there factors such as misconfigurations, accidental commits, and weak security controls? Which one of those are more significant? And I don't have any specific data on, you know, how many secret leaks are we seeing between humans and between agents. But for the most part, agents are going to be doing that less, depending on the type of model that you're using. And also you have to be very careful, like, what files or what information is being committed. But also another thing to consider is not all of the secrets that are identified within GitHub repositories are in the code base itself. They could also exist in discussions. They can also exist in issues. They can also be identified within a poor request comment, we use push protection, or rather we use secret protection to find those particular areas where those secrets might exist. And predominantly, those are all being done by humans, by people. And so for the most part, a lot of this stuff might happen accidentally, a lot of this stuff might happen because of there's a rush to get something done. And they don't have time or don't want to take the time to work with their secret management platforms, whatever that might be. So there's a couple of reasons why this does happen. It could just be carelessness. It could just be like, hey. It just happened. Yes. And also actions output as well. There's a question that jumped in there. We also look for secrets in GitHub actions output as well. That's something that we had just released very recently. But before I get too ahead of myself, I do want to show you all what the product looks like, what sort of results look like, and what are also included with some of these features, as well as what this experience looks like from a developer perspective in the terminal. So right now, I am in a demo organization here we call DSP testing. And in this environment, we have thousands of of repositories. And with those repositories, we have a lot of people contributing to those repositories as well. So with secret protection, what you're gonna see is once you turn that on, you're gonna look down here and see under secret scanning, there's sort of two designations. There's gonna be the default and there's going to be generic. Now, to be specific on what these things mean, default is going to refer to anything that is going to be a partnered pattern. So in that documentation I shared in the chat, that's going to show you all the different partners that we work with. And for a lot of these partners, as Lupita said earlier, like they're going to be part of a partner program, where we work with that partner to help identify or to define very specific things to make their secret tokens and access IDs and and whatnot to be very specific and easy to find. A lot of these will use custom algorithms to generate these particular findings. And so what we find is that whenever someone is trying to test out, hey. Let me just throw in, like, what maybe looks like an AWS access key, for example, and then secret protection doesn't pick it up. And they're like, why isn't this picking it up? It's like, well, that's not an actual AWS access key. That's just something that you did on your keyboard really quickly. It doesn't match the format or doesn't match, the output of that particular algorithm that AWS would use to generate that that particular key, for example. So we get down to that level to produce very high accuracy. And then for the other patterns, we'll use regular expressions to help identify those particular, bits and pieces as well in order for us to have a provide a very strong and low false positive result for developers. Because the thing is that if a developer is gonna be working inside of GitHub, we have to be very careful. Because if we're not, hey, guess what, they're not gonna wanna use it anymore. They're gonna complain about it. They're gonna wanna get turned off. They're not gonna use it if there's no value anymore. So we have to have this fine balance between, you know, adding enough friction that it helps change behaviors, like for push protection, for example, but also making it easy enough to use for security and developers to adopt and be like, okay. Like, this is a fair trade for us to be able to use. When we're talking about generic, this is going to be patterns that are either going to be identified using AI or they're gonna be patterns such as, h HTTP bearer tokens or PGP keys or GPG keys, RSA tokens, SSH keys, things that have a specific format, but they're not used for a particular purpose or with a service provider. Like an RSA token or rather an SSH key can be used to log in to different machines or to sign commits or to, gain access to something or to prove your identity or whatever it might be or to the identity of of whatever sort of thing that you're trying to access. So there's not a dedicated purpose for that particular key in the same way that an AWS access key will again give you access to AWS. So we call these more generic use cases. For the AI generated ones, if I click into this, what we're gonna see are things like password. So something like this, is a generic enough password that it doesn't necessarily follow a particular format. It doesn't have a particular purpose, or rather this pattern doesn't necessarily is used for a particular purpose in the same way that a provider would be. But it is a mess of different characters, upper or lowercase, special characters, numbers. So this makes it difficult for us to find via regular expressions on on on its own. So we're using AI to help identify these particular secret patterns and then report inside of GitHub. So that way people are able to know, like, oh, for these types of keys that or these types of tokens or passwords or what have you that are being used within my environment, I can still find them. And so that's something that we're, we've built and something that people can take advantage of. And you'll see here that we have, like, private keys and we have open SSH keys. You know, we're able to identify those and kinda showcase them to the user so that they know, hey. We found these. Something needs to be done about them. But let's actually dive into a particular alert and kind of take a look at what we can see in it, what sort of features are available with them, and, you know, hey, what can we do about them? And also you'll notice that we have some sort of, like, weird things here. I don't wanna say this is weird. This is just basically saying the Japanese language, but written in kanji, for example. Or you can see, like, enterprise testing, webhooks, something like that. These are what we call custom secrets. You do have the option as a user to create your own custom patterns, and you can also, test those custom patterns against your repositories or an entire organization to see how many hits you get to see how accurate that particular pattern that you've created. You can also use AI to generate that pattern. That's not something I'm probably gonna do in this particular webinar, but I can show you, like, where that is and what that looks like. So that way we can sort of, like, move forward quickly. But you do have the option of creating your own custom patterns. So what I wanna do is I'm gonna use some of these filters here. So for example, I want to look for a particular secret type. So I'm a look for my Figma personal access tokens. And so I can just click on that one, and it's gonna show me all of my Figma keys. And already at the top, I can see, two of them that are being prioritized here. So one of them, both of them are active. So with secret protection, what we can also do with some of our service providers is we can send that secret pattern or that token over to that pattern via a a secure API endpoint and basically ask them the question, is this an active key? Yes or no? If it is, they let us know, like, hey. This is an active key, so we'll go ahead and add the the pill here to say this is an active key. If it's not active, then we will tell you, hey. This is not an active key. But if they say, like, if they provide us with an an ambiguous answer or something that we just don't know, we'll say it's a possibly active key. We can't verify that it's active at this time, but it is possibly active, and so we still want to be able to prioritize that. Another bit here is called a public leak, and what this was referring to is that this secret pattern was found in a public repository owned by this particular enterprise. So within the enterprise, you have your public repositories, your internal repositories, and your private repositories. And that the amount of people that can see a public is everyone, the the amount of people that can see an internal is only gonna be people within the enterprise. And then the amount of people who can see the private repository are going to be the ones that are assigned to that repository, or have access to that repository. So the amount of, of users able to see it is gets extremely low. But if something is seen in a public repository, then we want to be able to call that out and say like, you know, hey, this plain text secret is now available for everyone to see in that environment. So let me dive into one of these, and so we can get an idea of, like, what other things we're able to see here. So first and foremost, what we can see here is that we found the secret about 27 ago. And we have what we call extended metadata included with the secret. So since we know that this is a publicly or rather this is an active secret, we were also able to get some metadata back from that provider, and we're showcasing that metadata here. And so as Lupita showed in her slides earlier, if you get this extended metadata, you're able to see the amount of of secrets being rotated and revoked and having these things be closed as revoked and rotated, at a higher percentage than if you don't have these particular this particular data. This information at least lets me know, hey. Who is the user? What is the email associated with that user? What is the ID? That allows me a very quick trip to that particular person to reach out and to be able to let them know, hey, we saw that this particular pattern, exists in this repository. We need you to revoke, rotate, as in revoke the token. Basically, that token is no longer valid. Rotate the token, create a new token with the same permissions, or depending on the situation, less permissions, if applicable, and then put that secret token in a secure place, like a secret vault, for example, depending on what the use case is, it is frowned upon to put plain text passwords in repositories because anybody can read them. Anybody potentially can access them, and anybody can potentially use them for their own purposes. And that is outside the control of the enterprise, of the owner, of anyone else. And so that is a huge concern because we don't know what they could potentially do with that information. And the more that we don't know, the less that we can secure. And that's a huge problem. You'll see on the news all of the time, that so and so had a secret leak. And that brought them to that provided access to somebody to gain access to infrastructure, to resources, to personnel, whatever it is, for them to be able to achieve some sort of nefarious goal, we want to be able to reduce that attack surface as much as possible. And so having that visibility on where those secrets are, whether or not they are active, as well as if they've been publicly leaked, these things are incredibly necessary for us to be able to narrow down that large backlog of secrets. So that way, we can start tackling these things and making sure that we have a a, a playbook as well as a secret store in order for us to deal with these types of situations. So right off the bat, I have some information that I can use to start that process of revoking, of rotating, and putting the secrets in a better place for us to be able to use for our purposes. Further along the line here, I can also assign people to these secret alerts. So by default, the security manager, which is a role within GitHub that allows a person to see security alerts across an organization or an enterprise if they're an enterprise security manager, and the repository owner, org admins, as well as the developer who contributed the code that contained the secret in it, they all have visibility on this alert. And so other developers don't have access to this alert. So that way, they don't necessarily see something calling directly to them saying like this secret is an active secret. Now, if you want to assign this particular alert to somebody who doesn't have visibility, when you assign them this when you assign them to the alert, they will have visibility to the alert. So be careful with that if that's something that you're going to do. Make sure you're assigning to somebody who will do something about this and who has the ability to, to do something about this. The extended metadata here can help with that process. Because if you know who that user is, then you can go ahead and target that person, not target that person, but, reach out to that person directly in order for them to, start the work on revoking and roaching that particular secret. We also have some general remediation steps for a lot of the secrets that we have. So people are if they're looking for something that they looking for at least the beginning of a playbook or looking for some steps to follow, they can follow at least these steps. And depending on what type of token, we also have links that can take you over to documentation on what these these particular tokens can do. And if you need to learn more about them, you have access to that just in time. Another thing that we're doing here is on the right side here, you can see that this particular pattern right over here was found in other alerts as well. It's not just the one alert here. We can see the relationship that this pattern has been seen in other places too. That's where this multi repository pill is coming from. And then I can also see where this particular secret pattern was found in other repositories that are public. So this is key for you to know to sort of, like, see what that blast radius looks like or how quickly a particular key can be, propagated across multiple places. So again, to help sort of foster that urgency around dealing with these tokens, we have to be very careful about that. You'll also see this big old button here that says verify the secret. So for partner patterns, that button will exist. And when you click on it, it's gonna go reach out to the the provider and say like, hey, is this an active secret? Yes or no. And then we'll get a response. I did this yesterday, and this is still an active secret. However, if you are trying to use this to get access to anything, unfortunately, this is just a test secret. There's not really anything that you can do with this. So I know, sort of the irony is that I'm talking about a secret protection product. And I am exposing secrets publicly in front of however many people who are here. And I don't know what all these people are going to be doing with this. So if you're trying to do bad things, please stop, rethink your your life choices, and just do the right thing. Alright. So let's say, for example, we did do something with this particular secret. So when we wanna close it, we have a couple of options. You know, we can revoke the secret, we can say, hey, this use the secret is being used in tests and is not production code. And so that while it may not be something that is viable or allowable within an environment, and depends on your organization, your organization's policies. But sometimes, like, this is just a test secret. This is not something that's connected to anything in production. We're just using it for very limited purposes. Then the security team can review this and say, yes, okay, that makes sense or no, like, please do deal with this as you would any other secret. Sometimes, though, we can say, like, you know, hey, this is not an invalid alert. So we're gonna say like, this is a false positive, or say, you know what, this is not a relevant alert, and I want to click on won't fix. And then I can add a comment here to say why this is happening. So as a security team, if I see a bunch of developers, you know, closing secret alerts to say, like, won't fix, won't fix, won't fix, I'm gonna get pretty frustrated because these developers are not helping with business continuity, they are potentially adding in unnecessary risk to our environment. And so we have this other feature that allows you to prevent developers from just click and try and close alerts. That's what we call delegated alert dismissal. And so essentially, the flow is when someone when a developer wants to close a particular alert, it's going to have a button that says request to close the alert. And then that will send an alert to a security person, whoever's on the list to approve. And then what they can do is they can say, hey, you know what, after reviewing this, we agree this is a false positive, or, hey, we agree this is being used in tests. Let's go ahead and close this or we have confirmed that this particular alert has been revoked or that the secret has been revoked, we can go ahead and close that alert. Once an alert is closed or approved by a security person to be closed, what we're gonna see at the bottom here is part of the audit log. So the alert will stay in existence, and you will see what types of actions have take have been taken on this particular alert. So for example, if I were to close this and say, hey, this is used in tests, Minimal access not used for production. Something like that. I can go ahead and click on close alert, And we can see alert close with an active secret or revoke it. That's fine. But I can see here that I go I went ahead and I closed the alert and say it was used in tests. Minimal access not used for production. If I want to reopen the alert and say, oops, my bad, it will go ahead and open it. And it'll also show that, hey, that I had reopened this alert with that particular comment. So as a security team, I'm gonna be able to view that audit log to see what sort of things are happening. And these types of audits are also being streamed to our audit log. So if you have some sort of, SIM or SIEM, or if you have some sort of log aggregator and you are consuming all of the audit logs coming from GitHub, and you have an alert that states, if there's a change in a particular any particular alert, or you have web hooks set up with GitHub. And so anytime there's a new alert, you're able to log those and keep them in And so anytime there's a new alert, you're able to log those and and keep them in in place. You have access to these types of logs outside of the GitHub platform as well. So it's not all just localized here. We are extensible in that way. Now that's, when I come back here, it's taking me to the repository and not to that that larger view, but you can see, like, we have a lot of public leaks here. I'm just gonna take a minute just to kind of look at a generic AI detected password. And so when we're identifying these, obviously, hey, there's not really anything that we can validate this particular alert to. Since we don't know what this is associated with, we don't know, how this is potentially going to be used. We don't have a mechanism to verify against that particular API endpoint, for example. But we do say like, you know, hey, this was detected by AI. And then we have some documentation explained to you further like what that means and how we did it. But you'll see here that within the code base, we see exactly where that particular secret, might be or that in in this case, a password might be. And you'll notice that there's other things here too, but this alert is focused on that particular password and not these other ones. So we are grouping the alerts by the actual value of the secret as opposed to the type of the secret. And same things here. I can go ahead and close the alert, and I can say, hey, I want to say it's revoked, using test, false positive, won't fix, what have you. I can do things there as well as assign people to the alerts as well. So that's gonna be secret alerts sort of in a nutshell. So we're able to identify partner patterns. We're able to identify, more generic type secrets as well as non provider secrets such as, you know, SSH keys, RSA tokens, HTTP bearer tokens, etcetera, all within that documentation I shared in the chat earlier. Now what if, for example, I have an issue and I have a lot of people working in my environment, and they are all, you know, associated they all have emails associated with particular domains. And I wanna know if they're doing something out outside of my enterprise, if potentially they are leaking secrets outside of the the boundaries of my control being my enterprise. And this is where this brand new public monitoring feature comes into play. So essentially, what we're doing is we're saying, hey, we are seeing in this environment, there is a lot of activity from our users within our environment, we have seven verified domains, And a verified domain is essentially a domain for an email address that is show associated with our enterprise. So if I click on this little eye, you can see there's gradeschooldropout.com, jeff, jeff,ahefeish.org, patterson.io, etcetera. There's other ones that are there. But anybody that has, you know, whatever at gradeschooldropout.com, for example, that's going to be somebody that is associated with this enterprise. And so if we see that they are leaking secrets outside of our enterprise, we wanna call attention to that here. So I'm gonna go ahead and click on this particular alert here. And what I can see is that, hey, we have some member activity from this particular user at github.com, and they've shared this Salesforce o auth two consumer secret in a public repository outside of our enterprise. So what does a person do with something like that? So first and foremost, you need to figure out, hey, is this secret relevant to our enterprise? Once you figure that out, is it active or in use, or rather and in use? And if so, we need to revoke that secret and rotate it and do something with and and, so that way, if anybody gets access to that repository outside of our control, that's something that they no longer can do anything with. So essentially, we're cutting off that secret, you're cut off, you're out, get out. Next, we need to see what is the exposed surface and relevant security logs for that particular secret. So obviously, whoever used that particular secret to gain access to our Salesforce environment, we want to be able to know what that looks like. So looking at audit logs, and looking in security logs within Salesforce for us to know what that sort of blast radius is. And then, obviously, we wanna make sure that we educate that particular developer on best on handling secrets more securely in the future. So that way, this doesn't continue with that particular developer. A lot of this stuff is sort of just in time enablement, but it's also really critical skills for moving forward when working in a public space such as GitHub outside of my enterprise, for example. Okay. So there's a lot to to sort of, like, dive in and sort of, what's the word, talk about when it comes to public monitoring. But there's one last thing I wanna talk about. And so we've talked about secrets existing within my repositories, but what about preventing new secrets from being added into my repositories? And that's where push protection comes in. So what I wanna do is I'm just gonna go ahead and switch over to my other window here so we can showcase what that looks like from a developer perspective. So let me do that relatively quickly. And so right now I'm in my terminal and I have a Go file here that I want to go ahead and edit. So I'm gonna go ahead and go into this file, and all I'm really gonna do here is I'm going to add in a particular secret token. So I'm gonna go ahead and get to here. I'm gonna create new line, and I'm just gonna say token, and I'm gonna paste in the token that I have here. So now what I wanna do is I'm going to add that file. I'm going to commit it. Great feature. Incoming. And now what I wanna do is I'm going to push this. So I'm gonna do git push to my origin, and then my branch in this case is called report improvement. And so what I should see is this bad boy right here, GitHub push protection. So it identified in that file that I have an anthropic API key and on what commit and on what path and on what line in that path in that file, where that key exists. And it's basically telling me, hey, you cannot push this because we have push protection enabled on this repository. And we identified at this as a secret, and we're not allowing us to get in there. Right now, this is supported for a lot of our, partner, secrets. In that documentation I shared earlier, it'll also have a column that shows you which ones are default for push protection. But you also have the ability to edit which, patterns are push protected and which ones are not. So you have that flexibility to say, GitHub by default doesn't push protection push protect this pattern, but I want this pattern to be push protected. And push protection works for custom secrets as well. We have a lot more in store for secret protection in the coming days and weeks and months. So please be sure to be on the lookout for all the things that we have, that are coming out. We have some really interesting things that we're doing with AI as well and AI plus push protection, so please be on the lookout for that. So I am at a good stopping point for here. What I'd love to do is bring Lupita back on so that way we can answer some questions live. Awesome job, Leo. Thank you so much for doing that. And thank you all for putting in all your questions. I was trying to keep up. And there was a couple that were very similar to each other, so I did leave some open so that we could have Leo dig in just to kinda give you a sense for what sort of the best approach is. Let's go ahead and start with one that came up as sort of a feature request. Say they have 500 alerts, and let's say they want to have a button that closes all the alerts. Now I know, from experience, just going in and and bulk dismissing isn't always the best approach. It's always good to kinda go through and validate that they aren't actually a risk. But, Leo, tell us tell us more about what you think about this one and what you would provide as a suggestion for them. I think shutting down a bunch of secret alerts all at once is potentially a bad idea because I don't know how you decided on those 500 alerts, for example. So let's say let's assume that you've gone through all 500. In that event, use the API to close those individually, or rather to to close those en masse without having to go into the user interface to do that. But if you haven't reviewed those 500 alerts, my recommendation is to use what we call a, security campaign to make sure people can actually review those alerts and do something about them. So we came up with security campaigns, last year, and that was mostly focused on code security alerts and using AI to, remediate those particular alerts. With secret protection, there's not really a way for us right now to use AI to remediate these secrets, because there's a lot of human step processes that need to happen such as revoking, rotating, understand that the blast radius, and putting those secrets in a in a place that, like a a vault or store or something like that, a secure place. But we still want these alerts to have something be done to them. We want them to be taken care of. And so creating a security campaign focused on a particular secret type, or focused on a set of alerts within your critical repositories, keeping it the scope low or small, so it's doable. And it's something that developers can do within a sprint or within a, you know, short period of time. And that way, as a security manager, I can also see the progress of the alerts in that campaign. And so that's how is it I would deal with that particular scale problem. You know, I have hundreds of alerts. Well, how do you eat any sort of elephant? Well, you have to, you know, one bite at a time. That's how you would wanna deal with secret protection. I would love to say just throw Copilot at it, and it's going to solve all your problems. That's not something I would do right now because secrets have a very one secret can bring it an organization down to its knees. And so we have to be very careful on how we, deal with these types of alerts and when we deal with these alerts as well. Yeah. And I saw that one come up a couple of times in in different ways. So I'm glad we were we were able to touch on that with a little bit more clarity. There's also some questions regarding how you can get started with this, and I'd love to kinda showcase what that looks like. But in terms of licensing and cost, what I would recommend is you to reach out to your account managers. We have made it super simple for you to leverage code security and secret protection as two distinct sort of pools, Depending on how your organization is working with us, there are some different options on what it would look like from a licensing perspective. So definitely as an action item, follow-up with your AEs, and they can help kind of clarify what that cost will look like. That being said, I know there's a ton of other questions, so I'm kinda trying to sift through these to see which one There is a question I do wanna answer. helpful. Perfect. Go ahead, Leo. How does the pricing look like? It looks like some numbers. There's also another question on, the link in the push protection alert. The push protection alerts, it'll have a link there, and it'll say to if you want to, bypass this push protection, click on this link, and then you can go ahead and, commit your code and push it and then that secret pattern will be added to the repository. It will create a secret alert. So there still will be an alert even if you bypass push protection. But as a as a security minded person, what I would always recommend is don't let your developers push or rather bypass themselves. What we do, we have this feature is called delegated by a delegated bypass, This essentially is, I'm a developer, and I want to push this commit, and this commit has been push protected. But I need this in the code base because we have a release coming up, and we need to get this work done. I can request that this push protection alert get bypassed, and that can be, agreed on by somebody else, somebody else can, agree on that bypass. Once it's agreed upon, then I can go ahead and push the the commit. But then pushing the commit will again, create that alert and let us know like, you know, hey, you have an anthropic key in your repository in plain text. But at least I had somebody else make that decision, as opposed to one person or many developers making that decision on on their own. So it's a way to help limit the amount of bypasses we're seeing in having somebody who's approved to make those decisions make those decisions. Let's see. There's another question on if a secret is detected, who detected it? How does the detector clean the secret, let's see, from its memory? So here's the thing. When you post something on the Internet, it doesn't go away, ever. And so there's a bunch of crawlers all over the Internet right now going through hundreds of thousands of repositories a day, maybe more. And they're looking for secrets to be able to use or to collect them and to use them for whatever purposes they want to use them for, to sell them, to to use them, to get access to something, or to, you know, perform additional reconnaissance before they do some sort of attack, whatever that might be. Now we do not recommend people clean their secrets from the repositories because you are messing with the Git history. And when you mess with the Git history, you are messing with the Git history of everyone who has ever used that code or edited that code or cloned that code, used Git with that code. It becomes a gigantic mess. So what we recommend is instead of, you know, removing the secret and then adding a commit without that secret there, the secret still exists in the Git history. History. There was a point in time when that secret was added to the repositories, and that point in time is locked in with Git. You can use tools to edit that Git history, but again, it creates a lot of problems and a lot of friction for developers. So instead, leave it there. Leave it in the git history, revoke, rotate it, use it in a more secure way, and then update the code to use that secret in the more secure way. So it's referencing what what that secret would be as a variable when it gets pulled in at runtime, for example, versus having it plain text in the code base itself. So, again, don't mess with the Git history because you're messing with everybody's Git history since Git is, what's the word of, distributed. It just make it just makes things so much harder than it needs to be. I do not recommend cleaning out your Git history. Let's see. What other questions can we answer live? Let's see. Is GitHub Advanced Security already included in our organization's plan, or is it separate? It is an add on, that you would need to purchase, but definitely talk to your account team about GitHub Advanced Security and see if it's right for you. Also, consult your doctor. Let's see. Are there any plans to add AI powered blast radius analysis that automatically shows the business impact and attack paths of a leaked secret rather than only detecting the secret itself? That is an interesting idea, and that would also mean providing AI with a lot of other points of information. I don't know if that's something that we can productize today, but it's something that we can talk to our product team to see, like, you know, hey, is there any sort of, like, blast radius analysis that we could potentially provide to our customers? That all depends. But there's a lot of data points that we would need to make it an accurate telling of what that might look like. And I think for now, having human providing the analysis through humans or human analysis, or I don't know, sorry, as a member of the lizard race, I'm not really sure how best to approach you humans these days. But, that's a joke, by the way. It is, it still needs to be done be led by people. People have to lead that in sort of analysis. They're gonna have the access. They're gonna know who to talk to or find out who they can talk to in order to perform that analysis. This isn't something that you can just do overnight. It takes time. Let's see. Absolutely. I see. Are there any plans to add any more Azure integrations into secret validity to eliminate some of the manual work? I think that just kinda goes back to what you were saying, Leo. So as we're building out those those partner programs, it comes based on demand and need. So if there is anything specific that you don't see on the list, please reach out to your AEs. We're always taking back that feedback, to increase our coverage. Though I know, obviously, because we are owned by Microsoft that Azure has taken lead, so I'd be curious to know what specifically you're looking for. Yeah. We think you have advanced security. Something that we announced at I believe it was billed earlier this year. The Microsoft Defender for Cloud or rather the advanced security integration with Microsoft Defender for Cloud and being able to pull in advanced security results from your repositories over to that cloud context and be able to see, you know, if a particular dependent bot alert or a particular code scanning alert or code security alert, you know, exists in a container or within a part of your infrastructure for your application. It's a pretty cool capability, but you'd have to have a Microsoft Defender for Cloud to make that work. Let's see. I see GitHub go ahead. go ahead, ahead. Lupita. No. No. Please. You. No. I was just gonna say, I see a lot of would GitHub consider doing x, y, and z in in some of the questions here. And just for the sake of time, I would love, to kinda continue that conversation for anyone who has any feature requests or, you know, kinda wants to get an idea of what the road map looks like. We could definitely take back that information to kinda set up maybe a further discussion, just being that this was sort of a high level where we are today, what we're seeing in the market, and how we can help, that could certainly be something that we can table for for next session. Let's, see. Leo, I'll let you pick another one. Yeah. Let's see. The best path or resource to follow for a very fresh startup. There's actually a really cool resource called the GitHub well architect well architected framework. I believe you can find it just by googling well architected framework GitHub, or binging, I should say. If you can binging more, that would be great. But there I think it's like wellarchitected.github.com is also something you can reach directly. But that gives you a framework of what you can, how you should be building out and running your GitHub enterprise in the most scalable, and secure way possible. I would definitely go ahead and and use that resource. That's a resource that was put together by our customer outcomes team, and they are a very bright bunch. And it's something I refer to quite often, especially for anybody asking. Because what we find a lot in the enterprise and if you're a fresh start up, hey. Awesome. Like, tons of potential there. If you do things right inside of Git, you have less problems to worry about later on down the road. But we've seen enterprises that have thousands of organizations, and they're like, how do we manage this? It's like, well, we have less organizations, like, but we have like thousands and thousands of repositories per organization. I'm like, okay, this is gonna be a project. So let's let's bite down and kind of work through this. But if you can start out with a well architected GitHub environment and you maintain that in time moving forward, you're gonna have a pretty good a pretty good time there. And just for the sake of time, I know there's a lot of questions on kinda how to get started and and what folks can do. So one of the action items that we all have for you today is to take the risk assessment. This is free of charge. It's a click of a button. If you do have the security manager role or the org admin role, you should be able to see this button. And what it's going to do is show you, at a high level, an overview of any secrets that have been detected within your repository. If you can see the button, I recommend you bookmark it and just take a look and or find someone within your organization that can run this. Again, it's free of charge, and it just gives you a snapshot. Doesn't tell you the line, the source, where it is, how to fix it. For that, you will need to turn it on from a licensing perspective. But at least it gives you kind of like a scorecard so you can see where you stand today. So that will be the big takeaway for you all. Again, there's a lot of questions still in the q and a, which I absolutely love. So what we're planning to do is in a follow-up email with the recording, provide you access or a place to incorporate some of those questions so that we can continue the conversation. But I absolutely love the engagement. I think this is awesome. This is probably the first webinar that Leo and I have done where there's probably more questions that we've ever seen. So this is awesome. Thank you all. Thank you all so much for your, your questions, your time, and your and just being here. It's you could have been anywhere else in the entire world, and you chose to be here with us. So thank you very much for doing that. I just wanna double check. I just wanted to double check on the time. Oh, the the event's over. Okay. Yeah. Let's let's leave the stage. Exit right Alright.