WEBVTT 00:00.000 --> 00:10.480 Hello, everyone. Welcome to our next talk and security room. Next talk is from Tunis 00:10.480 --> 00:14.760 at a streamlining signing artifacts in container ecosystem. Welcome Tunis. 00:14.760 --> 00:26.360 Thank you. So, yeah, I'm Tunis. I work at open source built-in, a talker. And 00:26.440 --> 00:30.840 today I'm going to talk about sign artifacts and some of the advancements we made in this 00:30.840 --> 00:38.680 area. So, to get started, like, why should you sign? And I think there's simple answer 00:38.680 --> 00:45.760 is that because there's many threats there to end many things that want to attack your software 00:45.760 --> 00:51.360 and compromise it. So, when the first example I just picked this actually, you 00:51.360 --> 00:58.840 tells hack that was came, like, lots of attention. I'm sure many of you remember this 00:58.840 --> 01:05.160 one that lots of coverage, mostly the coverage was about this bizarre situation, how there 01:05.160 --> 01:10.680 was this maintainer who built up trust for a long time. And then, also, like, the patches 01:10.680 --> 01:19.000 were really, really complicated. What maybe got less coverage was that if you actually look 01:19.000 --> 01:26.000 at, actually, exploit, then a part of it was never even like committed to get. So, basically, 01:26.000 --> 01:31.640 some artifacts were just built on a random machine. They were shared with the rest of the 01:31.640 --> 01:39.480 internet and people just trusted it and started to use it. So, like, the question is, why do 01:39.480 --> 01:43.720 we think this is normal? Like, like, isn't there like a technology solution that we can, 01:43.760 --> 01:50.760 we can use to prevent this? And yeah, come from Docker. We work with containers and there's 01:50.760 --> 01:57.760 been, like, many different attempts to do some kind of signing in the best. But if you, like, 01:57.760 --> 02:04.760 pick some kind of, like, a random popular container at the moment or a container image, 02:04.760 --> 02:13.680 then, most likely, it's not signed. So, this is what I'd like to change. And then, 02:13.720 --> 02:18.440 just when we're looking at some of the solutions, I've listed here, like, some of the things 02:18.440 --> 02:24.680 that I'm looking for in this possible solution. So, I want the solution to actually 02:24.680 --> 02:33.480 be effective against some of the practical attacks. If you're doing the signing, you should 02:33.480 --> 02:38.240 really understand, like, why are you signing this? Like, what value is the signature providing 02:38.280 --> 02:42.280 because, like, if you're just signing it for the sake of signing, then we're just 02:42.280 --> 02:49.240 adding, like, another failure point. Another thing, I just want to emphasize is that I do 02:49.240 --> 02:55.080 think it needs to be simple. If you want to get, like, a really big adoption. Like, I could 02:55.080 --> 02:59.440 come here and talk to you that, like, you need to get, like, three of your big keys, and 02:59.440 --> 03:02.760 you might go on with a, like, a ton of another, and then you put the third one into a safe 03:02.840 --> 03:09.600 time, then you go and share it with whatever ways. Like, I don't think this is, like, 03:09.600 --> 03:16.440 way how we can get all our images signed, because, like, most of us need to spend our 03:16.440 --> 03:20.640 time, like, actually building things, like, we can't, like, worry about the security 03:20.640 --> 03:26.880 problem, also, like, the whole time. So, yeah, I'm looking for something that's, like, it's 03:26.880 --> 03:33.320 very tight and integrated with existing tools. And, yeah, it also doesn't make it, I 03:33.320 --> 03:37.880 think it's thing tools super slow once you enable it, because, like, if this happens, then, 03:37.880 --> 03:46.320 like, people will just not turn it on and, and nobody will, will care anyway. So, let's see, 03:46.320 --> 03:51.480 if you can find something like that. I first want to talk to a little bit about the 03:51.480 --> 03:58.080 circuit. So, the builder framework that we use at Docker, the powers at Docker build command 03:58.080 --> 04:04.520 we use it to build our Docker files, but it's not really, like, anyway, restricted to just 04:04.520 --> 04:08.320 Docker files, it can build, like, you kind of build the conditions. There's many, very 04:08.320 --> 04:14.000 popular use cases, even I saw the Docker. It's hyper formats, it can build very complex 04:14.000 --> 04:21.120 builds, it does automatic casting, it's about the, like, the built kit container image, 04:21.120 --> 04:28.520 just past one billion pulls this week. So, it's, like, built it is running, like, millions 04:28.520 --> 04:30.640 of builds every day. 04:30.640 --> 04:37.760 Uh, a little bit to keep the understanding of how built kit works internally. So, your built 04:37.760 --> 04:44.160 definition is to need to a graph of build steps, and all the, this graph starts from 04:44.160 --> 04:48.440 something called source nodes. So, these are, like, things like images, heat repository, 04:48.440 --> 04:53.120 HTTP URLs. These are all immutable. They're guaranteed to be immutable. You can get 04:53.120 --> 04:57.800 a checks on for them. And then, while you build this running, then, those sources can 04:57.800 --> 05:02.200 transform them. And there's, like, very, you can do, like, any kind of, like, dependency change 05:02.200 --> 05:09.200 between them. The important thing is that, uh, everyone of those build steps is sandboxed, 05:09.200 --> 05:14.880 and it's, like, a side effect tree. So, it's not, uh, the, the step is not influenced 05:14.880 --> 05:18.720 by another step running as part of the build, and it's, there's never influenced by the 05:18.720 --> 05:26.640 system where it's running out as well. Um, then, once you, once you build completes, you 05:26.720 --> 05:31.800 get a build result. So, of course, like, you want to get images, but build kit can give 05:31.800 --> 05:36.000 you any kind of hard effect you want. So, we build our all-ever release binary, as well, 05:36.000 --> 05:43.520 like, build kit because my wouldn't, yeah. Uh, in addition to the build result, you automatically 05:43.520 --> 05:49.680 also get the provenance at a station. And, uh, like, if you're seeing the provenance 05:49.680 --> 05:54.960 at a station, maybe from some other tools, like, or sometimes they, like, seem like there's 05:55.040 --> 05:59.680 just, like, a checksum, and you add, like, some kind of parenthesis around it to make 05:59.680 --> 06:04.200 it chase, and then, like, this is not like that. Uh, this provenance that the station 06:04.200 --> 06:11.000 has, uh, your, like, complete the trace of your build. So, like, it's, as the complete 06:11.000 --> 06:17.040 information of, uh, what exactly happened during your build. So, it has all the, uh, all 06:17.040 --> 06:22.480 the build sources, uh, our capture there with a checksum, all your build configuration, your 06:22.560 --> 06:27.680 build step-to-step initial. So, every client, uh, like, this, uh, changed during your 06:27.680 --> 06:32.560 build flow, photographer's source, timing information, like, you know, like, if you're, like, 06:32.560 --> 06:38.000 build access network or, or not, uh, if it's, like, binary reproducible things like that. 06:39.040 --> 06:42.640 So, this is very good if you're, like, have an artifact and you want to figure out, like, how 06:42.640 --> 06:47.440 this artifact was built. But it can, it can give, like, really, like, complete story from the, 06:47.520 --> 06:54.720 like, the initial ingredients to, to how, how the final binary was made. But, uh, I still 06:54.720 --> 06:59.760 could make this bonus statistician, it's not signed. So, you can't, like, really use it for, 06:59.760 --> 07:03.600 some kind of a smaller detection. So, you need to trust it the same way as your trusting 07:03.600 --> 07:11.360 the image. Um, so, let's see if it can, as some kind of trust it, with the signature. 07:12.320 --> 07:18.560 So, I told you that, uh, toolkit provenance is, is not signed by default, but let's look at some 07:18.560 --> 07:24.480 other example, in here, where, where there is an attestation and it is signed. So, this is something 07:24.480 --> 07:30.800 that I copied out of from, documentation from, uh, GitHub, well, they, they kind of, like, have, 07:30.800 --> 07:34.960 like, documentation for our, like, how to use our actions in, in, in the, in the, in the, 07:34.960 --> 07:39.120 in the GitHub actions development. So, in the first section in here, here are, like, our actions 07:39.200 --> 07:44.080 for, for actually running to build the toolkit. And then, in the end, they write that one extra 07:44.080 --> 07:49.360 step, uh, that, like, generate artifact of the station and if they look at the, like, documentation 07:49.360 --> 07:54.960 for the step, then they say that this thing is an unfortunate statement. So, like, at least, 07:54.960 --> 08:01.200 somebody is very confident. So, so, let's, let's look at, like, how, unfortunate, all this, this 08:01.280 --> 08:10.160 release them. So, let's first, uh, see what's good about this. Like, like, this is a signed 08:10.160 --> 08:18.480 attestation. There's no key in here. Uh, so, the way it works is that temporary key is generated every 08:18.480 --> 08:24.560 time, or you run that this workload is, every time there's a new key, and based on the scope of your 08:24.640 --> 08:29.680 GitHub token, you get a certificate from a fixed order that matches this scope and matches your, 08:29.680 --> 08:33.440 your key. Like, once you're, once you're done with your job, then you throw away the key. 08:34.480 --> 08:38.640 So, that, that's, that's all simple. And if you look at some of the tech vectors, so, like, 08:38.640 --> 08:44.800 if our tech vector is that our register credentials can compromise, then this is a very good signature. 08:44.800 --> 08:50.560 Like, if you have, have a way to change stuff in the registry, you can never, like, 08:50.560 --> 08:58.960 create a signature like this that matches the, the both as well. But, what if our GitHub credentials 08:58.960 --> 09:06.560 get compromised, not register credentials? What if our, like, our, like, GitHub token, for example, 09:06.560 --> 09:11.520 leaks, like, this is what we saw, like, many times last year with all the, like, like, a childhood, 09:12.480 --> 09:16.960 a text, right? So, in that case, you're, you're kind of, like, screwed, because, 09:18.480 --> 09:23.920 then, like, with your GitHub credentials, first of all, you can, the attacker can change anything 09:23.920 --> 09:28.640 that happens before in this, in this, in this build flow. But, you don't even need to do that. 09:28.640 --> 09:34.080 You can just use the GitHub token directly, go to sixth or register the token in the sixth 09:34.080 --> 09:40.080 or, and then, like, you, you can do, you can save, save that, that employee key forever and 09:40.080 --> 09:48.080 use it forever and, and, and take as many things as you want. So, to avoid that, what we really 09:48.080 --> 09:54.400 need to do is we need to put all this build flow away from the user repository. So, that, when 09:54.720 --> 10:03.200 you have access to the user repository, then, you still need to, like, you still can't, 10:04.720 --> 10:09.520 can't mess with this build flow, and you can't mess with the signature. And the way to do this 10:09.520 --> 10:15.520 is some, called, our usable workflow in GitHub Actions. And this is what we've done with our, 10:15.520 --> 10:22.000 like, newer repository that we've created, that's called, GitHub Builder. So, this, this provides 10:22.000 --> 10:29.440 this trusted, usable workflow for builder for doing this build flow. If you use this, builder, 10:29.440 --> 10:37.440 then, all the attestations are signed or, like, get a proper six or signature. And those 10:37.440 --> 10:43.360 attestations, how do we, like, the build key statisticians, not, not some other, like, simple 10:43.360 --> 10:51.360 attestations. Yeah, we make sure that we only allow secure build configurations. We make sure that 10:51.440 --> 10:56.400 everything that's part of the build pipeline is also verified before your build starts. If you 10:56.400 --> 11:01.680 want to cache, then we sign the cache as well. So, like, you can only import cache that's already, 11:01.680 --> 11:10.560 also created by this builder, and, and, and properly signed, and yet, and many other features, 11:10.560 --> 11:19.360 as well, like, the laundry security related. So, just to illustrate, like, what's happening in here, 11:20.000 --> 11:25.360 like, you're, like, a simple file flow of the, getting to six towards signature. This is how we 11:25.360 --> 11:30.960 was in the, in the, like, first example. And now, if we add the trusted builder there, it comes in 11:30.960 --> 11:37.360 the middle of your upper repository, and the sixth or, like, the certificate provider service. So, 11:37.360 --> 11:44.880 now, all the, all the signing is contained in this trusted builder, not with your upper repository. 11:45.840 --> 11:51.040 Uh, you can, as a user, you can't change anything that's happening in this trusted builder. 11:51.040 --> 11:56.240 You can't, you can't inject anything into that flow. Only thing to adapt repository can do, 11:56.240 --> 12:01.680 is provide itself as a source for the trusted builder. And then, once the build is complete, 12:01.680 --> 12:10.800 then it can get the result back. So, just to make it very clear, like, what does the signature 12:10.800 --> 12:17.840 prove? Like, and the answer is that when, when you have an artifact that was built with this builder, 12:17.840 --> 12:23.920 it has a certain checksum. Then there's a very strong relationship that this binary was built 12:23.920 --> 12:29.280 exactly from this, keep commit in the repository using exactly those steps that are covered in 12:29.280 --> 12:37.760 the provenance attestation. And, uh, and, like, some, some of the, like, things, like, that can't 12:38.720 --> 12:42.160 fake this relationship is, like, you know, when you have a registered financial leak, 12:42.160 --> 12:47.440 you can't fake this relationship. If you have, uh, kita credential leak, you can't do any of that as well. 12:48.160 --> 12:52.640 Uh, yeah, like, if you're, kita token, for example, leaks in CI, you still can't, even if you're, 12:52.640 --> 12:59.360 like, a rogue maintainer of the source repository. Like, whatever, you, you want to do, like, 12:59.360 --> 13:03.360 you have access to their repositories to change anything in there, but you can't make, like, a 13:03.440 --> 13:10.480 fixing ensure, like, this from the, uh, paid based on the source code. And obviously, like, 13:10.480 --> 13:14.960 just to make you sure, like, like, talker can't, like, create two signatures as well. Like, like, 13:14.960 --> 13:19.440 like, it's not that you need to trust, talker and, and hope that talker doesn't create, like, a 13:19.440 --> 13:25.440 fixing ensure for your project. And, technically, you don't need to trust six store as well, 13:25.440 --> 13:30.880 because, like, the transparency locks. So, it's, uh, the transparency locks of the, of the six 13:30.880 --> 13:36.480 store would, would then show, like, right away, like, if anything, even, like, happens on the six 13:36.480 --> 13:42.400 store stack. And, yeah, we will also protect against the built-up end of CI leaks. So, like, we 13:42.400 --> 13:47.920 make sure that, uh, the workflow that's actually, like, running when this transformation happens, 13:47.920 --> 13:54.480 doesn't have any, uh, any, any, any possibility to do, like, a tool come there and, and 13:54.480 --> 13:59.200 check this off. And we also make sure that, yet, you have no side effects from the host at my 13:59.360 --> 14:04.000 moment. So, when GitHub changes their VM image, and there's some kind of arbitrary state that's 14:04.000 --> 14:09.040 subtracting their VM image, like, this doesn't ever add any effect for your build. 14:12.400 --> 14:21.520 So, yeah, as a summary, this is, uh, like, like, the, the trust of this, of this model is provided 14:21.520 --> 14:27.920 as a combination of the two tools. So, one is, uh, this GitHub builder that provides the trust 14:27.920 --> 14:34.000 assigning context, and that it moves the, like, the correct version of our, of our build stack. 14:34.000 --> 14:39.120 And then build kit itself is doing the, the, the trust model of the actual build when it's running, 14:39.120 --> 14:45.360 making sure that they're bi, build is properly isolated and making sure that, uh, all the, 14:45.360 --> 14:48.080 all the steps that run as part of your build are properly captured. 14:48.800 --> 14:59.200 Okay. Now, this was about signing. Let's talk about very fine, as well, because, like, 15:00.160 --> 15:04.640 a lot of the time, like, very fine, it's kind of ignored in this story, like, there's so much 15:04.640 --> 15:09.840 talk about signing and then point away, like, I guess we can somehow do the very, very fine, 15:09.840 --> 15:15.440 as well. But if you do not verify, then there's really no point of signing at all. So, 15:16.400 --> 15:22.240 because, like, the whole point is that we create this very strong signature that attacker can't fit, 15:22.640 --> 15:28.480 but if you, if that, if you don't verify that, uh, all the fact, for example, that attacker has replaced, 15:28.480 --> 15:32.880 doesn't have this strong signature, then, like, there's, there's no point of doing any of that, 15:32.880 --> 15:41.120 the dog. Uh, so, some manual ways to do the verification, uh, is, uh, we've had that, 15:41.840 --> 15:47.200 and you think you're inductor inspect. So now, when you're, like, inspecting a signed image, 15:47.200 --> 15:51.600 signed this way, then it would show the signature there already in the verified form. 15:51.600 --> 15:55.520 You can manually sign with, well, verify the cosine, of course, because it's, uh, 15:55.520 --> 16:02.720 completely, like, a legitimate six-store signature. Uh, there's a thing for Kubernetes, like, 16:02.720 --> 16:09.040 if you're, like, writing policies in YAML, uh, what we really want to do, though, is something 16:09.120 --> 16:16.080 more built in, so something that's more built into the tools and, uh, more, like, automatically enabled. 16:16.880 --> 16:25.040 So what we've added is, uh, a re-godd that's from the open, uh, policy agent, uh, like, uh, 16:26.240 --> 16:30.400 policies written in the re-god language are not, not supported directly in our build stack. 16:31.120 --> 16:34.720 So what you can do, which you can write the policy, like, the matches you're, like, 16:34.720 --> 16:39.680 talker file, for example, name it, talker file.trigo. And then if this file exists in your project, 16:39.680 --> 16:46.800 we will automatically load it anytime you invoke, talker build. So, and what's happened then, 16:46.800 --> 16:51.600 is that when built, it will run your build for every source in your build, it will first go back 16:51.600 --> 16:56.480 to the policy and check with the policy. Like, if, if this source value, they're not, and if it's 16:56.480 --> 17:00.560 not valid by the policy, then your build will just not complete, like, it will, it will just 17:00.560 --> 17:06.000 throw it out right away. And yeah, it's very flexible language to write policies, and we will 17:06.000 --> 17:12.960 give you all the source properties, like, to, to check with. So you can do, like, very, very complex 17:12.960 --> 17:16.960 stuff in, in, in those policies. So this is just some of the examples that, of course, 17:16.960 --> 17:20.960 like, I'm going to show the signature case, but you can do the check, verify the check sums, 17:20.960 --> 17:25.360 verify, or like, pin the check sums, like, you can do the kitchen at yours, whatever, 17:25.360 --> 17:32.640 the image properties, like, anything you pretty much want. So, here I have the example, 17:33.520 --> 17:37.360 for, like, how do, how you would use this regal policy to verify, 17:37.360 --> 17:43.760 this trusted pillar signature that I just showed previously. And for that case, like, we've added 17:43.760 --> 17:51.600 and, help her in here to make this easier. So pretty much, what to say is that, if you have a source 17:51.680 --> 17:59.760 as part of your build, so that's, what a image called, or app, then it's only allowed to be used. 17:59.760 --> 18:06.480 If it has this value trusted pillar signature for this same kit up repository name, and 18:06.480 --> 18:11.120 extra condition is also that the kit up tag and the image tag need to be exactly the same. 18:11.120 --> 18:18.160 So you can switch the versions as well, in this case. And this is the same exact thing, 18:18.160 --> 18:22.320 it's just, like, written out what would happen internally, like, or, like, if you work, 18:22.320 --> 18:28.240 example, like, write to verify manual six-store signature. Important thing to notice here is that 18:28.240 --> 18:33.680 we need to verify both the, like, the source repository and the pillar repository separately, 18:34.240 --> 18:39.520 because, like, if you only verify one, then it's not secure. It's only secure if you verify both, 18:39.520 --> 18:47.280 like, the combination of them. And another question might be, like, okay, like, 18:48.160 --> 18:53.360 come, using those dependencies in my project, like, how do I know which policy rules are 18:53.360 --> 18:57.840 correct for those projects? And I think, like, at least what something that we can start with, 18:57.840 --> 19:03.600 is that if you use this builder to build a release binary, then what you can do is, 19:03.600 --> 19:09.680 you can just write in a read me that, like, hey, like, we are using this, in our release flow, 19:09.680 --> 19:13.840 we are signing images in this way. We have these rules of, like, these tags, 19:13.840 --> 19:18.880 I'm remutable, these tags are not, for example, and put just an example there, and, like, 19:18.880 --> 19:24.320 that users of your project could, could just put their into their policy to make sure that 19:25.680 --> 19:34.080 your dependencies, like, validate that in their most correct way. And this isn't, like, 19:35.040 --> 19:42.640 like, the point of that is that then you, like, commit this, commit this policy into 19:42.640 --> 19:49.600 it, and then it kind of like comes as you are, like, security thoughts for your project. 19:49.600 --> 19:54.880 So now, like any time you work on your project, you are automatically protected by the policy 19:54.880 --> 20:02.960 when you, like, your CI runs for your project. It also protects your CI when you release 20:02.960 --> 20:09.440 what runs, it also protects your release, but when other people clone your project, 20:09.440 --> 20:14.080 they also get this default behavior. And, of course, there's a way to how they can, like, disable, 20:14.080 --> 20:18.160 if they don't want it, they can tweak it. But, as a project owner, you can kind of, like, define, 20:18.160 --> 20:26.720 like, what is the secured default for your project? So, to recap, we just talked about, 20:27.680 --> 20:32.320 like, we sign your images, you know, reason not to sign, like, we have, we have the technology 20:32.320 --> 20:38.160 to add this very, very strong, like, security parameters, need to have all the effect, 20:38.160 --> 20:46.320 and it's very easy to do, I think. Not all signatures are equal. So, when you're, when you're 20:46.320 --> 20:50.000 doing their signing, like, make sure you understand what you're actually protecting with it, 20:50.000 --> 20:57.520 be to signature. And, software that pulls those sign packages, like, it needs to do the 20:57.520 --> 21:01.360 verification. If it doesn't do the verification, then they kind of like, the signature is useless. 21:04.400 --> 21:10.800 So, the trusted builder repository, it's available today. You can use it right away. 21:11.680 --> 21:15.760 If you're, like, using our existing kit-up actions, for example, at moment, like, 21:16.080 --> 21:20.880 like, I think something, like, 800,000 repository still or something like that, then it's very easy 21:20.880 --> 21:26.640 to, for you to upgrade, like, it's pretty much just a little bit of, like, syntactic changes, 21:26.640 --> 21:31.760 but it's built by the same people. So, it's, like, the UX will be very, very familiar with, yeah. 21:33.920 --> 21:38.960 If you're not building, like, container image is at all, then I think this could be still, 21:38.960 --> 21:43.120 like, super useful for you, because, like, whatever way you're building your, like, release 21:43.200 --> 21:46.960 planner is, for example, like, it's very likely that whatever tool they're using, it's 21:46.960 --> 21:51.920 run is fine inside containers as well. So, you can just, like, pretty much, like, take your existing 21:51.920 --> 21:58.080 thing, but add a little bit of, like, a container wrapper around it, and you get this very strong 21:58.080 --> 22:06.240 signature guarantee, like, almost like, out of the box. Yeah, and all are, like, latest releases 22:06.240 --> 22:12.000 for, for a built-in, we've already created new versions of them, and they're all already signed with 22:12.000 --> 22:19.760 the same builder. So, we're, yeah. And, when this tool's run inside the GitHub, 22:19.760 --> 22:26.080 later, we also get a signature verify properly. And, yeah, the vehicle policy support as well, 22:26.080 --> 22:32.800 we check it out. It doesn't, like, think that we will continue working on, so, very much 22:32.800 --> 22:39.520 interested in any feedback if you have there. And if you use the GitHub builder, then, please, like, 22:42.320 --> 22:47.360 keep, like, an example, policy as well, for their finance that you've created, so that people know, 22:47.360 --> 22:55.440 like, what's the best way to validate it? So, I think I'm, like, pretty much, out of time, so, 22:55.440 --> 23:03.360 I'm not sure if we have time for any questions, but maybe one question. You're a closest. 23:04.000 --> 23:13.200 Thank you so much for the talk. I was wondering two things. If this workflow, it's strictly 23:13.200 --> 23:21.840 tied to GitHub, or I can be exported to other systems, I guess, yes, possible. And, the second one, 23:22.960 --> 23:29.120 I was wondering, what about Rigo? If the policy that it supports are integrated with the package 23:29.120 --> 23:34.400 manager, that we use to build the artifacts, like cargo, that downloads a lot of stuff, so, 23:34.400 --> 23:42.400 I want to actually check. Yeah. So, the current, like, the GitHub builder is very much like a 23:42.400 --> 23:48.400 GitHub specific collector. It's based on the GitHub workflow. And you also, like, yeah, you need to 23:48.400 --> 23:53.760 run it in the GitHub stack as well, because, like, if you run it in a third-party runner, 23:53.760 --> 24:00.000 then we can't really trust what was going on there, right? So, but of course, like, the whole stack 24:00.000 --> 24:04.800 is open source, and, like, some, a lot of systems are very similar to GitHub, so, like, it's probably, 24:04.800 --> 24:09.840 like, very, really portable. If there's, if there's interest or any other system. And the, 24:10.800 --> 24:16.320 the Rigo's question, like, at moment, the things that you can write to policies against are those, 24:16.320 --> 24:23.120 those sources that tilt it support natively. So, so, we have, like, a big data type that we 24:23.200 --> 24:29.520 expose to the policies that has all the properties of the, of the built-in sources, and the 24:29.520 --> 24:34.000 elected, to, like, package manager things are not, like, natively supported by a, by a built-in. 24:35.200 --> 24:40.880 The, the some ways to actually, like, make them kind of, like, built-in sources, the way you do that, 24:40.880 --> 24:48.240 is you kind of, like, like, turn them into URLs. It's kind of, like, a complicated to explain in here. 24:48.240 --> 24:53.520 But, for example, if you, if you, if you look at the promise of the station for something called, 24:55.520 --> 25:00.160 the Docker Harder Dimitris, then we have, like, kind of, like, a special built-kit front end in there. 25:00.160 --> 25:03.920 And that one actually does, for example, like, a package is for Debbie, and an out-by-natively 25:03.920 --> 25:08.480 in built-kit. And so, so, in the case, they would show up as URLs in the policy, and you could write, 25:08.480 --> 25:12.160 like, like, a policy rule, specifically, for the, the game package. 25:12.960 --> 25:17.120 Okay, thank you. We are out of the time. So, if you have some further questions, please ask them on the 25:17.120 --> 25:21.040 metrics or catch up with Tony after the talk. Thank you.