Transcript for "Learning Labs: Securing CI/CD with Chainguard":
Hello, everybody. Welcome to Chaingard Learning Labs, April edition with me. I'm Erica Heide. I work as Deborah here at Shein Guard, and we will be starting in a few minutes. Let's just, see if more people are coming. In the meanwhile, can you share where you attending from in this chat? So I'm attending and presenting from The Netherlands. The Hague one precisely. Hello, Tony. Justine. I see Atlanta, California, Seattle, New Jersey, Quebec. Wow. Nice. Lots of different places. Aberdeen Proving Ground, Shell, Lotusville, San Marcos. Nice. Very cool. K. Let's just just give you a couple more minutes, and then we can get started. So how are you feeling about your CICDs after so many incidents recently? Right? Yeah. It's been a tough few months. K. Let me prepare what we're gonna do. We're gonna do a little demo also. So we also have, time for q and a at the end. So I will be presenting and then you can use the q and a tab of the chats, or you can also ask on chat and then we will go at the end and look at the questions. London? Okay. Someone else. Okay. Sacramento, California. No one from Brazil yet so far. Curious fact, I'm from Brazil, so that's why I say this. Someone else want okay. Reading. Cool. Okay. Puerto Rico. Nice. Okay. So now I think we can get started. So three minutes. I think that's really okay. We can go with the introductions and all. Right. So welcome again to those who joined in just a few minutes ago. And so today, we are at the April edition Shengland, learning labs. I'm Erica Heide. I work at Stavrel at Shengland. I've been here for four years, and, yes, I've seen a lot. And this, last year was really incredible in the sense that lots of things changed with AI assistant, step coding, and all the new incidents that we've been seeing, CICD, GitHub Actions. So we thought it was a good, topic to talk about, provide some, assistance. And so today, we are presenting security ICD with Chingart. And so this, talk will, let me go to the next. Yes. So we'll start with a timeline of, recent CICD software supply chain incidents from the last year. So we are gonna see things from March 2025 to March 2026. It's already it's likely outdated because new things happen. This is not of everybody. But anyways, it's for Provenio points. And then we will unpack the three b compromise, and I will do a secret exfiltration demo. We'll try to reproduce the first attack, the first compromise with, progress targets. And then, then I will talk about how to mitigate those risks, and we'll talk a few strategies that are, like, common sense for everybody to follow. And I will also share how Chingart can help with these things. And then we have some resources and Q and A at the end. So let's get started. We start with a timeline of, CICD software supply chain incidents, And I will talk a little bit about each of these to give you an idea of, what we are what we are looking at. Right? So in March 2025, the first thing that's, became the news was actually the TJ actions change at file was the incident that actually made the news, but it's all started with the action setup, the review of dog action setup compromise. And then a lot of things unfolded, from there. So the review dog action set up compromises in March 11 around March 11. And so the attack had compromised the review dog, we have org, injected credentials in payloads into action set up. And this was the upstream dependency that actually made DJI actions, the attack possible. And this was a classic cascading supply chain compromise. So the first, compromise the action setup from review doc, and then that led to the DG action, DG actions, change of files, compromise. This was a few days later. Then what I did here, they all the texts were, real retroactively repointed to a malicious commit. So, these malicious commit would, dump CICD memory to logs, and over 23,000 repositories were affected by the TGA actions changed files, exposure. Secrets were exposure exposed for, like, fifteen hours about that, And, it was originally, a targeted attack on Coinbase that cascaded broadly. So more than 20,000 repositories affected after this one. And then we had, jumping to August. So I'm not including everything that happened that year, but these are the most relevant incidents, Evo supply, software supply chain in CICD specifically and especially if we have actions. So the similarity and x already in August. So they exploited a pull request target. So this is the pattern that we'll see a lot in a misconfiguration and x repo, and the that's, allowed them to steal an NPM publishing token. So that's great for them because then they can spread malware on the NPM ecosystem. Right? So this was the first known supply chain attack to weaponize AIC CLI tools. It, used a prompt injection, to search for secrets of witness, on the witness machines. And then, we go to the NPN package hijacking. So, 18 popular packages including shout and debug, hijacked via phishing campaigns. So this was, phishing campaigns were used with the maintainers and billions of combining weekly downloads affected. So a lot of people was, many people were affected by that. And, this was like a this provided actually the initial pool of compromised tokens that seeded the shy, lukewarm that comes next. So one thing is, building for the next. And then the Shiloh would warm the first wave became very famous. This was in September, and it was the first self propagating supply chain NPM supply chain warm. It compromised more than 500 packages by automatically injecting itself into every package a victim maintained. It used a truffle hog harvesting and shared, tactical patterns with the Singularity attack. So it was very similar, but much more sophisticated and self, self, spreading. So Shylen, rude, warm name, we had the Shylen, rude second coming. Self replicating also. So, the first one was, post installed hook, and then the second wave used a pre installed hook. The second wave, added GitHub actions, self hosted runner exploitation, and harvested cloud credentials. The focus for the second wave was really cloud credentials, AWS, Azure, GCP, and there were more than 700 packages affected by this one. And then we come to the three d initial breach. So this was in March. And, as you may know, there was a campaign, with HyperBot cloud and autonomous bots. So it's exploited a pull request target misconfiguration to steal, a personal access token, and that led to several other things that I will explain in more detail in a moment. So yeah. And then after that, we had this second compromise that was actually the full, chain compromise of the three b software. So, yeah, this is all, we've seen in the past year and, like, there were others, but these were the most compelling ones. Like, what made the news in like, there's a clear, evolution of, text and becoming more sophisticated. And we also see these, the rise of the targets, the open source as a target. The CICD is a new target because, it's it's, in terms of cost benefit for exploitation, gated software, you would you why compromise one only if you can compromise, on open source project that are it's used by millions of people, meet thousands of people, wherever. So a single dependency can infect thousands of projects. And what open source workflows are already exposed on the GitHub actions workflows. They are all public. So you can see all the the the workflow, and you can find vulnerable targets there, fairly easily nowadays with, AI assistance. In CICD, when you get these two elements together, open source, open source workflows, public workflows, and AI assistance, and CICD together with secrets, API tokens, deployment credentials, and VAT. So this is the perfect, space to be exploited. It is the perfect target. And we also seen in 2026 being the year of AI assisted attacks. There is the blog post from my colleague, Patrick Smith, that is very good. You can have a look. There's a link there in our blog. And it goes down drills down the change we've seen in 2026 because, it's there is it's clear that the cost of exploitation is going down. That, makes the time to exploit window collapse. We, use it to see in 2020, for instance, there was a seven hundred forty five days window, from the time and exploits the time between a vulnerabilities disclosure and the first observed exploitation. So this is the time to exploit this measurement, let's say, this measure. And, this was seven hundred and forty five days in 20020. And in 02/2025, it went down to forty four days. And now we are seeing negative numbers in 2026. So, which means that, 28% of CVEs are exploited within twenty four hours of disclosure. So not off the patch, but for disclosure. If we are seeing a window of, like, about seven days of exposure without a patch where exploits are already used in the wild, and there is no patch. So this is becoming critical. The time to patch is much higher than the time to exploit. And it's easier than ever to go from researchers' proof of concept to n day exploits. So an end day exploit different than a zero day, it's a exploit that is already published, the vulnerability that is already published. So, rather than spending resources on original zero day research, the threat actors are simply leveraging known vulnerabilities, but unseal unpatched because there are so many. And instead of trying to find a zero day, you can exploit that end day now. So that's the trend. And so, let's unpack the three d compromise. What happens? Why and how? And this is, something that really caught my attention. I was really impressed because I didn't know that it it was possible to compromise a repository with a pull request only coming from a fork and make it run your code. I did not know it was possible and to steal your secrets. So, I really wanted to know more and I started researching. And my goal was to reproduce that, so we'll see that in a moment. So, let's see. On the right, there is, like, a timeline of everything that happens. So first, we had the HyperBot cloud, opening a PR to Trivy, and that is, the PR introduced it, exploited the pull request target workflow. It's a vulnerability that was in the workflow. A design, arrow, let's see. And so what happens? When you have the pull request targets, it runs, if you are running code from the, the pull request, it will run the code with the context of your main repo, with all your secrets, tokens, everything. And so when, what they did was they introduced a crawl batch line. So they created a PR that introduced that line. Of course, nobody would accept that PR. It was clear that it was executed unknown codes, but it didn't matter because, the workflow would run that code with the context of the main the pull request targets, context. So that way, the org repo token was exfiltrated. So there is it's it's small. It's a bit hard to see, but if you look at the slides later, I will share this slide, and you can see, the details. So there was one of the steps on the workflow. Shares a uses a GitHub token from a personal access token that has org wide privileges, which means that with this PAT, with this personal access token, the attackers could do anything in the whole three d org, create repost, delete repost, and that's exactly what they did. They moved the three d repo to private, created a new public repo, and deleted years of releases. They did a we did, made a mess, really. So, then Aqua disclosed the incident and rotated credentials, and we thought it was all good. Everything was fine. But the problem is it's very hard to, rotate the credentials in a atomic way. While you're doing the process, the attacker might be able to get access to another PT and and create another one. So it it can be difficult. All we know is that something didn't, work right. You know, it was not atomic or it was not complete. They retained credentials and then, they were able to spoof maintaining commits via the Apple bots account using these credentials, created fake commits, and they were able to hijack the tags. So 76 of the 77 tags that are in the repo were hijacking. The three d action, what you something that we use in our workflows to scan our images, run times. So they hijacked that the trivia action tags. Anyone pointing to those stats on their own workflows would get, exposed. And they also distributed a binary that was not actually in the source code. It was not in the repo, the release. It was a ghost release. And, they were able to deface all 44 repositories in the org. And yeah. So it was a full multichannel supply chain compromise. From a pool request request, targets vulnerability, they were able to compromise the whole three d org. Yes. Which is, very bad. Right? And I thought, well, it must be very hard to do that. Let's so let's see how hard it is. Can we reproduce the initial compromise? So what I did was I created a dummy scanner. So I've I've coded a scanner, a GitHub x to run on GitHub actions, and the goal was to comment on a PR if the file number changed. So it's a very simple goal script that just counts the number of files in the, the projects. And then when you open the pull request, it compares the old and the new and creates a comment. And then I asked the clouds to create a workflow to run this action and comments on my PRs. And then cloud created the workflow, and he, he cloud it. It's created the workflow and use it for request targets. It did not alert me of anything of any possible vulnerability or anything that I should worry about. It created a pull request targets and so that the action runs with write permissions even on PRs from forks. And that's the big deal of the PR the pull request targets, trigger. So yeah. Created that. And so this is the workflow it created. It uses the pull request targets, and it sets rights, permissions for the jobs. And on the action, the step that I have to create the comments on the PR, it needs a GitHub token. So it's using the GitHub token from, GitHub actions bots. But in a real case scenario, usually, you would have a PHE here to use a bot. For instance, I would create a dummy bot, a dummy scanner bot, and that's how it was for the Trivy, compromise. They use the they use their PT from the Trivy bot, the AquaBot. So here, I probably create user PT for a bot here. So that would be another, token for an actual account and not the GitHub actions bot. And I also have here two dummy API tokens that I put there just to make sure that I had get the value back. So this is like the secret to represent secrets that you usually pass along as a virus to your, workforce. So we have, these details, and I will show you more in practice how how how that's, will work. But yeah. And this, so the other thing that there's a box bread box here is highlighting the call, the execution of the code from the head branch. The head branch is where the PR where the commits are for the contribution, while the base branch is where you the target, the main branch, the actual name from the Legit's repo. And then I come with a PR and I'm sending the head branch. And I'm running code from the head branch in this workflow, which is not, secure at all. Cloud did not alert me from anything. It just created it and it vibes and it works, and it was fine. So, yeah, the pull request act, as I mentioned before, executes with context from the base branch, which is simply your main, including secrets and tokens. And when our workflow like this runs code from the head branch, the proposed code will run with access to secrets and tokens from the main repo. You just need an exfiltration scheme here. So the this way that the workflow is set up, all all by clause, I didn't do had to do anything. I only need an an exfiltration. So, yeah, run a script, send my aims, send the aims that I get. So how how easy it is to exploit? Let's see how easy it is. K. So I made something called setup scam, and I'll show you actually in the demo, which is better. I was able to create a four, create a pull request and get the the secrets from the dummy scanner. So I will show you in practice. Let me change my screen here. So this is, I'm logged here on GitHub with my accounts. Let's say that is, like, the the legit scanner. The scanner here is, the only problem is the workflow, it's vulnerable. But the scanner itself doesn't have vulnerability. Let's see. The I'm gonna go in the secrets. So I you you are sure that it's not like us. I'm not, fabricating the things. You go to, secrets and variables, actions. So, like, it's like a CTF thing. So these are these two are the tokens that we want to obtain. These are the secrets we want to execute. And I will put a new value here just so we, someone type something on the chat, please. Random, like, screens a string that I can put here in the variables, please. Who's gonna share something? Clone Wars. Okay. Clone Wars. Thanks, Danielle. Okay. Oh, just a moment. Okay. Security. Yes. Okay. Updated the dummy API dummy API token is updated, and I'm gonna update dummy token secret as well. Let's see. What should we do here? What should we save here? Okay. Something something. Okay. So I updated these two so we can do everything from scratch. So I'm gonna go now to my other GitHub, my hacker GitHub. So what I'm gonna do is I'm gonna create a fork of the dummy scanner. So this is the original one, original one from Erica Heidi, and I'm Boracat mom now. So I'm gonna fork this. Because I already have a fork. So I'm gonna delete this. I have to delete this first. Because I need the test before, of course. Okay. We can go back to dummy scanner. No. Not this one. The original one. Yes. The scanner, I'm gonna, fork it. Okay. Create four. Just regular stuff. And I actually have the code here that I want to execute. So it's actually I just one init function that we want to introduce in the codes, and it's gonna be in the main dot go. So I can edit this file right here. And yeah. So I'm gonna add this function here. This is gonna run it's it's the same thing as the curl bash, thing. So it's gonna run curl. To download this, I'm gonna show you how this runs. But, essentially, I registered a domain, and I got a VPS to run these. Yeah. I'm sure you in a moment. And then we need to also import the o s a sec here. Yes. So I'm gonna commit the changes, and then I will create a new pull request in a moment. So you can create a can create a quick rest here. But first, I need to run my server. Otherwise, nothing was gonna was going to happen if I don't run my server. So, yeah, let's go to the terminal now. So this is where I have my, exfiltration code. So setup's gone. I've white coded everything also, of course. The data dot t t x t is where I have the results, actually. So, essentially, it's a shell script, a shell script that makes actually the actual downloads and then runs and sends the the stuff. So the actual script is set up scan. Yes. So this is the the actual scripts. What it does, it gets all the antivirus on these the current environment, and then, it posts creates a post to a URL, a a defined, runtime defined URL. So this is how it I call it. This is the the thing that I'm gonna curl batch, that I'm gonna download and execute. And I have a server, of course. So the Python server serves the malicious script, the exfiltration script, and also serves, the data dot t t x t file that has the results. And yeah. So we really just need to run this server. So it's listening now. Now if I create a pull request, I will get a, request here because I added the code on the on the pull request. So let's create the pull request now. We are here. We will open the pull request. So, Nafi, when I click the create pull request, button, then the CI will kick up kick off, and then, the workflow will be executed, the the vulnerable workflow, and then we'll see what happens. K. It's just our change here from a forklift repo. Create a request. Okay. So this is the workflow now being executed. Set up go, run test. So we won't see anything here, actually. That's the also dangerous thing. You don't see anything in the output from the logs here. I could output something, but, it didn't. Okay. So it did scan. And now, oh, we got some hits. So you can see that we got quite a few hits, here. This is all executed by the GitHub actions, runner. So what we help we got, because it does it scans the main, branch and then scans the head branch. And so there is a get for the scripts, the bash curl, the crawl batch, and then it's posts the results. So we have, three pairs. Let's see what we get now. So I can close this, and then we can actually do a text dot t x t. And then we have to find here our stuff. But yeah. So I have a ten time stamp here in the IP. This is from the GitHub actions runner. And let's see if we can find our stuff. We have event prep, we have end, retention. Yeah. Maybe just do a bread. Right? Because that's too much. And, also, we have a few different, hits. So we need to find the one that is the right one. Let's grab for dummy. Yes. Here we found it. Dummy API token, Clone Wars. Dummy token secret. What should it say here? Okay. So this is the secrets that we just defined in the legit scan repository, and all I had to do was exploit, the vulnerable workflow. And there are many vulnerable workflows like that, out there also on GitHub. Yes. So let's go back to the slides. The demo was successful. Slides are here. Yes. Okay. And let me find my notes. Okay. So we are back to these slides. Dina can explain a little bit each thing. So as you can see, it's this is from a four. So there's nothing you need to do. I don't have permission to obtain any of these these variables. And then I just needed to add a function here. The PR was closed. It doesn't matter. The code is already executed. The secrets are already exposed and exfiltrated. So here is just a print because I run this before, of course. So dummy API token, dummy token secret, these are all, secrets that I have defined in all my action secrets that should be completely inaccessible in secret. And the GitHub token, this is from the GitHub actions bot. But as I mentioned, usually you have here a GitHub token from the org, from a maintainer with more permissions, sometimes to, manage tags, manage releases, and things like that, auto triage issues. So usually, people use a personal access token for that with, lots of missions. And then this is how we can get extra traded. And from here, what could unfold, right, based on everything we saw? An attacker publishes a new version of the software. So now I get the GitHub token. Let's say I have a token that is, like, Triviz, has a org wide permission. So it doesn't even if it only has, like, a repo permission, it's already a lot because then you can release a new version of the software, and include the malware exfiltration code so it propagates to anyone using that action or that software. And you can maybe you do a little bit more sophisticated. Of course, mine was not obfuscated. It was just a proof of concept. But, yeah, it will be a bit more, obfuscated, more hard to notice, maybe. Attacker hijacks all the tags, so it will overwrite tags that are have been published before. So your versions that were should be safe. They will all points to the same temporary version. Then any workflow referencing this GitHub action by tag, you'll get them more aware and then we'll get it their own aims extra traded. And then the attacker can use those aims to ex to, spread more widely, ex and compromise all the refills. And, then, usually, they will look for high visibility targets, repositories that have that are used by many people, by many projects. They will also look for NPM tokens that can use to effect JS packages and spread through the NPM ecosystems and they the ecosystem. And they will also look for Docker Hub credentials that they can use to publish compromised images. So that's a lot they can do with some, personal access token. And then you get a full multichannel supply chain compromise. It's not GitHub actions anymore. It doesn't matter if you you if you don't use GitHub actions because you will download the software artifacts that will has been produced in that pipeline and has been tampered with, and and you'll be compromised anyways if you don't pull from the right sources. So yeah. Now, we talked a lot about the incidents and, even the demo was not to make you scared. It was to show you how how real that that that stuff is and how must, how seriously we have to take that, the CICD risks seriously. And so now I'm gonna talk about strategies to mitigate software supply chain risks in CICD. I will share some best practices and also how Chainguard can help you with that. And so number zero is not give me number one. Number zero, items, namely zero action that you have to do is to, do a repository inspection, look at your repos, and inspect your repos for insecure defaults. Things that are there by default, they just forget about it, and then it's not safe. So first, of course, you have to check your usage of pull request token as a target in your workflows because of everything that we talk here already today. There are legitimate use cases probably for the pull request token, I think. But, you cannot have it together in a workflow that executes code from the head branch from the branch that is proposing the pull request because then it makes it really easy for an attacker to introduce some, malicious codes in there. If you really need it, then you have to find a way to, block pull requests to only get requests from safe, from retainers, the trusted maintainers. And even that way, it can be, still vulnerable. If one maintainer is compromised, then people can get still to the the the thing. Anyways, so the other thing that is really, not a good practice is long lived tokens. Unfortunately, it's the easiest way to set up these things, these kind of automations. So we do that a lot. Everybody does it. Create a pool, personal access token to do some, operation on the repo to help with maintenance triage. But they they are very insecure because usually they have broad privileges and allow allow, rights permissions. And and also, yeah, you forget about them. That's the the main issue, I think. Most of us set up a personal access token before and then just forgot completely about it for years, for projects, for accessing the API, for something small, and then you forget about it. That happens a lot. And other thing that you have to be aware is, direct shell execution with some kind of input that can be manipulated by external actors. So it's like the curl bash thing, but maybe you are executing in a run statement of codes that, has a variable that comes from, inputs on it. GitHub actions or something that can be manipulated. Sometimes even the branch name can be manipulated and be used to, change the the execution line. So you have to be aware of that. You actually also, action spin by tech. I'm still gonna talk about these in more detail in a moment. But this is also a bad practice. It can be really insecure. You, understand in a moment. Also, unprotected main branch and unprotected release tags. And these are related actions being in by tag, unprotected main branch, and protected release tags. These are related because an attacker that gets access to a personal access token, as you just, talked about, will, create a new release, will overwrite existing tags. And then if you have an action that is pointing to a tag, it will be, vulnerable anyways, even if it's an older tag that is stable. And then, as a maintainer, you have to protect your branches, really do this, create branches and tags rule sets in your repo. So you, you don't allow to the text to be rewritten, to be, overwritten. So you restrict the updates and deletions. You cannot delete, releases and cannot, change the release. So, there is also a a heard about immutable releases before, for GitHub, but I don't know how that's going right at the moment if it's already a feature that's already available for everybody. But that would be also very, helpful to mitigate this, specific issue of tag tag hijacking. And then, number one now because it's, so the the other stuff was, like, zero because it's, like, critical. But now number one, minimize attack surface. When we talk about software supply chain, minimizing attack surface is one of the simplest practices that you can do. And it's like it might not be simple in practice or easy, but the concept is very simple. It's very simple to understand. You have to to limit, what you have available to be exploited. So to protect, artifacts from vulnerabilities that are not introduced directly in your source code, you need to reduce the the the blast radius you have. So it's just that a low hanging fruit, So you cannot ignore that. You have to think about direct, and transitive dependencies. So dependencies that you have directly on your code and also, the dependencies of your dependencies at the ecosystem, at the language ecosystem level and also at the OS level, the runtime environments, everything that is running there, to assist you, in your in your application, life, cycle. And, any we think in that chain can be used as a foothold to obtain access. So the main idea here is not to remove functionality. It's not saying here that I'm not gonna use it open source anymore. No. That's not possible. But it's to remove what doesn't need to be there. Your application will keep running the same, and, you don't need all that stuff. And, Chingart containers, when we developed Chingart containers, we designed this was really the main focus was to do this work, to reduce the attack surface, to create container images that are low to zero vulnerabilities. This is a comparison of our Go image. On the left side, you have the Shein Guard version, which, currently has zero CVEs. And the alternative is the default image you get from Docker Hub. It has over 200 lunar gazes. And, surely, some of these are medium, are low, but there are some highs also and sometimes some critical ones. And, all these any of these actually can be used as a foothold and combined with others to, create the the the right, situation for exploitation. So, of course, it's, there's not much to talk here. You have what do you want? You want to run your app on a base that is full of vulnerabilities or you want to run your app on a base image that has zero vulnerabilities. I think it's I don't need to answer that. Right? So our customers were protected from the three d supply chain attack, for instance, because, we have a true image, and our true image was not affected because we beat our packages from source. And most of the tampering happens at build time distribution. Right? We'll see in a moment also, something about that. But yeah. So, and as I mentioned before, it's not just, I'm not using GitHub action, but you are using other software with an images that, are produced in these, vulnerable environments. So you have to pull from, safe sources. And, actually, we have now a free offer for, catalog starter offer. Oops. Let me come back. Starter offer. Oops. Let me come back. You can choose five images from our catalog for free, and we have more than 2,000 images in our catalog. So for sure, there will be something for you there. We have also the free tier of images, which is more like a offer for open source and for small, individuals to test shingular containers. And that gives you access to, bigger, medium size a small catalog, I'll say, but contains all all the language ecosystems, databases, some application images, web hosting, Nginx, MariaDB, things like that. But you will only have access to the latest tag on the free tier. And with this offer, you have access to all the tags, but then you select five images and you have that for free. So it's a good way to, experiments and evaluation their containers before, yeah, signing up. So yeah. And then, we have, I just mentioned that, pull from those resources. So, the reality that we're living right now is that 98% of the malware is inserted during build and distribution phases, which bypasses regular review from containers. The vulnerable code is not actually on the source, code that you see on GitHub. Most of the time, 98% of the time, you won't see that because it is introduced at other phases and that you don't have access or and the maintainers also don't see that. So it can happen at the build time, at the CICD level, even on GitHub, but you won't have that visibility that you see on the source code, the vulnerability. And and also on the registries, so there is the ghost release gap. So attackers are exploiting the gap between verifiable source code and the opaque build at facts that you consume. We saw that, with all these, recent incidents, and you don't see the actual malicious code in the repo, but you see it's, coming up with the as an artifact, as a temporary artifact at build sign or distribution time. So, the attacks are shifting left and are focusing on turning developer laptops and CICD pipelines into nodes for propagation. That's what we have seen also. Shaihoo, and all these recent ones using developer laptops, your own environment, and also the CICD pipelines. So, with Shamgar libraries, we try to, create the same using the same concept actually for our container images and OS packages, which is pulling from source and building in our factory and providing those, packages from a safe source for our customers. So instead of, your developers picking up unverified packages off the streets, like, from any public registry, we do the heavy lifting for you. And then, we have all this, dropping replacements for your libraries that you commonly use your dependencies, and then you can just drop in and and use them, your developers. Instead of building getting, artifacts that are built and distributed by, sources that you cannot trust. So we are also not affected by the light, LLM, and tech because of the same thing. We build the packages from source. We don't run preimposed in some scripts, and then the our artifacts have, sign in, are sign in, have provenance attestations, and everything as bombs so you can, feel safe. And we actually have, also an offer for Shengan libraries for free until June 30. So you have, Python, Java, and JavaScript libraries, and these are verified from source, say, from the next supply chain attack. So you can use this QR code to get this free offer. So number three, I'll speed up a little bit because we're running out of time. I want to leave some type of questions. And so third strategy that is very important is ping to digest. As we see in recent CICD incidents, attackers with repository permissions often publish a new release or points tags from malicious commits. To infect both the people who use the latest tag and also those who pin by tag, any tag. Any tag, the most specific that you want to put, 1111.200.3. It doesn't matter because the tags can be hijacked, as we've seen, with many incidents. This is the first thing that they will try to do, especially for GitHub actions. So use digest instead. Instead of using a tag, you should ping your actions in containers to a digest. A digest is a unique hash pointing to a specific build of a GitHub action or a contained image. And then when a new version is released, your workflow won't be affected. It will remain using the same build, the same action, or the same container views, but it will also become outdated, of course. So with time, you have to update the digest, and we have a tool just for that. This is a free tool that you can use, with the GitHub app that you set up within your repo, digest the bots. It will it works like digestible, like, dependable, but digestible is for updating the digest. So it will keep your workflows and Docker files up to date with the most recent version upstream. And then you, it will open up a request if the digest updates, and you will have some time to review and test the changes before you, run the update without knowing, which would happen if you use a tab or a latest, something like that. So in by digest. And this is the the action, by the way, miss image digest update digest about. And then number four, ban PATs, new struct with tokens. Personal access tokens, they can give access attackers full access to a project repository or even the whole org as we've seen. So use short lived tokens, and we have something for that too. We have OptoSTS. It's also a free app, GitHub app that we created to implement this strategy. It uses the same concepts behind the historical sign for short lived tokens, but for giving you a token that is only temporarily available. And then it will, even if it gets executed, it will be rotated very quickly. So, attackers won't have access to anything pretty much. So it's a matter of installing the app, creating some policies, and then, yeah, we have docs for that too. You can look at the GitHub app that will have some resources on how to set it up. And last but not least, use chain guard actions. So we have a new product, Shengard actions that is in beta right now. So what it does, we how it goes? We start by looking at the full list of actions, but especially the most used ones, the most popular ones. Then we ingest these, actions in our factory. We review them against attack vectors. We have a rule book for that, and then we harden the workflows, push the actions to the verified actions to our repository, and then confirm the desired state has been reached, and then we make these available for our customers. And, so our beta rule book, like, in beta, I see we're still developing see the rule book is being, improved as new exploit techniques emerge. But right now, we evaluate unsafe shells, unpinning users, hard coded credentials, GitHub environment injection, suspicious run content, missing permissions and dispute injections. This is all, taken care of. And so we have these are the the main ones that we already have available, and it's really easy to set up. But, yeah, you have to wait to join our beta waiting list. It's not in GA yet. It's in beta. And we are already preventing CICD risk. So the, Entropix on file code action had a high severity script injection, a GitHub token interpolated directly into a shell command. So this could be, use it for a script injection. And our Houdini agent caught it and fixed it, documented the remediation automatically. And yeah. So in our, broader road map, we are going to be also flagging these issues so much. Right now, we're still in database and developing more our, partner agents. But, yeah, it's already calling get getting a lot of stuff, important stuff. And this is that you are going to join the better with list for Chingart actions and protect, your CICD actions from the next attack. So I have a TLDR here, but I we are on the outside, so I'm not gonna repeat everything. Chinga contains Chinga libraries, Chinga actions, digestible, and Okta SDS. Here are five things that Jingua created that can help you with, handling your CICD, yeah, making it secure. So I have here a few things that I'm gonna run quickly. And what I suggest is, are there any questions? That you if you have any questions, you leave them in the chats now. You'll find a way to answer them even if, we run out of time, because this link will still be accessible after the events. We can, watch on demand, and then you can, see any, answers to your questions. And I wanted to share something really quickly. On May 16, we have securing the AI era, no more ignoring our problems, is a webinar with our CEO, Dan Lawrence, and cofounder, and also Nick Chaelon, founder of SSH. SH. Yes. And our next 30 laps will be on May 28. It's gonna be building safely with AI from code to production machine guard. And this is gonna be a nice one in two parts because a lot of content that we are gonna cover. Probably you will see me again. Still finishing the details, but you can, keep an eye on events.shengard.dev for, when we get the landing page release, and you can register. Okay? And yes. Thank you. And now if you have questions, now is the time to share them. We still have, some minutes. If you, can stay for a few extra minutes for q and a, that's fine. Thank you. Thanks, Geralyn, Sima, Simon, Joshua. Thank you all. And I don't have here a PR code, Christine. Do you have the link for a shared community maybe? It's like community. Because then if you have questions, you can, also use our Slack community to to ask your questions, and we can keep in touch there. I'm there also in all the DevRels. I will find the link, and I am sharing here. Let me oh, yes. Christine found it. Yeah. Yes. Amazing. Thank you, Christine. Okay. So you can join our Slack community, and we if you have any questions or any help with your GitHub actions, our flows, any tips, then, you can join there. Find me there in the under that Rails, Patrick, Muffreids, Kelly. Right? Okay, folks. Then I will say thank you and see you next time. Thank you for joining today. It was really nice. I love doing the demo, and I'm happy that everything worked fine. And yes. So I won't take any more of your time. I'm already run a little bit late. Have a good, rest of your day. And, yes, see you next time. Bye.