[0:00] – Hello, everyone. [0:02] We are very happy to be here today, first time at RSA. Okay, so this is us. [0:11] So short introduction. My name is Eyal Paz. [0:15] I am managing the research group at OX Security, which is an ASPM company. [0:22] Prior of that, I spent a while solving...
[0:00] – Hello, everyone.
[0:02] We are very happy to be here today, first time at RSA. Okay, so this is us.
[0:11] So short introduction. My name is Eyal Paz.
[0:15] I am managing the research group at OX Security, which is an ASPM company.
[0:22] Prior of that, I spent a while solving network security and endpoint security problems and a lot of work in the threat intelligence operations.
[0:34] – Hi, everybody. I’m Liad. Thank you all for coming.
[0:37] I started as a script kiddie back in the days, went on learning, finished my masters in computer science.
[0:44] Now I’m on the other side, building detection systems from PoCs to production. I enjoy.
[0:53] – Okay, so before we delve into our research, I want to describe for you a bit about how we came to this research topic.
[1:05] So the open source ecosystem is quite huge.
[1:09] There are over 5 million packages all combined in the public registries.
[1:16] The most, the biggest one is npm, which is the most common of the JavaScript ecosystem.
[1:22] And we got a question by one of our customers asking how they can actually manage
[1:30] those open source packages in the sense that some of them might not come from the public registries.
[1:38] So this made us thinking if already today the ecosystem is very, very huge.
[1:46] But, and it’s also very, very targeted.
[1:51] And threat actors see the public registries as their playground where they can publish
[1:59] their own malicious packages and put them as baits for developers to integrate them into their applications.
[2:08] So this ecosystem is quite huge, and this is only the tip of the iceberg.
[2:15] And this is what we are going to discuss here today.
[2:19] So let’s pause for a minute and discuss the process of how these open source packages actually reach the registries.
[2:28] So usually it starts when a developer or group of developers think that they have problems that they want to solve.
[2:37] So they create their project and the weapon of choice today to deploy those open source packages, it’s GitHub.
[2:49] And once it’s on GitHub, it’s very, very simple to run a GitHub action command, a workflow, which will deploy it into the public registries.
[2:59] It’s very, very simple today.
[3:01] There’s a lot of templates of doing so and all the developer need to do
[3:11] in order to make it happen is just to put in the registry token. And voila, he has a public package in the public registry.
[3:20] In this example, we chose Python.
[3:22] Now the developer’s ecosystem mostly consume the packages out directly out of the registry.
[3:30] But once they do that and if they want to join a discussion regarding the package or making a contribution themself, so they are doing it on the GitHub repositories.
[3:43] Now, myself also as coming from software development background, I know that some of the open source projects are actually not maintained at all.
[3:55] And even if I will create a pull request of enhancing or fixing a vulnerability in existing project,
[4:03] then it’s very, very likely that it won’t get picked up by the maintainer.
[4:10] So what I will do is create a fork and use the fork directly instead of the project which exists in the public registries.
[4:21] And this flow today combined is 100 times bigger than all of the packages that exist within the public registries.
[4:33] So a data provided by GitHub actually points that there are over 5 million different projects today in GitHub and with over 20% growth year over year.
[4:50] So let’s describe a bit regarding right of the kind of projects that exist in GitHub today.
[4:56] So as described previously, there are the published software packages and there’s also another category of the unpublished software packages.
[5:07] Some packages don’t reach the registry by the maintainer choice, some of which are just fork of existing projects.
[5:17] They are also complete software project like Parse Server and Backstage which are well known.
[5:26] But there are tens of thousands of such projects where the, this is a complete framework of project which organization deploy in their organization.
[5:38] There are software plugins where it’s not in a full blown project,
[5:47] but actually an enhancement of an existing project like a Gradle plugin or a Logstash plugin, et cetera.
[5:57] And there is also everything related with infrastructure as code where, and I’m not talking about the project itself like Helm project or Terraform project.
[6:10] But actually, playbooks or charts where DevOps can actually use and save time in writing them themselves.
[6:23] So all of this combined basically tells us that with all of the item on the news
[6:30] regarding software supply chain attack which happen on top of the public registries.
[6:36] For threat actors, GitHub provide a much more lucrative opportunity with the same amount of effort to actually reach a much broader audience.
[6:50] So the attack vectors in this case for the threat actors is either to register a malicious package.
[6:59] You can see this example where in two years ago, PyPI actually had to shut down its registration process
[7:06] for new users because it was overwhelmed with the sheer amount of malicious usage of its platform.
[7:16] There are also account takeover where malicious threat actor actually
[7:26] take control of GitHub accounts.
[7:30] This also happened recently with the tj-actions example, and there’s another example here.
[7:36] Basically, no one has malicious intent other than the threat actor in this case.
[7:42] And the third option, which is quite different, this is where a malicious maintainer actually become a part of a legitimate project.
[7:53] So there is the famous example from last year of the executives,
[8:00] which a community actually discover almost randomly where a maintainer for a period of over two years
[8:10] in parts actually made the process of getting the back door into the mainstream.
[8:18] So to just to set the expectation, what we going to show
[8:25] with you here today is 10 different ways how you can get pwned by putting your trust in GitHub open source software.
[8:35] And what’s very, very important for you to understand that this is not just about malicious packages because the the SDLC process,
[8:44] the software development lifecycle spread more than just the software development part.
[8:52] This is also the deployment part.
[8:56] This is also the monitoring part and this is also the pre-commit and everything happens before the code actually reaches the source control management system.
[9:08] So this part will be with Liad. – Thank you, Eyal.
[9:14] So we start with the first category in the software development lifecycle. We dive into JavaScript.
[9:22] So developers, as Eyal mentioned, can actually use the GitHub repositories rather,
[9:30] they are using the GitHub repositories for the cutting edge features on the new functionalities that are delivered to GitHub repositories that are not published to the public one.
[9:41] And then in this case in JavaScript, they can use the package-lock on the package json file, which is the manifest file.
[9:49] And they should just reference the GitHub repository with some git commit SHA pinning, specific in this example.
[10:02] But most likely they will use the repository, the external repository without any SHA pinning or a commit pinning.
[10:12] They will just refer to a specific branch or a specific release or a specific version.
[10:17] And the problem in this case is that these references are mutable.
[10:21] The code behind the scenes can change the branch, can get new commits, it can get a new malicious commit inside accidentally merge into the branch.
[10:31] And once that happens, the next time your software runs the build, it’ll pull the newest commit with the malicious code.
[10:42] So we have found over 110,000 package-lock files referencing an external GitHub repos.
[10:52] And few words about the methodology of this research.
[10:56] So we have used the GitHub research tool, which is a pretty powerful tool.
[11:01] And we gather lots of data about lots of open source project.
[11:05] We also validated the stuff against the closed source and tens of thousands of closed source
[11:12] project verifying the data that we gather are actually correct. So…
[11:22] Yeah, moving onto Python.
[11:25] So in this case developers and in specific aspect of machine learning and AI,
[11:34] many data scientists are actually using the state of the art and new functionalities that are pushed to the public repositories.
[11:47] In this example, the stable-diffusion and autogen-ui are two popular examples where the official repository actually reference
[11:56] another repository without the commit SHA pinning, but they are actually referencing the master branch.
[12:04] We have found over 60,000 requirements.txt and pyproject.toml files referencing a mutable versions.
[12:17] So let’s dive into a specific POC. So this is my first time at RSA.
[12:25] Prior to here I was at Black Hat and few other conferences and I wanted to plan our trip here.
[12:33] And I wanted to know which are the best places in San Francisco that I should visit. And I built an app for that.
[12:41] So I created a travel planner app and I wanted to add a new functionality to know which clothes I should wear.
[12:52] So I wanted to know the weather.
[12:53] So I started my exploration on GitHub to search for an open source utility that should allow my application to know the weather forecast.
[13:03] And surprisingly, I found an amazing open source project, I wish the screen was bigger.
[13:09] I found an amazing open source project called the Weather Forecast with a release version and a nice README file and an example usage.
[13:19] Everything looks fine. Great, let’s see what could happen.
[13:25] So on the bottom side we see the attacker screen, starting to listen to a new event.
[13:30] On the top left side we have the requirements txt referencing the external repo. It’s a bit tiny.
[13:38] On the middle, we have the application and then we reference the external repo, the utility that we are using.
[13:46] We run our application.
[13:48] Amazing, we now get the trip plan and what we should do including the weather.
[13:54] But behind the scene, behind the scenes what happened is that our environment variables were exfiltrated to our remote attacker listening for that.
[14:08] So what really happened, we can dive deep into the source code
[14:15] of the open source utility that we just pulled into our project.
[14:21] And looking on the code itself, we have a simple class referencing the WeatherForecast class and doing the initialization itself.
[14:32] We call a specific function called silent exfiltration. Let’s dive deep into what really happens here.
[14:40] Just gathering some data about the system.
[14:44] We look onto the source code and see that it actually runs the command and it calls another function called the run command.
[14:52] And looking on the run command function, we see that it’s actually a pretty straightforward function we’ve to do to implement it.
[15:01] And it just returned two strings.
[15:03] We are not sure what happens here, but if we go all the way to the right, we have all of the malicious stuff
[15:13] or actually the execution of the command being obfuscated all the way to the right.
[15:20] And this is one type of obfuscation that malicious actors are using.
[15:24] There are several more, we will talk about them a little bit later. Moving on to Java.
[15:33] So Java is using the Maven Central as the public registry that it pulls directly from there.
[15:42] But there is the JitPack, which is the package manager
[15:49] that can pull the repository from GitHub, pack it into a JAR file, and then you can use it into your project as you use other JAR files from Maven Central.
[16:01] So we have found over 50,000 JitPacks referencing GitHub repositories.
[16:07] And Go specifically is a language that is based on the version control system.
[16:14] So it hosts all of these packages on GitHub.
[16:18] So it’s not surprising we have almost a million go.mod files referencing GitHub because every Go Module is hosted on GitHub.
[16:30] Another small insight here is that the repository or the Go Modules are going through a proxy.
[16:40] So you don’t actually pull the utility always from GitHub.
[16:46] You go through a proxy and then you might think that proxy saves us and everything is good.
[16:54] Because the malicious actor, the malicious commit that was pushed to the branch that you actually reference is not going to your code because you are pulling it from the proxy side.
[17:05] But this adds a new risk like the incident of boltdb.go, which served a back door on the proxy side and the GitHub report was cleaned out of the malicious code.
[17:19] And on the first look it looks clean, but the proxy served the back door for over three years until it was seen.
[17:29] Moving on to a new category.
[17:31] So we finished with pulling dependencies, we are now building the image, the containers.
[17:36] We are building our software and we have the dockerfiles and the docker-compose files.
[17:42] In this sense they, we can reference GitHub repositories with the run instruction or the add commands
[17:51] and in docker.compose we can use just the reference under the services instruction.
[18:02] And there are about quarter of a million dockerfiles on GitHub publicly available.
[18:07] Each one of them is referencing at least one of an external repository.
[18:13] And most of them are not referencing them with a commit SHA pinning. They’re not validating them.
[18:20] They’re not doing the integrity checks, they’re just pulling them doing the image building process.
[18:27] So let’s take another scenario.
[18:30] We are building the same app that we did last time, but this time we are not referencing the utility of the weather forecast from the requirements.txt.
[18:40] But we are using the dockerfile instruction to pull the utility into our own container and then we build our own container of the application and we run it.
[18:51] This time we get the utility when the image is built.
[18:55] So again, bottom of the screen is the attacker side, listening to new events.
[19:06] Yeah, on the top left side we have the requirements.txt.
[19:10] Now it is cleaned out of the references from GitHub and on the dockerfile itself, on the top right we have a, it’s pretty small, yeah.
[19:22] We have a reference to the utility with the git clone instruction.
[19:31] And the entry point for the container will be the same planner.py that we had previously.
[19:39] Once the image is built, we can verify that is available.
[19:44] Amazing, now we can run it with the open weather map API key or whatever that we use for the weather app.
[19:52] Once we do that, we get the output of the application, which should be the same.
[20:06] Looking on the output, we have the same output that we had previously, but the environment variables were exfiltrated as well.
[20:16] So this is another way that you can pull dependencies from GitHub during the image building process and you get pwned the same way.
[20:29] So moving on, once we have the container built and the image ready, we want to deploy this stuff to production and to run it actually on our production systems.
[20:40] So here comes the Kubernetes and Helm charts.
[20:43] And Helm chart, Helm is just a package manager for Kubernetes.
[20:47] And it can reference GitHub in several ways and most likely it’ll pull some configurations from files from GitHub and some new utilities.
[20:58] And there are several examples on how to do that.
[21:01] There are over 140,000 charts on GitHub referencing an external GitHub repo.
[21:11] So let’s take another scenario. In this case, we have an application
[21:19] that we have built to tell us the ratios between currencies, the USD and the Euro.
[21:26] And we suspect that this application is memory heavy and we want a utility to help us detect the RAM usage during runtime.
[21:36] So we want something that every a few seconds will tell us how much RAM is used and then we can monitor this type of stuff.
[21:45] So we go on our traditional exploration on GitHub, we have found an open source repo called RAM Logger.
[21:54] Amazing, looks great. README file, release version.
[21:59] We go into the files this time to verify the source code that nothing malicious is over there.
[22:05] We go to, we see a chart.yaml that looks pretty clean, the values.yaml also is clean.
[22:14] And we have another file under the templates directory which is a cronjob that every few seconds
[22:22] will just output the memory usage of the container or the code that is running. Looks great.
[22:30] We integrate it into our project. How to do it?
[22:34] We just add a few lines of code with the dependencies and reference to the repository on GitHub.
[22:42] What could possibly go on here? So on the top left side we have the clean Helm chart.
[22:49] On the top middle we have the chart updated with the RAM logger utility.
[22:56] The bottom of the screen is the attacker side listening to events. I hope this is starting. Yeah.
[23:09] So we will start with the deployment of the clean Helm chart and on the top right side we have the deployments.
[23:16] Nothing is running at this moment.
[23:19] Once we run the deployment, we have it popped up
[23:26] and we can start listening to the logs and see what is actually happening.
[23:32] So as we expected, we see the USD and the Euro ratios, nothing suspicious happening now.
[23:43] But we’ve now integrated the RAM Logger deployed again.
[23:48] We have the environment variables exfiltrated to the remote attacker listening, and we have side by side with the currency ratios.
[23:59] We also have the RAM usage that we expected to see. So what really happened here?
[24:06] Why did the environment variables exfiltrated?
[24:13] So taking a deeper look on what really happened, we have the chart yaml that referenced the RAM Logger external repo.
[24:26] And in this case, when you reference an external GitHub report, it actually doesn’t verify or look at the source code of the repository itself.
[24:36] It just look for a specific file, a tgz file, which just download it and use it as it is.
[24:45] Without integrity checks of the source code, the repository has without anything, any verification.
[24:53] In this case, the tgz file was different from the source code of the repository.
[25:00] It had the same functionality, a cronjob, but also with an additional malicious code that will exfiltrate the en var.
[25:11] Moving on, another category through the software development lifecycle, we have the GitHub references in configuration management and observability.
[25:23] So once we deploy our application, we want to track it, we want to see the logs, we want to monitor it.
[25:34] So there are four cases we go through pretty fast.
[25:38] Ansible is a way to automate configuration and automate the systems themself.
[25:51] There are over 3,000 of them referencing GitHub.
[25:54] We have SaltStack, which is another configuration management pretty known. Over 1,000 of them are referencing GitHub.
[26:04] Moving to the log or the logging systems.
[26:08] We have Logstash, which can also reference GitHub to get additional plugins, additional utilities.
[26:15] And Grafana for the dashboards and once you have the data, then you can make it into a pretty dashboard.
[26:24] So of course Grafana can pull dependencies and pull the configuration out of GitHub as well.
[26:33] So GitHub webhooks and integrations. This is another step in the software development lifecycle.
[26:41] So actually GitHub can trigger new events once there are some specific,
[26:49] or trigger an API calls once specific events happen in the repository.
[26:57] So this could be a code push or commit or manager request.
[27:01] Once this has happened, it can send the webhooks to an external service.
[27:06] And there’s a specific event called a repository_dispatch event, which is, once it’s getting plugged,
[27:15] it can make a pull request to an external GitHub repo.
[27:22] And we have found over 50,000 workflows actually enabling the repository_dispatch event and waiting for this event to be triggered.
[27:35] So CI/CD pipelines and GitHub actions, another step, another category.
[27:40] In this case, let’s have a few words on what are GitHub actions and CI/CD pipelines.
[27:48] So this is a way to automate your process through the tests and the building phase and the deployment phase and creating your images
[27:57] and push your stuff into your registry, whether it’s a public one or a private one.
[28:03] And we have seen, and GitHub action is the native things that you can compile,
[28:11] all of those stuff into a specific action and also you can share it.
[28:15] And there are many GitHub actions that are publicly available for you to streamline your development processes.
[28:24] So we have found many workflows and many GitHub actions referencing an external GitHub actions or an external GitHub repo.
[28:38] And using the git clone commands inside the GitHub action.
[28:44] And we have started to create a PoC, but as soon as we started this happened.
[28:51] And tj-actions is a major incident I hope all of you heard of, which is affected almost 23,000 repositories.
[29:02] It was a GitHub action that was compromised, over 20,000 repositories where using this GitHub action.
[29:11] And this really proves that the attack surface we are talking about is actually being weaponized.
[29:18] So let’s take a quick look on a specific example that we found a repository called homebrew which used the tj-actions.
[29:27] And this repository used tj-action through a specific version.
[29:34] So we targeted a specific release, but in this case the malicious actor changed all of the versions, all of the list to include his malicious commit.
[29:46] So it wasn’t pinned to a specific SHA or a specific commit.
[29:51] So all of the version of tj-actions were compromised and anyone referencing at least one of those were vulnerable.
[29:59] So we have found homebrew, it was referring this one, it was running a CI/CD jobs during the exposure time of the vulnerability.
[30:08] And basically the malicious intent here was to exfiltrate all of the en var outside into the CI/CD logs.
[30:18] This is a public repository, so the CI/CD logs and the GitHub action logs are also public.
[30:24] And once we decode it base64, decode it, double decoded. And we have the GitHub tokens available over here.
[30:35] Few more categories. So we have the Git Submodules and Git Subtrees.
[30:39] This is usually things that the developers are using on their machine when they’re creating a new repository
[30:46] or a new project where the project might depend on another repository or share a common library of utilities.
[30:55] So they might use the Git Submodule or Git Subtree and of course they can reference an open source repository that they can depend on.
[31:09] So we have the infrastructure as code during the software development lifecycle.
[31:16] And here we have the Terraform and Terragrunt, which again is an infrastructure as code that manages your infrastructure.
[31:28] And it can reference GitHub plugins and GitHub repositories to pull the dependencies,
[31:36] to push them, to add some utilities over them and then run them.
[31:41] And there are many management things that you can do with Terraform, but also with incorporating an external GitHub repo while doing that.
[31:54] And we found over 100,000 terraform files reference in GitHub. So the attack surface is huge.
[32:04] Moving on to the plugins and extensions that you can pull. So we have Gradle and Redis.
[32:10] Redis is hosting its plugins on GitHub, some of them. And Gradle specifically can reference an external GitHub.
[32:18] Gradle is a package manager for Java and you can of course reference an external GitHub repo over there.
[32:28] So let’s dive into another POC.
[32:35] So we have seen a lot of demand from the developer community, or, for all of the developer community running Gradle commands.
[32:46] And they wanted a specific repository that would just print nyan-cats to the console while they are running the build Gradle or the Gradle run command.
[32:57] So we have built this repository and we share it to the public audience and we have released a version.
[33:06] It is pretty simple code, we just print the nyan-cat to the console and there is an example on how to use that.
[33:16] So it got a lot of traction and many requirements and feature request.
[33:22] And one of the contributors named Aviad decided to add the new functionality to our repository.
[33:29] He wanted the nyan-cat that should be colorized and we should add a new merge request
[33:37] or merge his fork and approve his new code that he contributed.
[33:45] So before we actually merge his contribution, we took a look on what is the code that was supposed to be merged.
[33:55] We see that nothing suspicious is over here and we decided to merge it and release a new version of our open source.
[34:04] Amazing. So what could go wrong now?
[34:10] So let’s see a short video of what the functionality of the repository was before running the merge request and after it.
[34:23] I hope this is running. Yeah, so we use the apply which is the command to reference an external Gradle.
[34:35] And we, and the Gradel command, amazing.
[34:38] We get the nyan-cat on our console and now we will add the new functionality to print it with the color.
[34:46] And we update the reference to reference the updated version or updated release.
[34:54] Quick insight, this happened as soon as we saved the file, the exfiltrated en var
[35:06] went to the attacker even before we ran the new command.
[35:10] So as you saw, the yellow nyan-cat now points to the console, but the en var were exfiltrated twice.
[35:20] So looking back on the merge request and the source code, we ask ourself why this was malicious?
[35:28] So on the top of the merge there is another apply command which referenced another Gradle plugin,
[35:38] which this Gradle plugin hosts all of the functionality to actually apply the color to the nyan-cat.
[35:47] And going specifically to that Gradle plugin, we see the malicious code over here.
[35:55] It’s just basic, default encoded and then we run a shell over it
[36:02] and it actually applies the color but also exfiltrate our environment variables.
[36:10] Last category, we have the pre-commit, the pre-install, and build scripts.
[36:15] So during the development lifecycle we have another way to streamline our jobs
[36:22] and many packages on the npm,
[36:30] on the npm ecosystem have a pre-install and post-install commands or scripts,
[36:37] which will run automatically behind the scenes without sometimes you even noticing that will, the pre-install will run
[36:46] before any installation of the package and the post-install after it.
[36:50] Some of them can of course reference GitHub, but threat actors are actually using those types of scripts to inject malicious stuff over here.
[37:05] I think that’s it, yeah. – Okay, thank you, Liad. So just to recap what we just seen here today.
[37:15] So the GitHub ecosystem, as you saw, is quite huge.
[37:20] Worth mentioning here that GitHub is also a commercial product with over a billion dollars ARR just for the closed source.
[37:30] This is before mentioning the open source.
[37:33] Now what we seen here today from our analysis as we have also,
[37:40] we also have access to closed source repositories where we witness that the same behavior
[37:47] that exists in the open source ecosystem that Liad just showed you in the examples also existing in the closed source, meaning that this is by design.
[38:00] So all of the referencing to between GitHub, different GitHub projects,
[38:10] it’s all by design and basically means that this is a vulnerability
[38:17] or a attack vector which is not going to go away anytime soon.
[38:23] So with all of that, this provide threat actors a very, very lucrative opportunity, which will also provide them great value.
[38:33] As we also saw in the tj-action example, it’s already being weaponized out there.
[38:41] So to tackle it, because this is not going to go away anytime soon, we need to manage our software supply chain better.
[38:53] And also when considering SBOMs where it’s already a part of most organization today,
[39:04] the process of creating an inventory of all of the software component.
[39:09] You should also make sure that you list the items that you use directly out of GitHub and not just the ones which are hosted on the public registries.
[39:19] And as we’ve seen in the news previous years, so again there was tj-action,
[39:28] there was executive tools, but there were also dozens of other examples.
[39:33] And we are pretty sure that this is just the tip of the iceberg.
[39:38] And because of the wideness of this attack vector, we are pretty sure that there are much more of this already ongoing.
[39:48] So what you can actually take from this talk and apply it in your own organizations?
[39:55] So everybody here I guess already know about SBOMs and the importance of that.
[40:01] So starting with making sure that you are already able to cover for GitHub repositories as well, which are directly consumed by your applications.
[40:15] Moving on from there, you need to make sure that you have the SBOM for the entire SDLC,
[40:22] meaning that if you’re using a Redis plugin or a Grafana plugin or Helm charts which are also taken from open source project.
[40:33] You need to make sure that your SBOM cover those as well as you will hear the news on some kind
[40:41] of compromise Helm chart, you will have the same, basically it’s the same use case as you already have with the application level packages SBOM.
[40:55] Because the purpose is exactly the same.
[41:01] Moving on from there, you need to make sure that you standardize the application building process and the entire SDLC process, you know, in your organization.
[41:11] This could be made by usage of golden images where you are actually building a shared infrastructure for the different development group.
[41:23] In this way you can actually manage the process and making sure that you authorize
[41:31] and able to monitor a single process where of the way of the application actually reaches production.
[41:40] And the holy grail is actually to be more proactive and provide the development team and also the DevOps team,
[41:48] the required infrastructure that answer their needs ahead of time.
[41:53] Because today, with all of the AI tooling and rapid application development
[42:03] required from those teams, then when they’re facing a problem, they will solve it.
[42:07] Because they have true business needs that they need to handle.
[42:12] And if they don’t have the required infrastructure, they will not wait and they will just do it.
[42:17] And this how shadow IT comes into place.
[42:22] So if you are going to be more proactive, you are going also to dramatically reduce the attack surface.
[42:31] So basically the concept of platform engineering, if you already heard about it, great.
[42:37] Not a lot of organization actually are active on this front.
[42:41] As larger the organization, it’s making much more sense to have a dedicated team of architectures actually tackling those kind of problems.
[42:51] And making the steps of standardization and building proactive infrastructure
[42:59] to make sure that the attack surface actually became something that you are actually able to manage.
[43:07] So a little bit more about the research. So the entire research, we made it open source.
[43:13] Also the demo recording and the GitHub project that we use, you can also recreate it on your own infrastructure.
[43:22] You don’t need to worry about your environment variables, we won’t take those.
[43:28] And also a big thank you for our colleagues Moshe and Aviad, which actually assist in the research and took part in building those demos.
[43:38] So that’s all from us. Thank you. – Thank you.
