you want to participate jump on over into um our other our other channels looks like everything's uh everything's going all good everyone's letting me know they can hear me so that is good well everyone we have a great topic and i'm i'm pretty excited about this i'll explain why in a minute but uh i have already introduced our guest cj may and we're gonna be talking about uh securing our github actions uh and workflows keeping them secure which isn't a topic that we've covered on the webinar before but we do have a blog post uh about this and uh we're gonna be coming some really really interesting uh interesting stuff with cj on this so a little bit about how today's gonna go if it's your first time at the at one of the get guardian webinars welcome welcome to to the show so we'll do a little bit of an intro where we'll explain um some of the some of the things that will happen we're going to talk about what our github actions very quickly then we're going to dive straight into some of the best practices and then this is why i'm so excited uh we have a live demo um of some injection with github action so cj not me i'm not clever enough but cj is going to show us um how we can how we can use some of these best practices or the reverse of them you know how we can actually use some techniques to in and to turn github actions malicious to actually do bad things so we're going to show that live so that's going to be really cool really interesting and then we have our wrap up at the end and some some q a's so you guys will all have an opportunity uh to participate to say hi so if you're in the the crowdcast platform you'll notice down the bottom you obviously probably can see the chat function but there's also a poll button we do have a we only have one poll today but still there um and there's also a button that says ask a question so if you want to ask a question to cj um or myself but probably cj then you can do that in the ask a question tab and you can actually upvote everyone's questions so if you there's a particularly good question that you you definitely want answered then make sure you upload those questions that way we'll definitely be able to see it we had uh over 500 people register for this webinar um so there may be quite a lot of activity in here or at least i hope so surprises as always we have some prizes now we've had some logistical challenges with our swag bag so we do have swag bags available we also have amazon gift cards um so we we will be giving away uh some prizes that depending on where you live will depend on what price you get or if you particularly want one i'll accommodate that so how do you win prizes well uh lots of ways you can win prizes by participating by asking questions by saying hi in the chat a lot or commenting on things all of that gets up i have a magic button at the bottom where i will generate a list of who are our most active people on the webinar at which point you will win some prizes and also have some other ways to win prizes uh along the way so uh first of all while we're still waiting for a few people to join let us know where you're tuning in from so i'll start i'm actually not in paris today i'm in prague in czech republic i'm speaking at the cubit conference here which is pretty cool but that's why i'm in my hotel room uh today so not very inspired backdrop but but it does the trick cj where about you tuning in from yeah i'm from pella iowa which is in the united states it's a smallish town of about 10 000 people ah very cool all right so we have some here uh toronto russia miami amsterdam from amsterdam brazil france malaysia italy armenia lagos morocco wow i love seeing all these these countries come in new york city i'm going to be in new york city next week for data connectors conference so if anyone's going to the data connectors conference in new york you'll see me there or if you're going to the b sides or rsa conference in san francisco i will also be there i think it's in two weeks i'm not sure but if you are uh in rsa or san francisco and you want to meet up i'm doing some some talks there uh we have a booth but uh this way you can just find me on uh on twitter or linkedin send me a message and come say hi lots of cool places still coming in ghana kenya ukraine bulgaria mexico wow we got a couple of people from ukraine oh this is great all right let's get stuck into it so let's out we have our first poll of the day so you know where are you currently at with github actions are you new to it do you have any idea what it is what what it is um are you starting to use some basic actions do you use github actions as part of your organizations are you a github actions power user um they're going going through that and i i don't i don't have the option here but you know github actions is obviously only on github the equivalent on git lab is uh your pipeline so if you are a gitlab user there is a cheeky button for you to but we're going to be talking about github actions today um now one last thing before we get in i have a quick story today we're uh currently looking for some stories uh about leaked credentials now it's a little bit uh it's not it's not entirely what we're going to be talking about today but get guardian as you probably know is a company that detects credentials that are that are leaked in different places and there's some pretty hilarious stories out there of how these are leaked so you can do this anonymously but we are looking for the best stories of how you've leaked a credential or when one has been exposed and if you share your story with it you can share it with me on twitter on linkedin you can email me my email's down at the bottom of the of the screen there um or you can send it to guardian if you do this then there might be some prizes coming your way so before we get stuck in i have one funny story uh that i would like to share with everyone it takes exactly one minute and 30 seconds so i'm going to quickly uh introduce this story in here and um then we're going to get stuck into some github action so remember if you want to win some prizes make sure you share your stories with us about how you have accidentally licked a credential in the past i'll share one with you right now hello i'm the happy father of a little girl of three years old so three years ago my daughter my my wife was pregnant and i was working from home close to her she was due really soon we didn't really know when but i was walking and i was looking for golia on my computer at that time and i needed to upload a bunch of images to s3 and so i had been given a credential key to upload my stuff on s3 for the test and while i was writing my code i realized like it was time to go to the hospital my wife was about to give birth so we went there spent one week completely disconnected from work came back home one week later with the laptop still open i just saved my work commit push and moved on to other things what happened is actually i pushed the key because it was written i just copy pasted it in a file somewhere i pushed it to github and it was caught by git quad pretty quickly that sent a notification to the security team at algolia and turned out that this key was actually more right than necessary it was not just to approach stuff 2s3 and so while i was uh quietly on my paternity leave taking care of my wife and daughter it was like the chaos at algolia because we just licked a very important key and thanks to git guardian we managed to they managed to know that pretty quickly and change all the keys everywhere and i knew that only when i came back from my pattern that you leave like i saw all the slack messages like uh crisis crisis there's a big problem i was like okay thank you good guardian you saved my ass that's my favorite story pushing a key your wife goes into labor and then when you come back from your opportunity if you found out that you've pushed some production credentials anyway so share those stories with with us if you have them but we are going to get stuck in to the the subject at ham which is github action so let's start i just had a look in the poll so most people uh are fairly new to github actions but they know what it is and they they know they um you know and they'd be working with some basic actions we have a couple of power users we have a couple of github gitlab for life people and um um you know and we have a couple of people that uh have uh just learning in it so most of you are kind of starting in that so cj maybe you can explain a little bit what i get to have actions why do we use them yeah so um github actions are an offering that github has that basically enable you to run automations on your code so let's say that you push an update to your code it can do things like kicking off automated tests or doing some security scanning of your code kind of like get guardian does where you might be looking for secrets that you might have accidentally committed to your code so um yeah github actions are just kind of a way to uh automate different checks and and and stuff like that yeah okay cool so uh a way that we can kind of integrate it with that ci cds environments that automated check and automation scanning so an important part of modern modern modern development if we have some maturity then we're going to be using some kind of of actions or pipelines so it's really important that we understand how to secure these so uh i'm not we've got a lot of content so i'm not going to muck around uh we're not going to muck around here today we're going to list some of the best practices of how we can keep our actions secure we're going to go through them one by one and then cj is going to demonstrate what happens if you don't follow these so let's start with the first one that we have set minimum scope for credentials um what what crop credentials are we talking about in in this case with github actions and you know how and how does this kind of uh keep us safe and what are the consequences if we don't do this yeah so the um when we talk about credentials and github actions usually we're talking about you know uh api keys or a github token so api keys typically you can configure the permissions for that on the platform that the api key is for with github tokens it's a little bit different so by default the github token that runs in your actions has read and write access to whatever repository it's running in the context of and so um but there is a way for you to change that in your repository settings and so you can either change that to read from read write to read only and if you want to get more granular than that you can create a personal access token that's part of your account settings you can create a personal access token that really gets nitty gritty with the permissions that that token has and then you can add that as a secret in your repository and use that token right okay so we can we so if we don't have minimum scopes for for for these credentials um and they do get it and they do they do potentially get exposed then then basically and someone that is able to exploit them is able to do a whole bunch more damage move laterally into different areas exactly okay so let's let's let's get a little bit more kind of in detail into some of the github actions uh specificities so we have here best practice number two use specific action version tags so firstly what what is an action version tag and what are the advantages of using a specific a specific tag yeah so when you use a github action in your workflows you're basically running some code that somebody else has out there and this is in a public repository so you could go search for that on github and see exactly what it's doing under the hood but basically these tags that you see um on the line where it says uses actions checkout at v3 at v3 is referring to a specific version of that uh of that action and basically um there is a little bit of inherent danger there because you're running somebody else's code and unless you are you know constantly vetting updates to that tag because you know it can be re-pushed or re-tagged on a newer version unless you're constantly vetting those updates you don't necessarily know exactly what code is running in your workflow and so kind of a way to protect yourself against that is to maybe vet a specific version of that code and then you can instead of referencing the tag you can actually reference the commit hash so it's actually a very specific version that you know is harder even impossible to spoof because you can't just you know re-tag v3 um if you look at the second picture there we've got uh we're logging into the docker container registry and we're using a very specific version of that action so that you know if let's say that for some reason that action that repo got taken over and uh some malicious actor was modifying what that action was doing and maybe stealing your docker credentials um by referencing that specific commit hash we're kind of protecting ourselves from those updates that might happen down the line right yeah you know and an interesting one on this one it was a code called breach of last year because code cov was being used in github actions the the app the action itself was turned malicious so attackers were able to edit kodkov's code um and if you ran that wild code that malicious version then the attack has actually got access to your github repository it's a you know but but that could have been avoided right if we had used a specific version of codecov that we knew was clean that we we didn't then we we we could have um we could have prevented from from from from having that malicious uh threat that's a great example all right number three my favorite one my favorite one don't use blade tech secrets so uh uh we don't need to talk about my have you seen any any any webinars ever this comes up at least once um you know so don't do sk so why but let's human be here cj why shouldn't we use plain text secrets and how do we not use plain text secrets so yeah i mean obviously if you have plain text secrets in your code and it's an open source repository anybody can see that so you know as soon as you commit it there's probably you know bots and researchers and all sorts of people that are scanning github constantly to try to find stuff like this and so it doesn't take long for something to get discovered if you accidentally commit like an api key or something like that so you know whether it's in your code or it's in your actual github actions workflow file there's just no place for plain text secrets in any sort of file that you're hosting on github got it okay so i can't spell this out for don't use plaintext secrets all right now let's get into one now this one's actually a little bit this one has a little bit more complexity to it and um i believe this is kind of around um one of the demos that you might be doing later on cj if i'm not mistaken okay so here we go saying don't reference values that you don't control okay so what what are the values that we don't control and and and how do we not reference them so when you are setting up a github actions workflow there's certain built-in variables that github allows you to use in the example that we have here on the screen this one is printing out the pull request title and then it's running commit lint on that and so what's actually happening is it's grabbing the pull request title but if you think about that that's not something that you control as the repository owner that's something that whoever is creating that pull request they can make that title whatever they want so let's say that i opened a pull request to this repository and i named my pull request uh that line there where it's you know downloading some malware and then executing it then what actually happens is when that gets evaluated during the github actions workflow execution that'll actually inject that variable onto the command line and it'll run as shown in that second image there at the bottom right okay so by changing the pull request uh title you you can actually exit you could execute commands you can you could run a remote script somewhere yeah and it's not just the pull request title there's other variables like issue title um there's a lot of built-in variables that github offers you to use but if you're using built-in github variables just make sure that you understand whether or not you control that that input that you're using that's in that variable okay so we have yeah we have some more we have some more kind of examples of this um so um using using an action instead of an inline script so so what's what's the difference between between here and how does that kind of solve some of this problem so before on the last page what we were doing was we were actually using that variable directly on the command line because we had you know our run our run tag in our yaml file and then we were have we had that unsanitized input directly on the command line so basically what these two fixes are doing is it's kind of redirecting that input or kind of adding a a little bit of a second layer to kind of sanitize that or de-weaponize it i guess is probably a better term for it and so yeah that first one where we're not actually using a command line we're using an action instead so here we're using some fake action where we're checking the title and then we're just inputting that variable as a parameter to that action and then another way that you can de-weaponize unsanitized input is if you have to use it on the command line what you can actually do is you can create an environment variable in your action for that step like we see below on that second image and basically you create the environment variable and then you actually just reference the environment variable instead of the github the github variable itself right okay okay so we're basically taking things that we have no control over and then you know we're not using them where possible and then we're adding in added loads of protection that prevent someone from being able to overtake that okay i'm really excited to see the demo that uh that you have of this uh cj because uh yeah yes we're gonna talk about all these things but uh uh we we are also gonna cj i i say we because it makes me feel better but uh cj is going to demonstrate how you know how how these actually work in practice in a live demo um because what goes wrong when you do live demos so let's talk about let's move on number five okay only run workflows uh on trusted code so so what what are we talking about here when we're when we're when we're using talking about trusted code and running workflows with it yeah so this is one where you know we're kind of talking about um when you set up your workflow you kind of have to understand what code is going to be running in your workflow so if you have um if you have a workflow that's kicking off automated tests for um if you have a workflow that's kicking off automated tests for the code that's being in you know trying to merge in the pull request those tests are technically actually executing that code and so if you you kind of have to be careful about what is executing and then you also have to take into context where it's going to be executing so one thing to think about is you might have self-hosted runners rather than github's you know ephemeral ubuntu runners that are actually executing these workflows and if you have somebody else's pull request code um executing in your your github runner then basically it's kind of opening that up for remote code execution and so it's important to make sure that before you kick off these automated tests or these other workflows for a pull request that you've actually taken a look at the code that's going to run and make sure that you understand you know that this author didn't try to inject something malicious just to get it to run in your workflow right got it i understand all right so we're starting to get get near the end of this but we have a couple more to go through so harden your action runners okay so what you know what what is an action runner and um and we have here a reminder that we shouldn't use action runners in public repositories so let's let's talk about that for for a minute yeah so i kind of just alluded to that just a little bit ago but basically a github runner is basically the server or container that is running your github workflow so that's actually where these automations are actually happening and so you can set up these self-hosted runners in github so that all of your workflows run on a server that you control rather than an ephemeral github runner and so luckily github actually has protections and doesn't allow most accounts to use self-hosted runners on public repositories and the reason that's dangerous is kind of what i was just talking about where if somebody else opens up a pull request and is you know executing their code on your github runner that is potentially you know introducing malicious code into your environment on your server that you control and so for that reason if you do host self-hosted runners because this is allowed in github organizations you need to make sure that you have protections in place and monitoring so that if something bad does happen you take notice right away and can put a stop to it if we uh if we want to think about a real world example we can look back at the solarwinds incident where um you know the build server of the orion platform was compromised and by compromising that build server which is you know kind of like a github runner whereas you know they're kicking off those automated builds since they were able to compromise that server they were able to inject malicious code into the orion platform as it was being built and so that's kind of an example of why you need to make sure that you protect your your action runners right okay okay i got it so let's let's let's move on to uh being careful with with the pull request target trigger so uh what's the pull request target trigger and uh and why we need to be careful yeah so this one um this one's kind of subtle at first but basically github actions in the workflow files there they have these different triggers that will kick off actions so if it's a you know a push to the repository or it's a pull request or maybe an issue opens these are all different triggers that can kick off workflows and a pull request target trigger is actually one of two different pull request triggers so we have pull request which is just one of those and then pull request target and the difference between those two is what context the workflow is running in so when we have a pull request we have two different uh we have two different repositories we have the repository of the contributor so let's say that i i own that mackenzie owns a repository and i'm trying to create a pull request to his repository so we have my repository which is the contributor and we have his repository which is the target so pull request target runs in the context of the target repository so where you're trying to push code to um that's the context that the all these actions are running in and that can get dangerous when you're running untrusted code inside of that pull request because what's all included in that in that you know repository context is say our github token so like we talked about earlier by default the token has read and write access and so it enables things like code injection into the repository um just by creating a pull request and uh if it's confusing now i'll be giving a demo on that here in a little bit and basically showing you exactly what's possible here okay awesome i can't wait for the demo all right so we have an example uh of this and you said you were doing here could you just do a little run-through about you know what what we're seeing here why is this example um of a vulnerability yeah so basically here we have a scenario where we have a pull request workflow that's kicking off and basically it's setting up some python dependencies and uh and then it's running some command and let's just pretend that some command is kicking off pi test or you know some sort of testing for the code that's being committed so what's happening here you see you look at the trigger up at the top where it says on pull request target so like i said earlier that's running in the context of the host repository so the place where the code is trying to merge into that's the context that we're running in for this check so as we look down at the steps of the workflow if you look at the checkout action that first step there so we're using actions checkout at v3 with ref so basically what this is doing is it's grabbing the uh the code from the contributor and then it's checking that out and running that in the context of the pull request target repo and so when we go down and we kick off our our tests then what that's what that's doing is it's basically running it's basically giving the the contributor it's giving them right access to the to the repository and effectively bypassing the whole idea of a pull request okay okay well yeah and i'll be demonstrating that here in a little bit um yeah i can't wait to see that a lot easier to see it rather than to try to explain it yeah yeah well i think you did a great job um and i think it will help us follow along in that demonstration too you know i'm not gonna i'm not gonna pretend that i know everything what you just said but um yeah as i said we are gonna be doing a live demo of of some of these exploits so we have one last one now this is the last best practice that we're gonna go through and then we're going to get stuck into to some of the to some of the demos of of of how these actually work in practice so prefer open id connects to um access access cloud resource can you talk through your preferred open id and and and what's going on with this one here so sometimes in your github actions workflows you might need to do things like interact with a web service to um you know upload a scan report or something like that um or maybe you are deploying code and you might have to uh use some sort of api token to be able to access the environment where you're going to be deploying the code and so open id connect is it's it's kind of a a single sign-on uh provider so it's it's kind of an alternative to saml where but it's actually more geared for apis and it's kind of more lightweight than saml and so how you would use this in a github action is it's it gives advantages over longer lived tokens so you might have say in get guardian you might be able to create an access token to get guardian and basically just put that in your repo as a secret well with open id connect if that's available to you what that actually allows you to do is to create single use tokens rather than these longer lived tokens and these single use tokens um you know if one of those gets compromised it's no longer valid so it's just a more secure way to access cloud resources and github has quite a bit of good documentation on that if you want to read further okay cool cool definitely well look we've come to the end of this so these here are kind of a seven um i've combined two of them in here because eight didn't fit so seven but actually eight um best practices now we have our entire blog and a cheat sheet to help you follow along to this but right now uh i'm pretty excited because uh cj let's see some of this in action let's see what actually happens when these when we don't follow these best practices now i've been reading through a couple of comments and there's a few people saying that that a lot of these should be um you know should be should be self-evident but some of them can be very simple simple mistakes to make and you know it is the problem is that it only takes one of these mistakes uh to be made um if we trust something a little bit too much to to to be able to kind of get exploited so uh cj i want to invite you here to uh to to share your screen well i guess uh i can control that um and we can have a look at this in practice so the show is yours all right uh you guys can see my screen and everything right so basically we have a repository that i set up here and it's a private repository because it's got uh vulnerable workflows and i don't want you know random people submitting pull requests and trying to exploit it but basically in our scenario here we have an open source repository that's got you know some main code this is kind of the body this main script this is kind of the body of our code and then we've got this script over here that is going to be running tests in our ci pipeline so if we look at the workflows that are set up here we have this vulnerable pull request automation and so the first thing that i'm going to point out is that the this automation as part of the automation is printing out the name of the pull request so maybe the developer wanted to um wanted to identify the port the exact pull request title just to make it easier to reference that when they're looking at the actions output so what they're doing here is they're just echoing that variable that contains the pull request title so the way to exploit this if we go to this other branch that i have and we'll just pretend that this is some external contributor if we make a pull request from this branch here we're going to change the name of our pull request and we're going to call it this command here and i have a a web server that's kind of staged for this and it's got a bash script set up that i'm going to be running in the ci pipeline and i can just show you oops i had too much of it highlighted sorry about that so basically this bash script is just emulating uh you know dropping malware and then executing that on our runner so when i create this pull request it'll start kicking off some automations here in a second and if we go watch the vulnerable pull request what's going to happen is when it echoes the name of the pull request title it's actually going to inject that code that i put into the pull request title and it's going to put that on the command line so if we look at this step here print pull request title you can see that the the code actually injected and ended that echo command and then it actually made that curl request and then executed the script and so obviously that's not something that we want to happen in our in our environment so what we would do then to prevent that is we would do what i talked about earlier where we create an environment variable called pr title and then we use that on the command line which effectively de-weaponizes this untrusted input that we have here right so that script that you did before i mean that could have been anything or anything malicious and and then by by making it an environment variable we're basically saying that that this isn't you know like not to execute not to execute these instructions this is just a title yep exactly and then um the second type of injection we'll come back and look at our vulnerable workflow here this is the one that i was kind of alluding to earlier and this one gets a little bit more scary so with we're running in the context of the host repo but what we're doing is we're checking out the code of the pull request and so i've got this other contributors repository here and they modified the test script so instead of just running tests it's going to be stealing the api key which is uh you know a secret in the in the github repository and it's just going to be shipping that off to that same to that same web server in just a curl request and then the next thing that it's going to do is the scary part so what this is going to do is it's abusing that github token that it has access to and it's actually going to be modifying the main code of the repository and pushing that directly to the origin repository and so basically what's going to happen is as soon as i create that pull request and it kicks off this these automated tests it's actually going to be modifying the main branch of this repository without even merging the pull request so let's go see what that looks like so i'm going to open a pull request and it doesn't really matter what i name it here i'm just going to create the pull request and here in a second it'll kick off the automation so if we go watch what happens when it actually kicks off those tests we can look and see okay so we were stealing the api key it made that curl request and shipped it off to my web server and then down here we're abusing the github token so it modified that that main script that's kind of the body of our repository and then it actually made a commit and it sent that to the main branch so if we go back and we look at our repository and we check out that main script well let's back up for a second we can see that the most recent commit was from this github runner bot and it's got this seemingly inconspicuous commit message but if we look at that commit we can see that a curl request that same malicious curl request that we were making earlier was actually injected into the body of our code and again if we look back at the pull request that we just opened the code hasn't been uh committed yet but it was able to modify the main branch because it had the permissions from that vulnerable workflow so so yeah go ahead i just want to stop you yet so this pull request has been made by a third-party contributor now we haven't accepted this pull request like we haven't added this into our code yet right right yep and we can even close the pull request and say say we're the repository owner and we recognize that they modified that test script and we want to just close it because you know we identified that it has malicious code in it but we might have overlooked the fact that even after we closed that pull request it already modified our code so this is the main branch of our repository and that pull request had basically bypassed um all sorts of uh access controls and it already injected its code into the main body of the of the of the program so this is insane so yeah wow so from a malicious actor using github actions they can inject code even if we do not accept their pull request that's wild that's absolutely wild and so the way to protect yourself against that if we look at the safe check is rather than using pull request target we use pull request and this ensures that you know the github token that the pull request is using does not use uh or does not have right permissions to the main branch and yeah that kind of concludes the the demo if if anybody has any questions we can cover that as well i had a i had a slide for that and everything there you go q a well see cj that was uh that was fantastic so thanks so you know i know that's probably a lot for everyone to follow along but i do want to kind of uh uh um emphasize is that all this is outlined in a very detailed blog post with a with a cheat sheet that comes along with it so so if you're kind of struggling to go okay what yeah you look you you want to know the code you want to know the the the examples we can you could go through this again in your leisure and be able to see in more in more detail more clearly what's actually going on because i know in a live in a live uh area it's it can be difficult so all of this is on our blog well it's big banner um blog.guardian.com um you'll find the cheat sheet in there but at the end of this uh webinar i also have some um i have a link and and um some a qr code so if you want to live dangerously and scan a random qr code on the internet and you can do that and i promise it'll take you to the right place not a malicious website um okay so look um i'm gonna i'm gonna go through and uh look at some of these questions that we have um and so even if you haven't asked the question please go in the question area and upvote your favorite ones um so that we can get to the right ones um okay so uh first question here is it secure to run external workflows for example um being aws ecr uh login um i'm gonna assume that you mean uh external external actions um in inside of a workflow so yeah i you know in general if you trust the the publisher of that action so which is probably aws um if you if you trust the publisher then that's okay if you're not sure about the publisher you might uh you might it might be a good idea to actually look into the code of the action so in order to publish an action on the github marketplace you actually have to have a public repository that shows the code that's going to be running in the background when you use that action so you can actually go to that repository and read the code for yourself and vet it out if you're if you're not sure about the author okay great great all right let's move on to to another question there how these changes how are these changes done by adversaries that are logged so i think the question i'm going to try and refresh how are these changes done by adversaries when they're logged by github uh oh that one's just disappeared okay we'll try and uh i'll try and ask another one here okay the presentation deck gonna be about i can answer this one this one's an easy one yes the presentation deck will be available we'll make that available along with the video um there we are is there a way to scan action scripts automatically by action scripts uh i think would that be like the github actions workflow yaml file yeah yeah so the yellow so what when we're writing our code is there a way to to is there a tool i guess like sast you know we have these tools for for finding misconfigurations is there something similar for github actions that's a good question um to my knowledge i don't think there is uh if you have a a a sas tool that is configurable you might be able to create your own detections for that um but yeah to answer the question to my knowledge there aren't any any tools out there that come pre-built with detections for this type of thing right got it we have a couple of uh questions along those lines too um can kick out is geek out incapable of preventing this title pollution so short answer is uh no no we you know we can detect secrets and um in different areas but we can't uh we can't solve all all the problems and so what i always say when it comes to get guardians get getting should be one tool in your toolbox when it comes to to having secure secure coding there is no silver bullet solution um and whilst we're all expanding our capabilities as fast as we can um you know it's always good to have multiple tools tools in here okay um does it protect uh other branches outside of just the main branch so um i'm assuming that's i'm assuming there's another question of gegardian so yeah yes i'm guessing so yeah so basically um the the workflow that runs will only have modification access to whatever it's running in the context of so let's say that you are you have pull request target um and it's a pull request to a non-main branch let's say you have a development branch and it's pull request to that then the the context github token would have access to that development branch that you're trying to merge into but to answer the question um if you use just the pull request it should protect all of the branches because it's only running in the context of the contributors repository so whatever branch or whatever uh repository that they have it's only running in the context of that so anywhere that they open a pull request to um would not have that right access okay cool i have there's a great question here that's actually been upvoted quite a lot um so this is this is this is great um does this vulnerability apply to private repo so basically um you know what what are the security risks of of having private reproduces public records when it comes to to to github actions so can you can you talk a little bit along the demo that i just gave was actually in a private repo um the the main thing to think about is going to be have you granted uh have you granted permissions to the repo to anyone else so if you're the only one that can see your private repository you don't really have to worry about these things because technically if you're the only person that you can even create a pull request or you know interact with the repo in any way you don't really have to worry about it that much but if you've given somebody else access to your private repo or a group of people access to your private repo then technically yes you do have to worry about um you know what they might be able to do or if somebody takes over one of their accounts what they might be able to do with that okay okay that makes that makes total sense you know and i and there's another thing too to remember about private repos is that um we put so much trust in in in our private repos and i'm always a big advocate of kind of acting like a repositories and implementing similar security practices as if they're public so you've probably all heard of like lapses breaches that have happened where they uh published samsung nvidia and microsoft source code of the internet because they didn't pay ransoms and a lot of people were wondering how did this band of teenagers as we later found out lapses was get access to all the sensitive source code and basically they were recruiting people on their telegram channel so so have a look at all the have a think about your organization everyone that has access to your your private source code okay there's uh there's your developers there's your interns you might have hundreds of them you might have thousands of them um and how many of those could potentially sell access uh to an adversary if they wanted to so um i hate i i don't like fear-mongering on this because this isn't a scenario that that that is super super likely but it can happen and you know if we if we act like our repositories are public um then you know this can also help that's my that's my two cents not that anyone asked but i thought i'd give it to you anyway uh all right i think that's kind of it for uh for some questions i'm just having another look um okay yeah well i will say uh cj uh you can't see the comments that are coming in here so i thought i'll read a couple of a couple of comments to you here awesome demo cj thanks thanks absolutely fascinating that was both fascinating and frightening um and we have a whole bunch of other ones so uh cj i would like to take this opportunity to to to uh thank you as well um for this and so the audience uh really loved it as i knew they would because nothing beats a live demo and as i said at the start we do have some prizes so remember if you don't win a prize today you can still win some stuff um by emailing me your your uh stories about league credentials they can be anonymous i promise i won't uh share any other insight but um the the reason why we're asking for these is because it happens to the to the best of to the best of uh everyone to leaking leaking credentials so i'm going to quickly share a story that involves me very quickly 30 second story i was creating a video for youtube about what happens when you leak credentials in a public github repository and i was using canary credentials but i got mixed up and i published a real secret whilst making a video about why you shouldn't publish secrets now luckily it wasn't the end of the world it wasn't it wasn't access to git guardian's production service but it it was access to my personal aws account uh i revoked the secret immediately i knew about it but i but so even when you're making a video about why you shouldn't leak credentials publicly you could accidentally leak credentials publicly so uh so feel free to share those all right but we do have a couple of winners from that here i'm going to go to my analytics and i'm going to try and find out who uh were some of our our most active attendees we had 231 people attend this webinar uh live and i'm sure we'll have a lot more uh afterwards so thank you everyone for for attending it was absolutely uh fascinating and i'm just scrolling down to see the most active attendees so here we are now if you've been to these before you'll know that i have um i i i have a terrible track record when it comes to pronouncing uh pronouncing people's names but we we do have some with it so um baiden herb congratulations i'll be in contact with you i'll put your name uh in here so that in case i've mispronounced it and also andrew camani congratulations to you two um you guys have both won some prizes um and i'll be in contact uh as uh as well um our most active attendee uh has already won a swag bag so i won't i won't give you another one although i don't think you've received your first one so last last month so um but anyway uh look i think that brings to the to the end to the end of the webinar you always know it's getting to the end when i start waffling um so thanks everyone for attending this was fantastic uh thank you again cj it was perfect now if you scan this qr code it will take you to the blog post that cj um uh wrote with uh content writer thomas it's a fascinating um it's a fascinating um article that will help and and and show some of what we've talked about today and um i think that call to action button should be happening too so there's also a link there's also a link down there if you don't want to scan a random qr code um then you can type that in manually too down the bottom or you can go to our blog we have lots of lots of content there so that's it that brings us to the to the end of the uh to the end of the session today so thank you everyone again uh for for participating uh for being here and thank you again cj now we do this every month so if you haven't already make sure you uh you follow follow us on crowdcast so that you'll be alerted next webinar and also uh check out our youtube channel um [Music] where we also have lots of other content on there as well so yeah thank you thank you everyone thank you cj and hopefully we will see if you see you guys next time thanks for having me