thank you hello everyone welcome to another webinar here uh at get Guardian I'm super excited for this webinar to to begin I'm super excited to hear from our very special guests it's going to be one heck of a session uh just want to say this is the largest webinar we've ever done nearly 1 400 people uh signed up for this and as you can see the the check going crazy uh it's great to see that you you all here it's fantastic to see such an interest in this topic and I'm really nervous that because because there's so many of you but we're gonna we're gonna get through it it's all going to be totally over fine uh so we had to have some very special guests here today that the webinar is a Hands-On guide to runtime security for CI CD pipelines with step security and we are joined by Varun Sharma and Ashish uh Gurney and so it is uh it is a really cool these guys are the founders of Step security uh and they also have years of experience in this and not only are we going to be looking at some problems looking at some really cool information there's going to be a lab as part of this this is this is really going to be a Hands-On webinar uh so they're going to have lots of opportunity uh to really learn some stuff and and actually participate so just something to know uh we do have prizes in this webinar so depending on where in the world you will depend on the kind of prize that you get and how you get prices is basically by participating being active in the chat asking lots of questions participating in the poll so they came up and at the end uh when we send our follow-up email just to thank you all we'll announce who the winners of those prizes are so please participate uh as as we go along uh that's your best chance to win some cool swag some cool prizes uh from us here so just while we're waiting I'm saying that there's a lot of people uh joining let us know in the chat whereabouts in the world you are joining from I myself are in the Netherlands uh close to Amsterdam um so we have that we've got USA we've got France Colombia Spain Morocco Germany oh it's going so fast India Indonesia Algeria UAE Israel Paris Kenya Costa Rica wow this is crazy Philippines ah this is absolutely mental uh this is really cool to see so many people from around the world Romania UK Ghana well my wife is actually in Ghana right at this moment so that's pretty cool uh Nigeria Nigeria Lagos we've seen a lot of people from the African continent that's fantastic Canada Chile Brazil oh wow really cool to see such a wide audience here joining us today uh so just a couple of things prerequisites there's a couple of things that you might need for this um you would need a web browser but I'm presuming uh you're on a web browser right now if you want to participate in Labs you'll need a GitHub account and you'll need to Fork uh this repository here uh so uh we can paste the repository in the chat you're going to have lots of opportunity to get to this as well I just wanted to give you an opportunity now I've added a link to that in the chat so if you want to go to that and Fork you can go ahead now you don't need to participate immediately on this this is being recorded and actually uh there is going to be an opportunity for you to watch this again so if you you know if you can't follow along uh entirely or you need a little bit more time then you can go ahead and just watch what's happening and then watch the replay and follow along but if you want to do it live with us you absolutely can too and that's the way that you can do that by forking that account in the chat um and uh and yeah and you can go ahead and and do that so I want to talk a little bit before we get going uh about why this is such an important topic and why get Guardian uh we're so interested in this so the guests that we have today are from Step security that's a fantastic company that's emerging um and I think by evidence of how many people are actually on this webinar shows just what an important uh topic this is uh but uh at step security it's all about securing the the CI CD pipelines and this is something that git Guardian has been really interested in as well um recently we've released our new uh product called honey tokens and these are fake credentials to uh to trap attackers now we've done some webinars on these honey tokens how to use them and how they can be part of supply chain security and Security in your CI CD pipeline but there's an important distinction which is why I'm so excited to have step security with us today and that is is that honey tokens are really part of an overall defense of supply chain security what honey tokens Can Do Is they can alert you when someone's broken into your systems they can alert you when your areas have been compromised but in addition to that you also need a way of being able to actually prevent security incidents like blocking security incidents being able to prevent malicious packages being able to prevent those calls now honey tokens can let you know when this happened but they can't actually stop it step Security on the other hand and the lab that we're going to do at the moment is all about how we can actually prevent malicious actors from getting inside our cicd pipelines so it's a really really important topic um and something that I'm super excited uh to to get into all right so that's pretty much it uh from from me uh I think it's now time for the main event so I'm going to hand over uh to uh Veron to share your screen and I'm going to let you take over so I'm just going to stop sharing mine awesome sorry Ashish I got I got uh whatever she's I'm going to head over to you now to share your screen and start the presentation so uh welcome uh everyone uh if you've enabled the Emojis we can send some emojis to a welcome Ashish to the stage and present uh on this webinar there we are I'm loving it uh for the first time so if she's I'm gonna leave and turn it over to you actually I'll I'll start this slide so welcome to the webinar on runtime security for cicd Pipelines and uh you know Mackenzie has already mentioned that this has a Hands-On lab so I'll not go into that a quick introduction my name is Varun Sharma and I am the CEO and co-founder of Step security uh step security is a leader in CI CD security uh and we are on a mission to build the world's best CI CD security platform uh before starting step security I was at Microsoft for 15 years I was part of the Azure security team Ashish you can go next hi everyone it's so great to have you all join us for this webinar my name is Ashish kurmi and I'm a co-founder and CTO of Step security I have about 13 years of Industry experience across plaid Uber and Microsoft and throughout my career I have primarily built low friction Security Solutions for Developers so this is the agenda we have today for our webinar to set the context for our Hands-On Labs we'll briefly go through cicd security and stuff security hardened which would take about 15 minutes and then we'll jump into our Hands-On labs so let's look so let's start the first section and let's actually uh do an interactive exercise so on this slide we have shown a typical CI CD pipeline so in this case it's a GitHub actions workflow and it consists of three steps so at line 53 we are checking out the source code and then at line 56 we'll log into our AWS ECR account and then finally at line 64 we build a Docker container image and we push it to our AWS ECR account and I would love to know from your perspective what can go wrong here and you know you can provide your input in the chat area uh so cicd is a high risk environment because cicd first of all is a high privileged environment as you can see at line 60 it typically holds admin Cloud credentials because it needs to manage Cloud environments in addition it also produces production builds uh that run in the cloud environment and the key threats in the cicd environment are related to the use of untrusted third-party and open source code in this high privilege environment so uh just like any modern day programming language all CI CD providers have a rich ecosystem of Open Source and third party components so when you build a CI CD pipeline today you don't start from scratch you essentially assemble existing open source and third-party components to achieve your chle objectives and this slide you know summarizes the key threads in the cicd environment which are related to the malicious misuse of the Privileges I described in the previous slide so they are exfiltration of source code and cicd secrets from the cicd environment and tampering of release bills and this is typically done through poisoned workflows and a workflow can be poisoned either by compromising a dependency or by a compromised build tool now uh malicious cyber actors you know also realize the value of going after CI CD environments and recently uh you know there has been a sharp rise in the number of cicd security attacks to put these threats into perspective let's look at two such uh cicd security attacks and let's start with the code of breach so code cop is a very popular service for measuring and tracking code coverage as an engineering as an engineering best practice a lot of organizations you know have internal targets around code coverage so when they run uh either unit tests or integration tests in CI CD they typically use code cough to measure and track progress on these engineering objectives so in the code of breach the code of bash upload a script was maliciously modified so when you run code in CI CD it produces a detailed report of code coverage and this bash upload a script essentially uploads this detailed report to the code API so after compromising The Bash approached script in January 21 these attackers silently persisted in the code gov environment for the next three months and during this time period anytime a code of customer ran code cop in their CI CD it executed the attacker-controlled malicious code as well in in the customer cicd environment and what this malicious code did was it read all the environment variables and then it exfiltrated it to an attacker controlled remote endpoint and once the attackers you know had access to these environment variables they were able to steal proprietary source code and other high value assets such as Cloud admin Cloud credentials thousands of code of customers were impacted because of this breach and many large-scale organizations publicly announced that their CI CD was compromised because of this breach you know companies such as twilio harshi carbon rapid 7. uh in fact hashikov's signing key was stolen in this breach uh McKenzie has uh written an excellent uh get Guardian blog post about this breach and I would highly recommend you check it out if you're interested in learning more uh now let's look at the solar winds breach uh solar winds is a very popular vendor for networking Solutions and in this case uh the attackers compromised the build server which was used for producing solarwinds software updates so in this case when the uh when the build server is compromised the attackers ran a utility called Sunspot which is a malicious piece of code which was constantly running uh in the background you know on the build server and this uh malicious code was capable of detecting when a software update is about to be produced so as part of the first step you know um in this software update pipeline uh the remote source code repository was cloned and the local copy was created so this Sunspot malware you know when it detected that a software update is about to be produced it maliciously tampered a local source code file and it injected you know another malware called Sunburst into it and then the software update was produced using this infected copy of source code and since the software update was produced through the official uh you know CI CD pipeline It produced all the release criteria such as the you know the binary was signed um and after this infected software update was published it slowly got rolled out to all of their customer environments eighteen thousand solarwinds customers were impacted because of this breach including about 90 percent of the Fortune 500 companies and many U.S government agencies such as all five branches of the U.S military uh this bridge was so severe that after solarwinds made this disclosure their stock price went down by almost 25 percent so uh Paul question uh we would love to know which cicd platform do you use and you can provide your input uh in the poll tab so as we saw cicd security attacks are on the rise and attackers are actively going after these high privilege environments let's see how the industry is responding to this responding to it so the industry realizes the need to protect cicd security and you know we are catching up on this area and you know we have shown two examples here so the first one is sisa which stands for cyber security and infrastructure Security Agency and NSA which stands for National Security Agency they recently released a joint uh guidance on defending cicd environments uh nist which is again another U.S government agency has started drafting guidelines for cicd security there are also a few industry regulatory bodies such as CIS uh you know they have started including requirements related to cicd Security in their benchmarks let's double click on the sisa guidance and let's see what they recommend so sisa recommends that the cicd network must be segmented and all the traffic that is uh either coming into cicd or going out of CI CD must be filtered they recommend using endpoint deduction and response or EDR Tools in CI CD to assist with investigations and forensics CSA recommends maintaining a tamper-proof audit logs and finally to reduce the CI CD attack surface sisa recommends eliminating unnecessary applications from CI CD there are several Security Solutions that can provide these capabilities in other non-ci CD environments so for example there are many EDR solutions that work really well in in the cloud environment similarly there are many vendor solutions that can eliminate unnecessary applications from source code repositories but when you run these existing Tools in CI CD they don't work and the primary reason is that you know these tools were not built for cicd in the first place so they understand see I said you can't interesting event in CI CD might be completely irrelevant outside of it so for example in the solarwinds breach we saw that a source code file was tampered maliciously now this is a significant event you know when you observe it in the cicd deployment in your CSD deployment pipeline but for a typical workload it's completely irrelevant second most of the runtime Solutions today primarily focus on anomaly detection and it makes sense because a typical Cloud workload is is highly unpredictable so you know you have to use machine learning and AI to figure out the interesting security events you know from these uh unpredictable environments on the other hand CI CD is highly predictable because it does the same thing again and again you know it downloads the source code from a well-known location it you know then pushes the software artifact to another well-known location it manages your Cloud environment which is again hosted at a well-known location so a better security strategy for CI CD is to create a baseline of the expected behavior and then flag any deviations from it third cicd can be hosted in a variety of ways you know you can use a completely managed uh SAS cicd provider on the other hand you can also host Cicely yourself and uh or you know or you know you can either use like a combination of these two options and existing Solutions are not versatile enough to cover all these CI CD hosting scenarios another poll question uh we would love to know how do you host your CI CD platform do you use a self hosted uh uh do you self-hosted yourself or do you use a completely managed provider and uh just while we're waiting for those poll questions to come through those that are interested the results are from the the from the polls we've had 138 Answers by far the most popular CI CD platform is GitHub actions at around 59 followed by gitlab then Jenkins then Azure devops and circle CI coming in at three percent in fourth position which is uh I found that interesting I I I I talk about their Circle CI and everything so much that I really thought that would have been uh would have been higher up but really interesting um and yeah make sure you submit your your vote the polls tab is next to the questions tab uh you can see it in there and you'll see the results once you submit uh submit your answer currently uh we're looking at about 60 hosted by the provider and forty percent uh hosted uh host is self-hosted but lots more votes still coming in I'll leave it back to you Ashish awesome so as we saw the industry is responding to cicd security attacks and you know we went over uh security recommendations to protect cicd now let's look at how step security Hardware learner can help you comply with these security recommendations cicd security platform and it is based on our learnings from the past cicd security attacks so uh build servers are typically called Runners and since the platform strengthens it or hardens it it's called hardened that's the story behind our product name so these are the key uh hard and under features harder Runner contextualizes all security observability events so anytime it makes an observation or it detects a runtime event it Maps it back to the exact CI CD step that produced it uh hard and Runner can create a baseline for the expected runtime behavior for your CI CD pipelines and then it can help you monitor any deviations from it we have built a CI CD native Network firewall which is an abstraction on top of the underlying infrastructure Network firewall and the host firewall so once you define your criteria to filter Network traffic no matter where your workflow is running either it's whether it's running in a vendor managed environment or whether it's running in your own environment hardened Runner can effectively apply those Network filtering controls and finally to protect the Integrity of the build process it also has a real-time file Integrity monitoring system harder Runner is free for open source projects that are using GitHub hosted earners uh for Enterprise use cases it also supports proprietary source code repositories and self-hosted runners Hardware number was released about 18 months ago and since then we have seen rapid adoption of Harder nunner by open source projects we recently crossed 1500 open source reposities that are using harder nunner and these are you know uh and these are important open source projects so we have you know open source repositories from industry Giants such as Google Microsoft MasterCard and data dog in addition several not-for-profit software foundations such as node.js and kubernetes are also using Hardware Runner to secure their CI CD and sisa has also started using Hardware in their public repositories so with that let's jump into the Hands-On lab so before we get started with the Hands-On Labs you know quick reminders that you need a GitHub account and you know a browser if you haven't already you can force the GitHub actions code Repository so let me go ahead and share my screen okay can you uh Ashish can you see my screen yes I can say it okay so before we go into the Hands-On Labs let me give a quick demo of hardened Runner so what you see here is the hardened Runner repository and the best way to understand what it does is to look at some of the projects that are using it so let's look at a couple of them the first one is from sisa and what you see here are runtime security insights from a particular workflow run for a GitHub actions workflow so here under the workflow you can see it says build.yaml so those who are not familiar with GitHub actions uh you know it's a cicd platform and you can write the pipeline as code file in yaml and that's what you see here and in this case uh at line 25 the step security hardened Runner GitHub action has been used and this is what uh you know does the runtime security analysis and as a result you see those inside so this this is a open source project from the cyber security and infrastructure infrastructure Security Agency seesaw and for public repositories these insights are public so anybody can see them and this is what you know Ashish was mentioning when he said contextualized uh runtime security Insight so as you can see this this is telling you what is the outbound calls that are being made as part of this particular workflow run and we'll go into more detail later in addition you also see a recommended policy so instead of relying on anomaly detection it's actually telling you that these are the calls that were made and now you can set a recommended policy or a block policy for this particular workflow so if it runs and if there's a call to any other endpoint that will get blocked so now let's look at another example and where you know a block policy is being used and this project is again a public repository from a Google Cloud platform and in this case if you see there is a block policy being used now if I go to the link.yaml file which is the GitHub actions workflow in this case on line 19 you'll see that it uses the step security Harden Runner action uh and on 22 line 22 you can see that the egress policy now is set to block mode and after that you can see what are the allowed endpoints which have been specified using domain name so if there's a call to any other endpoint uh harder one is going to block that and we can see here that in this run there was actually a call which was not in the allowed list to rubygems.org and that was blocked in this case it was not a malicious call it was just missed in the list but for example in the case of the code cop breach when credentials were exfiltrated that would have been an actual incident which would have been blocked yeah so that was a quick demo of hardened Runner and now let's go and do the Hands-On so if you haven't already for that you can uh you know now Fork the GitHub actions gold repository this is like an educational project where you can do Hands-On labs in order to Fork it you can click on this Fork uh you know drop down here and then click on create a new Fork and in this case I'm creating a fork you know under my GitHub account and let's go ahead and click on create Folk so once you Fork this what I would suggest is that you can just duplicate this tab so that we can read through the labs in one of the tabs and actually follow the steps in the second one now if you've reached till here what you need to do next is to actually enable GitHub actions on this Fork repository so if you go to the actions tab which should be the third tab from the top software code pull request and actions if you go to the actions tab you will see that there's a green button there it says I understand my workflows go ahead and enable them so by default actions are not enabled on a fork so you can go ahead and click this and it should enable GitHub actions on this fork and you should see a list of available workflows on the left side so now let's go ahead and start with the first Hands-On lab the first one that we will do is the first one in this table which says GitHub actions runtime security filter egress Network traffic so you can go ahead and click on that and it's going to have a set of steps that we are going to follow now these you know this Hands-On lab is going to use GitHub hosted Runner the first one is about network monitoring without hard and Runner so in this case we are just going to see what happens when you run a workflow which doesn't have hardened Runner and you know by default these workflows and in general pipelines in any CI CD provider are not really monitored for security observability and that's what this lab is going to show so if you go to the actions tab now you should see a hosted network monitoring without hardened Runner you should see a workflow there uh network monitoring without hardened Runner and if you want to see what this workflow is you can click on this yaml file which is going to run when we run this workflow so this is running on Ubuntu latest which is the GitHub hosted Runner and it's checking out code on line 9 and then on line 13 it's doing an npm install and then it's publishing you know to the GitHub container registry so it's a typical workflow and now we'll just go ahead and run this and if you haven't actually used GitHub actions before this is also a good good chance to just get familiar with it so let me go ahead and run this and you should start seeing that a workflow is running now and what you see here are the build logs and the purpose of this this particular lab is just to understand what do you get when you run a workflow and what do you not get which is that you don't really have any network monitoring by default so you don't really know what kind of outbound calls are being made uh you know so you know the code was checked out you know there was an npm install and there is a published to a registry which is happening right now but you don't really know what are the calls being made so we'll let this be here and let's start with the next Lab which is network monitoring with hard and Runner so now you're going to look at the difference uh and now you should be able to see as you follow this you should be able to see the outbound calls and when you do try to spot something interesting so now I'm going to run this lab you can go to the actions tab again and on the left side look for hosted network monitoring with hard and Runner so now we're going to run this workflow and if you want to see what this workflow has you can click on this hosted network monitoring HR dot yaml file and now you will notice that as I had showed in the earlier demo on line 9 there is a GitHub action State security hardened Runner which has been added and on line 11 you can see that the egress policy has been set to order so this is how you typically use it at the start when you don't know what are the end points that it's calling so so now let's go ahead and run this so the network monitoring with hardened Runner you can click on here and run workflow and now let's see what what output we get so in the build log you can see that the first step now is uh you know after setup job it's it's doing a pretty hardened Runner and then a hardened on a step and when you click on that you should actually see a link to the way that says view security insights and recommended policy so this is where the security incites for this particular run will become available after this workflow complete completes so now if you're following along in your workflow run you can go to the step where it says Run State security hardened Runner you should see a link and this link will have your own Fork repository mentioned there and you can click on this and once you click on this you should be seeing something like this you know these these uh security insights from that particular workflow run so let's go through these and see what this is telling us right so in the first step which was a checkout we now know that an outbound call was made to github.com which is expected because it needs to download the source code and then in the npm install step it's making a call to registry.npmgs.org which is also expected for it to download the uh dependencies but after that you see that there's a call to attacker.com and this is uh you know this is really suspicious and interesting uh and it's not really clear why this is happening right because all we had done was to run npm install and this is certainly not expected that it's going to make a call to attacker.com now in a real scenario it's not going to be that obvious but for example in the code preach an outbound call like this should have been spotted going to a direct IP address so the code reached outbound call that the attacker made was to a direct IP address and that would have clearly shown up here so now let's try to investigate you know why is this call being made where is this call being made to attacker.com so if you click on this npm link npm install link it'll tell you the exact step where this call was made so now we we know that this is where it's doing CD and then Source exfiltration demo and npm install so in order to investigate this let's go into our fork and look into source so there's the source folder and the exfiltration demo folder and this is where npm install is being run so if you click on the package.json file what npm install does it installs dependencies that are mentioned in the package.json file so here on line seven you see that there's a dependency step security malware simulator which is actually pointing to a file which is also in this repository which is under malware simulators exfiltration simulator so let's go there so just below this there's a malware simulators and exfiltration simulator and in here there is a package.json file and if you notice this has a pre-installed step so when npm install is run for every dependency that it installs if there is a pre-installed step it's going to run that so it's going to run the code here which is node compile.js and if you click on compile.js you'll see that on line four this is where an outbound call is being made to attacker.com and this is the call that hardened Runner is actually able to Monitor and tell you now this is just uh you know uh simulator so it's not not doing anything but just making the call but in a real scenario this could be exfiltrating source code from the build server or it could be extra trading the environment variables which are secrets uh like was the case in the code cop breach so uh that was the lab for network monitoring with hardened Runner so if if you had gone into you know the the acceleration demo and simulators try to get back to this lab page um also let me just you know pause for a minute and check Ashish McKenzie are there any uh questions or or anything to clarify until that I can help I I can't actually see the chat window no problem yeah there's a there's a a bunch of uh really great questions that have come through I just want to reassure everyone I know a lot of people were were trying to follow along um just to reassure everyone that there will be a recording made of this available so if you got lost to a little bit we need to redo something the recording is going to be available so you can uh you know do that again uh if you've got uh if you've got a little bit stuck um but uh just to answer that if we have uh if if we have a time for for a couple of questions now um or we could wait to till the very end it's up to you uh right yeah let's wait till the end let's go through the labs and we can do the questions at the end sounds good okay so the next Lab is about Network filtering with hardened Runner so up till now we were able to monitor the outbound traffic uh but that's not you know that's why that's great we can actually do better and prevent these calls from being made in the first place so let's see how we can do that so if you're following along on the Hands-On lab you can go to your actions tab and look for the network monitoring so under hosted Network monitor Network filtering with hard and Runner so you should see a workflow there Network filtering with hard on Runner and if you look at the workflow you'll see that in this case uh you know on line 10 the hardened Runner action is being used in addition you have a egress policy block so when you see these insights you also have a policy which is recommended based on the calls that were made and that policy has been set in here now obviously attacker.com has not been included here and the idea is that when you do a baseline you know everything that you see there should be as expected and if not you need to investigate so here this is what we expect you know uh calls for this particular workflow so that's what's been said in the block mode and now let's go ahead and run this workflow so hosted Network filtering with hardenedrunner and what should ideally happen is that you should see the call to attacker.com getting blocked so let's see what happens now yeah so here you can see that the npm install step has failed and you can see that there was a connection refused uh uh you know in the error in the build log so if you go back to your uh insights page you will see that there is a Arrow here which is view all runtime security insights uh you can you can click on this and this will actually show you a view of all the workflow runs across this repository you can also look at them across your organization and get a security runtime security summary so here you can see it says one blocked call and if I click on this uh you can see that this call to attacker.com has been blocked so if this you know this kind of tech was in place at the time of the code breached thousands of customers that got their credentials exfiltrated this would have been a call to a direct IP address which would have been blocked and all of that could have been avoided so that was the lab for Network filtering uh there you know there is another part here around running this on self-hosted Runners but you can't do a Hands-On lab for that so what I'll do is I'll come back and if this time I can do a demo but let's continue the lab and let's do the lab for file monitoring so to do the lap of file monitoring on the left side you should see a file monitor source code.md so you can click on that file which has the lab for detecting file tampering during the build so again if you're following along this is Monitor Source code.md it's uh couple of files above the one where we are we were at initially which was a strict outbound traffic so you can click on this monitor source code.md and let's do a lab for detecting file tampering now here the first one is file monitoring without hardened Runner but you know as you know there isn't any monitoring by default on a CI CD server or a build server and we've already seen that when we did you know this network monitoring without Hardware so let's not run this because all it's going to tell us is that there are build logs but you're not going to see any insights let's follow this one which is file monitoring with hard and Runner so to do this if you go back to your actions tab you should see one which says hosted file monitoring with hard on Runner so you should see this workflow file monitoring with hard on Runner and this is the workflow file here so if you want to look at what's happening here you can click on that and here again on line 9 we have the hardened Runner GitHub action it's being run in audit mode and so let's go ahead and run this file monitoring with hard and Runner and let's see what happens right so in the uh Network scenario we saw that there was a call to attacker.com and in this file scenario let's see if you can spot something interesting so I'm just waiting for this workflow run to finish because the insights become available after it finishes yeah it's taking a little longer to publish to the registry for this one for some reason foreign this is the the curse of the live demo it always feels like it takes forever when you're doing it um uh but while we're waiting for that we could uh uh answer a a couple of questions while this is uh this is happening uh and one of the uh one of the questions that uh has come up that I figured it will come up is uh does step security support or plans to support other CI CD environments other than GitHub actions um yeah so we definitely plan to support uh you know additional CI CD providers um and you know we are in fact looking for design partners and early adopters so if you are interested in that you know definitely reach out to us excellent uh I see my dancer I'll disappear again yeah so so now let's uh you can either click on this link which is under the hardened Runner step or if you have these insights open you can go back and yeah this time I actually didn't see uh a file modification which is uh interesting maybe I don't know if I ran the right one file monitoring with hard and Runner yeah maybe it is on it again I don't know if anybody saw an event for there but what you should see here did you are you looking at the correct inside page so if you go back and refresh the page uh the inside page if you go back and refresh it I want to make sure that we are looking at the correct inside page yeah we have to write one actually I can maybe show this from a few hours back so in here uh you know you you can see that there is a file that's being shown in red color and this is what should have happened in that demo so this shows up when a file has been overwritten during the build process so in this case the index.js file has been overwritten during the build process which is not typical of a release workflow so when you are doing a release workflow your source code gets downloaded on the build server and it shouldn't really be changed after that but this is a an attack technique you know which is uh which was used in the solarwinds breach and in fact in another one called event stream incident where the source code is modified on the build server because this is really hard to detect you know you would find that your source code is the same that you know in the repository hasn't been altered but it has been altered during the build and the only way to detect this is to actually do real-time file monitoring so this is you know what should have come up let me see if this has run again yeah it's still not come up but uh not sure why let's let's look at the you know the simulator again so if you're curious why that file is being modified uh it's because similar to the exfiltration simulator there's actually a backdoor simulator and in the in that case there's a compile.js file which is running as a pre-installed step and and that is what is overwriting the index.js file so that was uh you know the the lab for file monitoring and um what I'll do is I'll just take maybe a couple of minutes to show how this looks like for a self-hosted runner and you know in terms of the cicd Native firewall what what does that really mean so um let me go to the actual GitHub actions code projects on the GitHub actions code project we have a self-hosted Runners using actions Runner controller you know which is a way to run self-hosted Runners on a kubernetes instance and that is you know gaining a lot of popularity across different CI CD providers where you can actually run your Builds on a kubernetes cluster and different jobs on you know on a different pod and then that pod gets deleted so the advantage you have for a self-hosted runner is that you don't have to add the the hardened on an action to each job you know you just install uh what we call as the arc hard and Runner demon set on the kubernetes cluster and it will just automatically monitor both file and network events so this case you can see that there's a self-hosted runner it's running on self-hosted you don't have the hardware GitHub action but still if you look at the insights you know they will look just the same and uh you know the hardened on a demon set is able to which uses ebpf on the kubernetes Clusters able to do the same kind of file and network monitoring and also Network filtering uh yeah so here again you can see the call to attacker.com in addition because you own the infrastructure you own your kubernetes cluster you can also set up a secure by default cluster level policy which applies to all jobs across all workflow so you can have a default policy we do have a demo here where the default policy does not allow calls to direct IP addresses in in this case there was a call to a direct IP address you know which is again common for uh attackers to use to evade DNS monitoring and in this case because of the secured by default policy on the kubernetes cluster that applies to each job this call is actually not allowed so uh you know again these labs and these demos for actions Runner controller they're all available on GitHub access code so you can come at any time and you know have a look at this you can Fork the repo and try the labs cluster recording will also be available so with that I'll go ahead and stop sharing and you know we can see if there's time for more questions awesome there we are uh all right question time so we have uh quite a few questions uh thank you so much for that it's it's really a treat to get a Hands-On lab uh in these and again I I know that it can always be a little bit tricky if if you miss a pass and uh you're not sure but uh like we've said before we can uh we will we will be sharing the recordings but let's have a look at some of the questions uh that we have uh and uh go ahead uh okay the first one how how does the network filter of hard and Runner work is it DNS based and could it be bypassed uh I.E directly uh talking to an IP yeah so the the network filter you know it has a DNS filter as well as uh you know a firewall for direct calls to IP address so one of the techniques that attackers uses DNS exfiltration right so if you try to do that the DNS uh you know proxy is going to block that and if you try to make an IP call to a direct IP address which is not in the allowed list of the of the DNS names then that will also be blocked so the only IP addresses that are allowed are the ones that resolve the domain names that have been allowed that's why in the for example in the uh you know demo for self-hosted you could see that in fact the secure by default policy itself doesn't allow calls to direct IPL so it has to be something which was in the allowed list for the domain got it I got it uh here's an interesting question one that I've had too by uh Maurice uh our self-hosted CI CD platforms a little bit more secure what's your opinion yes that's a that's an interesting question you know what we've seen is that a lot of Enterprises especially the ones that are security conscious actually use self-hosted Runners so I mean you can use any platform for example even GitHub actions allows you to use self-hosted uh but we've definitely seen that enterprises you know that our security conscious tend to use self-hosted uh one of the reasons is that when you use something like GitHub Enterprise server you know you can't actually use the hosted one and the other is that self-hosted actually gives you more control over your hosting environment you can choose your build image with you know which can have uh very few tools installed the only ones that you need and as you saw with the uh you know even Network and file monitoring you have more control you can you can monitor all the jobs that are running without having to change each of the workflow files so from that perspective you know you certainly have more control and that more control actually gives you more Security on a self-hosted runner got it got it really interesting probably some people that will debate that but I certainly uh I certainly can't argue with that there uh we have another one here uh that relates uh to to to the labs uh when the call to attacker.com was blocked did it stop the npm install for just that malicious package or did it stop the npn install for all packages even the legit one so basically you know did I think did the build fail completely yeah so in this case you know npm install failed uh because of the way the pre-installed step was written but you can certainly write a pre-installed step in a way that will not cause the bill to fill so in this case what hard-on Runner does is it blocks the outbound call which is not in the allowed list but it does not necessarily fail the build right so you could have a you know uh scenario where the outbound call to the malicious endpoint is blocked but the build still succeeds got it got it interesting um a couple more how are we doing for time oh we're coming close to the end but maybe we'll fit in one more one more question here uh before we do it but the how do you perform security assessments for Network Services EG load balances reverse boxes that are integral to part of the CI CD infrastructure I'm not gonna lie this is a this question is above my pay grade but I'm hoping that you uh you can uh you can make sense of this yeah I think you know uh for for infrastructure which is uh part of cicd you would typically look at it as infrastructure which is part of your Cloud uh you know deployments itself and it's it's really important to give the same kind of if not you know more importance to the CI CD infrastructure a lot of you know a lot of times organizations tend to ignore that they just focus on their Cloud deployments uh but the way to perform security assessments for you know the cicd infrastructure uh should in large part be the same now there are certain things which are specific to cicd like you know the kind of solution we've built is specific to CI series purpose built as you know EDR and networking solution but for a lot of the other infra you know you would just apply the same principles that you apply to your Cloud security excellent wow it's a uh some great great responses there I'm sure everyone found that valuable well we've come to the end of of this webinar so I want to take a moment to to Really uh thank you both for being here again this was a fantastic webinar this was actually the biggest webinar we've ever done with uh nearly 1 400 people registered so uh a very I'm very happy to to have done this so thank you everyone uh for participating it has been uh really special uh really great uh and thank you again Iran and um and Ashish for for being here I'm sure everyone really enjoyed it the slides are available if you if you contact us the recording will be available to everyone that's registered so you can go back and watch it again so one last time if we can all give a big thank you uh to our special guests from Step security or and before I forget I have one other thing in the polls uh there is a another poll in there I just created saying do you want more information from Step security if this was really interesting to you and you want to find out more and particularly if you want to find out more from property at Enterprise level please uh answer that yes so that step security can actually reach out and and provide you some more context and and more personalized information so in the poll section there you can vote yes if you would like step security to to to reach out for you uh directly uh again so um and we already have a lot of people that have said yes to that so that's great uh that's great to see uh there is a no option there don't worry you don't need to click no but uh but uh yeah please please feel free to make sure that you do that sort of Step security can reach out and with that being said we've come to the end thank you all for participating thank you again veranda and I look forward to hopefully doing another webinar with you again maybe we can get to 2000 next time so thank you thank you both thank you Mackenzie thank you thanks everyone for joining