 Okay, let's get started for this presentation about automatically restricting permissions for the GitHub token. My name is Varun Sharma and I'm the CEO and co-founder of Step Security. Before starting Step Security, I was at Microsoft for 15 years. So this is what we'll talk about today, we'll talk about a story of a supply chain attack on the VS Code GitHub repository and that will lead us to a discussion about GitHub tokens and then we'll discuss how to set minimum permissions for these tokens and then I'll talk a bit about this open source project called Secure Workflows that can set these minimum permissions automatically. So this is a new story from Jan of 2021 where a security researcher was able to push a commit into a release branch of Visual Studio Code and this is what it actually looked like. So this is the VS Code GitHub repository and as you can see this is a pull request that has been merged. It just has a single file which is a proof of concept to prove that it was possible to push this file and the interesting thing here if you see is the user that has actually done this commit and it says GitHub Actions and what that, the reason that is interesting is because typically it requires a maintainer of that project, someone with right access to be able to push and merge a pull request but in this case it's been done by GitHub Actions and what that really means is that this has been done through a GitHub Actions workflow. So GitHub Actions is a CICD platform from GitHub and it's quite popular, in fact if you just search for these workflow files on GitHub you'll find more than 2 million workflows just for open source projects. So I'll talk about more about how this was done but let's talk about what is this token and how is it set up. So in this screenshot you see a typical GitHub Actions workflow and every workflow has a GitHub token and when it starts the token is issued and when the job is completed the token expires and the reason is because it's used to access different GitHub APIs and this token has a set of permissions which you can see in the build log, the most important permission here is the contents write. So this token has permissions to write to that repository where the workflow is running and so what had happened in that case is that the researcher was able to find a command injection vulnerability in a particular workflow that VS Code had and was able to inject their own code in it and exfiltrate this GitHub token and once they exfiltrated it they were able to, because it has contents write permission, were able to create a new branch push changes and then merge the pull request and so the best practice here is to actually set minimum token permissions for this GitHub token and as you can see in the screenshot you can set permissions using a permissions key and this is something which is recommended by GitHub and it is also something that the open SSF's code cards project finds and it classifies it as a high risk issue. Now the problem is that if you actually wanted to set these token permissions you would have to do these things manually so you would have to first of all know about the token and the token permissions, you would have to review your workflows one by one and then for each of these steps figure out what are the permissions needed. If you are using a GitHub action which is written by someone else then you would have to go and look in their code to see what the permissions are then you would have to sum up all of these things and put the right key in your workflow files and as you can imagine this is a cumbersome process which is why very few workflows actually have permissions set which is why they are not secure. So what secure workflows does is it is an open platform to update CICD pipelines to comply with security requirements and you can find it at github.com slash step dash security slash secure dash workflows and one of the things that it does is to set token permissions automatically. So the way it works is that it basically just does the same steps that I had listed but it is done in an automated manner and in addition it has a knowledge base of what permissions are needed by common GitHub actions and that knowledge base is stored as a YAML file so if you see the screenshot on the right you will see that for the labeler GitHub action it says that the permissions needed are contents read and pull request write and there is also a reason specified. So when it evaluates a workflow it goes through each of the actions being used and looks at the knowledge base to find what are the permissions that that action needs and then sums it all up and comes up with a recommendation. So in order to use it you can go to app.stepsecurity.io and as you can see in this screenshot you basically paste your workflow in there, click on secure workflow and it's going to do the evaluation and modify the workflow file and add the required permissions. You can also use this by using the open SSF scorecard action. When you use that action it has a recommendations link and it basically points to the same URL. So this is the impact of this secure workflows project so far. We used it to fix token permissions for top 10 critical open source projects and for that step security was rewarded the secure open source reward by the Linux foundation. In case you're not aware of this, this was actually discussed earlier in the conference where these are rewards given for securing open source projects and over 1500 workflows have been fixed so far and these are some references about the stuff that I discussed but thank you, let me know if you have any questions. Yes, so that is one of the features is to automate a token permissions. In addition, it can also pin the actions to a particular commit shot so that's another recommendation from Scorecard and GitHub so it does that as well and in the future we'll add more things so the idea is to sort of automate the remediation steps for developers so they don't have to spend time and effort doing that. Yeah, exactly.