WEBVTT 00:00.000 --> 00:17.000 All right, so we have very little time, I'm told we have two hours and we have to compress it down into 15 minutes, so we'll do it we can. 00:17.000 --> 00:25.000 My name is Michael Winser, I am the co-founder of our project named Alpha Omega, and this is Pierre Pochorelli, the secret engineer was the Fabius de Foundation. 00:25.000 --> 00:29.000 We have one mic between the two of us, so we will do that. 00:29.000 --> 00:33.000 Every time we talk about software supply, security, we have to put this slide up here. 00:33.000 --> 00:38.000 There's always new answers to understanding this, because what most people understand is that they're actually at the top of this thing, 00:38.000 --> 00:43.000 and they have no relationship to the things at the bottom, and so they can't fix them if their lives depend upon them. 00:43.000 --> 00:50.000 So open source, supply chain security, security is hard, and we'll talk about some of the ways it's hard. 00:51.000 --> 00:58.000 That depth of the pentagram, it's not just deep, it's entangled, it's hard to move things around, it's hard to cause change. 00:58.000 --> 01:03.000 There are a lot of humans, humans are hard, they're complicated, they have motivations, they have priorities. 01:03.000 --> 01:09.000 And over the past several years, we've seen an increased sophistication of attacks that are taking advantage of supply chain attacks, but why? 01:09.000 --> 01:14.000 Because it's the easiest path in now, which should be scary. 01:15.000 --> 01:24.000 So Alpha Omega is a project that was created with the mission of catalyzing, sustainable security improvements to open source across multiple ecosystems. 01:24.000 --> 01:29.000 We've been doing this now for about three years. 01:29.000 --> 01:38.000 When we think about the problem, Alpha represents points of leverage, where we can go in and make changes that will have lasting impact across entire ecosystems. 01:38.000 --> 01:47.000 But there are also hundreds of thousands, if not millions of projects that are not directly reachable or even influential, and still represent dependencies in your supply chain. 01:47.000 --> 01:55.000 And remember this, every piece of supply chain, every dependence you have, has total access to your build environment and total access to your runtime environment. 01:55.000 --> 02:03.000 So it doesn't matter how small or critical or how big or not important it is, it has access, and if it gets attacked, you get attacked. 02:04.000 --> 02:17.000 So with the past three years, Alpha Omega's raised a ton of money, we've spent a lot of money, we've made engagements with teams where we're doing audits, we hire people to have security engineering roles. 02:17.000 --> 02:20.000 Our work breaks down into four categories. 02:20.000 --> 02:26.000 Probably the most significant effort we do is making it someone's job to worry about security. 02:26.000 --> 02:32.000 When it's everybody's job to worry about security, it's a tragedy the comments doesn't get done. 02:32.000 --> 02:39.000 When you make it someone's job, everybody follows that person, there's a plan, there's a decision it gets done, and we've seen this time of time again. 02:39.000 --> 02:48.000 So we frequently help staff security engineers and residents at organizations where they can have that leverage impact that we care about. 02:48.000 --> 02:53.000 Category B is about package managers because they are the app stores of software development. 02:53.000 --> 02:56.000 They are, again, critical points of leverage and policy. 02:56.000 --> 03:01.000 Developers make trust decisions every day when they install a package from some package manager. 03:01.000 --> 03:07.000 They assume that everything about that package that they believe to be true is true, even when it might not be. 03:07.000 --> 03:12.000 Category C is actually where we start most of our engagements through audits. 03:13.000 --> 03:20.000 And it's again, amazing how if you start with an organization, you say, let's do a security audit, even how they respond to that prompt. 03:20.000 --> 03:25.000 Tells you a lot about the security posture of the organization, then what you find? 03:25.000 --> 03:33.000 That's interesting, but how they respond to what you find is what's really telling about where we're going, where we need to get to and the changes that we can make. 03:33.000 --> 03:38.000 And then finally, we have to acknowledge that we have no idea what we're doing. 03:38.000 --> 03:43.000 This is a very new space. There's a lot of technical debt and a lot of new tooling still being developed. 03:43.000 --> 03:48.000 And so we try to invest in the occasional experiments and innovation that help move us forward. 03:48.000 --> 03:53.000 These are just some of the organizations we've partnered with over the past three years. 03:53.000 --> 03:58.000 I have the unique pleasure of being sort of at the hub of this and talking to people in all these organizations, 03:58.000 --> 04:04.000 which affords me the luxury of learning about how great some of these people are and these projects are, 04:04.000 --> 04:11.000 and also how terrifying the situation is across the space and how many things we have to do. 04:11.000 --> 04:16.000 So I'm trying to go fast to give Pierre all the time to talk. 04:16.000 --> 04:19.000 I'm engaged with free bistie, actually just started somewhat organic. 04:19.000 --> 04:23.000 I don't even remember who introduced, but Ed Mast and I got together and started talking. 04:23.000 --> 04:29.000 And thought about how can we start working together and how can we make a change and how can we improve free bistie. 04:29.000 --> 04:32.000 And like I said earlier on, audits are our friend. 04:32.000 --> 04:36.000 We like starting with audits and Ed thought it would be a great idea as well. 04:36.000 --> 04:40.000 It had been a while since anybody done a meaningful audit across some of the free bistie code bases. 04:40.000 --> 04:49.000 So we started with that and the crux of our talk today is to talk about how that audit has already changed free bistie security culture. 04:49.000 --> 04:55.000 It's momentum, it's direction, it's intent and it's going to have a lasting impact on what was already a very secure space, 04:55.000 --> 04:56.000 but it's even more. 04:56.000 --> 04:59.000 And so with that I'm going to hand over the Pierre, it does all the work. 04:59.000 --> 05:00.000 Thank you Michael. 05:00.000 --> 05:02.000 I'd like to hold it. 05:02.000 --> 05:06.000 So we're in the bitty forum, you must have heard about open bistie free bistie, 05:06.000 --> 05:09.000 you know that open bistie focuses on security. 05:09.000 --> 05:14.000 But if you check the free bistie website, you will see that security only comes second to networking. 05:14.000 --> 05:19.000 And free bistie is built on bistie unique anyway, which means robustness, reliability. 05:19.000 --> 05:22.000 So we already have integrity, 05:23.000 --> 05:29.000 jails, bring confidentiality, one of the innovative security features that free bistie has been pushing over the years, 05:29.000 --> 05:32.000 because we've got sickum for a standboxing for isolation again. 05:32.000 --> 05:39.000 Then we have additional mitigations which we should use by some sister projects like how done bsd trusted bsd and so on. 05:39.000 --> 05:45.000 So over the history of free bistie has been a few remote bugs, but overall it's been a really solid record. 05:45.000 --> 05:48.000 So there is a security culture in free bistie. 05:48.000 --> 05:53.000 And it only made sense to have a good of it to like keep pushing the status. 05:53.000 --> 05:57.000 And here we chose to audit the b-hive virtualization layer. 05:57.000 --> 06:03.000 On this picture you have like a summary of the architecture, roughly drawn for you. 06:03.000 --> 06:06.000 Where b-hive is actually the hypervisor. 06:06.000 --> 06:09.000 So if you have a virtual machine, it talks both to the kernel and to b-hive. 06:09.000 --> 06:13.000 And then b-hive is to the operating system with process like everything else. 06:13.000 --> 06:17.000 It runs on AMD 64, which is what we used for the live testing. 06:17.000 --> 06:21.000 And R64, the ARM 64 bits platform is also impacted. 06:21.000 --> 06:25.000 So in total we had 20% days of audit on b-hive. 06:25.000 --> 06:30.000 And then also 40 additional days on capsicum because b-hive is a sandbox process. 06:30.000 --> 06:34.000 So it also made sense to capture this attack surface. 06:34.000 --> 06:37.000 And I see people taking pictures of the slides. 06:37.000 --> 06:41.000 You're welcome to do so, but we have a QR code at the end just for you to get the full deck. 06:42.000 --> 06:44.000 All right. Thank you, Michael. 06:44.000 --> 06:50.000 So we kicked off the project early in June about two months of total time of on the coded it itself. 06:50.000 --> 06:56.000 We had weekly updates with the penetration testing team, which was a synactive French company. 06:56.000 --> 07:02.000 So we had the pleasure to work with them and continuously validate the vendor bitu reported. 07:02.000 --> 07:07.000 Then coordinating this with the internal free base details. 07:08.000 --> 07:13.000 It also actually went all the way to net b-h-d because some of the upstream of the free base decode was from net b-h-d. 07:13.000 --> 07:21.000 So we then gathered fixes prepared binaries so that we could have a single day for releasing everything, 07:21.000 --> 07:23.000 coordinating the information. 07:23.000 --> 07:29.000 So we had security visories released from September on in two or three big batches. 07:29.000 --> 07:35.000 And then finally the report was published in its entirety in the middle of November by the foundation. 07:35.000 --> 07:38.000 We can see that on the website of the foundation. 07:38.000 --> 07:48.000 So in the report you will find the list of the vulnerability classes, which were important to track, that way we could group the different issues we found. 07:48.000 --> 07:55.000 Some were specific to behalf, like the MMIOIPI could probably be improved to avoid making more mistakes in the future. 07:55.000 --> 08:00.000 And otherwise, even if it's listing time of check time of views, basically risk conditions. 08:00.000 --> 08:05.000 Sometimes incorrect reference counting missing check for errors and so on. 08:05.000 --> 08:10.000 In practice it's all led to the same issue, which was memory corruption in most cases. 08:10.000 --> 08:16.000 So classic before the flows, but they were triggered by some other condition before. 08:16.000 --> 08:22.000 So we also noticed that it was really invaluable to have validators. 08:22.000 --> 08:29.000 So the auditors provided us sometimes with proof of concept to prove the issue was there. 08:29.000 --> 08:35.000 And we could use that very efficiently to check the patches to see that they were actually working. 08:35.000 --> 08:39.000 Many issues looked trivial to fix, but actually were a lot more complex. 08:39.000 --> 08:45.000 It came down to architecture specific aspects, sometimes even compare specific aspects. 08:45.000 --> 08:48.000 It was very complex in some cases. 08:48.000 --> 08:54.000 It's easy to underestimate the complexity, which is also the cause of the security bugs in the first place. 08:54.000 --> 08:57.000 We found fabricated to be great for the reviews. 08:57.000 --> 09:04.000 This is the tool that's already used by FreebaseD to check every committee into the system to verify that it's correct. 09:04.000 --> 09:09.000 With two pairs of eyes at least, but we also found it is not ideal for operational security. 09:09.000 --> 09:15.000 Because even though we were restricting the visibility of the issues to some people, then it was sending out emails in the clear. 09:15.000 --> 09:18.000 So each time for each comment, so that's not ideal. 09:18.000 --> 09:28.000 But that's also why it's important to find not just the audit, but also the fixes, the infrastructure of the project to withstand the security challenges of modern days. 09:28.000 --> 09:37.000 So with this said, we identified a list of mitigations that we can apply to prevent these issues from happening in the future. 09:37.000 --> 09:44.000 We found that we should apply maybe more source code annotations, so that the compiler can catch up and be more proactively attending the development. 09:44.000 --> 09:47.000 Directively attending the developer directly what has to be done. 09:47.000 --> 09:54.000 One way we can do that is to force APIs with returning error codes to be checked by the caller. 09:54.000 --> 09:57.000 So the compiler can do that if you undertake the code. 09:57.000 --> 10:02.000 This is either said done done because in order to implement this, we need to go through the entire source code again everywhere. 10:02.000 --> 10:07.000 Understand everything, apply the annotations, check that you don't break the bills on every supported platform. 10:07.000 --> 10:11.000 So this is not trivial, but generally you want to automate. 10:12.000 --> 10:23.000 So in free busy, maybe we're like in behind on tests, like some parts of the system are very well covered, but some others are not covered as much, and we should probably look at that for the. 10:23.000 --> 10:24.000 Yeah. 10:24.000 --> 10:35.000 I think that the point about testing is it's we always talk about everybody knows, but what both people have said is that it gives such incredible velocity to an organization that is then in response to a crisis. 10:35.000 --> 10:42.000 Because what's going to happen in the next year is it's going to be some nasty thing that happens and everyone's going to run around with their hair on fire trying to fix it. 10:42.000 --> 10:52.000 And having this kind of depth of testing makes that all that work goes smoother more reliably and you actually get the fix out the door faster because you have confidence in the testing framework that you have. 10:52.000 --> 11:02.000 So that automation basis is so valuable and I wanted to I hadn't caught this when we first practice this talk my practice, I mean we've got to get a 20 minutes ago. 11:03.000 --> 11:17.000 The the ops process of an organization, right is actually a key aspect of its security maturity and posture in terms of how well they have operational playbooks and processes and the tooling to support those so the fact that the. 11:17.000 --> 11:31.000 Fabricator tool wasn't set up for the limited disclosure that you need for vulnerabilities creates additional load on everybody or risk around it and the timeline for this particular audit was longer than anybody expected because it's sort of opened up all those doors and all those questions. 11:32.000 --> 11:38.000 Which makes it all the more valuable because now the organization is aware of them and working against them. I just didn't want to do that point because I thought it's important. 11:38.000 --> 11:47.000 That's great. So also to be fair, we had the set date for the next release so it made sense to wait a bit so that everything is ready. 11:47.000 --> 11:59.000 And that we don't have more work pushed on the release engineering and also generally due to mission is fantastic when you work in a team, especially when you don't sit in the same building or in the same company, you have different. 11:59.000 --> 12:13.000 Time zone, different equipment, different setups and so if you have a testing framework that was the same way for everyone then you can really validate that the bug is fixed and then it's going to work for everybody systematically and no matter how many pairs of eyes are going to have to to go straight. 12:13.000 --> 12:14.000 Yeah. 12:14.000 --> 12:23.000 So this also means additional documentation or maybe improving the quality because you don't want to also to overwhelm everybody with hundreds of pages every time. 12:23.000 --> 12:34.000 So in other direction we could go in this direction would be to create a training maybe go back on the BSD certification program which I think last traction in the past few years. 12:34.000 --> 12:52.000 We also suggested that the committee could be formed which would perform continuous security testing but also a lot of people to just ask questions maybe about specific patches is the reciprocity impact did I miss something without necessarily you know like asking the security team who usually handles vulnerabilities. 12:52.000 --> 12:59.000 To look into that because their focus should be on actual bugs and the tracking the fixes. 12:59.000 --> 13:07.000 So even if you have a general question about security to have a place to ask an essential place to prepare trainings documentation and so on. 13:07.000 --> 13:13.000 So we want to reinvigorate the security culture in Fribes D. It's super important. I don't have to convince you of that. 13:13.000 --> 13:21.000 It's a hostile world out there. There is a lot of work to be done. We need community engagement. Fribes D is a community project deal. 13:21.000 --> 13:30.000 So we only need to pay attention for our common good and if you want to get involved we suggest to write to the Fribes D security main list. 13:30.000 --> 13:36.000 I hope it's the most appropriate place. Maybe some Fribes D developers can confirm that. 13:36.000 --> 13:39.000 But otherwise I would say we can. 13:39.000 --> 13:40.000 Sure. 13:40.000 --> 13:42.000 So this is actually the test. 13:42.000 --> 13:49.000 So I put on my alpha mega hat here. How many people here are or have been a contributor to Fribes D in some capacity? 13:49.000 --> 13:51.000 So easily a third. 13:51.000 --> 14:00.000 Literally how many of you show up into that mailing conversation have become part of this transformation is one of the measures of success of this process. 14:00.000 --> 14:07.000 Because if an audit is something we have to keep doing again and the fall began and it gets harder each time, it doesn't work as well. 14:07.000 --> 14:14.000 And from my perspective, although we have reasonable resources to fund work, we don't have anywhere near the infinite trillions of dollars. 14:14.000 --> 14:18.000 The resources need to change and fix every culture and every organization. 14:18.000 --> 14:24.000 And so how an organization and a community like yours takes this and says, I care. 14:24.000 --> 14:27.000 I can get involved. I will help. 14:27.000 --> 14:35.000 Align priorities to this has a tremendous impact because your energies will create a wake behind you that other people will follow into as well. 14:35.000 --> 14:37.000 You know, Pierre has put a ton of time and effort. 14:37.000 --> 14:40.000 Ed and company have done a lot of work around this. 14:40.000 --> 14:42.000 That has created this initial push. 14:42.000 --> 14:46.000 It's on this community now to follow up on that push and to build on it. 14:46.000 --> 14:51.000 So it becomes a normal part of Fribes D which ultimately then drives its success. 14:51.000 --> 14:53.000 Because make no mistake. 14:53.000 --> 14:58.000 The next 10 years are going to be characterized by how secure is your project. 14:58.000 --> 14:59.000 So again. 14:59.000 --> 15:02.000 Yeah, of course. And it's the perfect time to say thank you to the Fribes D Foundation. 15:02.000 --> 15:05.000 But most of all in the Afro-Miga Foundation. 15:05.000 --> 15:08.000 To an initiative. I don't know how you want to call it. 15:08.000 --> 15:09.000 Whatever. Yeah. 15:09.000 --> 15:10.000 We gave money. 15:10.000 --> 15:13.000 They did work. 15:13.000 --> 15:14.000 Sorry. 15:14.000 --> 15:16.000 And actually I have probably the best job in the world. 15:16.000 --> 15:17.000 I get with me. 15:17.000 --> 15:18.000 No, no. 15:18.000 --> 15:19.000 It's really me. 15:19.000 --> 15:21.000 Because I have all this money that I have. 15:21.000 --> 15:22.000 I don't control directly. 15:22.000 --> 15:24.000 I have stakeholders to make decisions. 15:24.000 --> 15:26.000 But I get to go around meeting people like, 15:26.000 --> 15:30.000 working with organizations like this and starting these changes. 15:30.000 --> 15:33.000 And people are very happy when I shop with some money because it's such a hard problem. 15:33.000 --> 15:35.000 How do we get started on this? 15:35.000 --> 15:38.000 And again, everybody's current workload defines their priorities. 15:38.000 --> 15:42.000 And it doesn't include the Delta to start the security effort. 15:42.000 --> 15:45.000 But we can't permanently fund security work. 15:45.000 --> 15:48.000 So we try to find ways to start it and make it happen. 15:48.000 --> 15:52.000 And I also thanks also to, in fact, the Fribes D team, 15:52.000 --> 15:55.000 care, the community of how they handled this. 15:55.000 --> 15:57.000 You know, again, it took longer than anybody thought. 15:57.000 --> 16:01.000 But the results were 10 times more interesting and compelling than what we had hoped to get. 16:01.000 --> 16:03.000 We thought maybe some bugs, fixes and see like that. 16:03.000 --> 16:09.000 And it's there we thought there was an entire culture and process shift that was very encouraging. 16:09.000 --> 16:11.000 So we wanted to make sure we had plenty of time for questions. 16:11.000 --> 16:13.000 I did also promise some links. 16:13.000 --> 16:15.000 So this is a QR code to the deck. 16:15.000 --> 16:21.000 The deck also has some additional links at the end of the slides that you can go and click to. 16:21.000 --> 16:24.000 And I am told we have a whopping 15 minutes left. 16:24.000 --> 16:26.000 So we can either make stuff up and talk about things. 16:26.000 --> 16:28.000 But we'd much rather take questions. 16:28.000 --> 16:30.000 And here would have to say. 16:30.000 --> 16:31.000 Yes. 16:31.000 --> 16:33.000 No, the question at all. 16:33.000 --> 16:35.000 But just saying thank you. 16:35.000 --> 16:38.000 The Illumus community also uses the hypervisor. 16:38.000 --> 16:42.000 So any bug who fades, if it's for us to. 16:42.000 --> 16:45.000 So this was a, I mean, I'm going to repeat the non question. 16:45.000 --> 16:46.000 And what was the community? 16:46.000 --> 16:47.000 Illumus. 16:47.000 --> 16:50.000 The Illumus community uses the Fribes D base. 16:50.000 --> 16:51.000 So anything we do for them. 16:51.000 --> 16:53.000 Does use the open scenarios base. 16:53.000 --> 16:55.000 Open scenarios base as well. 16:55.000 --> 16:56.000 Right. 16:56.000 --> 16:58.000 And uses B hive and that makes everything better. 16:59.000 --> 17:05.000 I have a, at your random question, how many people here represent businesses that are effectively monetizing 17:05.000 --> 17:12.000 Fribes D in some way where they're taking Fribes D and using it to build products that they are then selling? 17:12.000 --> 17:16.000 I would like to talk to you after the talk. 17:16.000 --> 17:22.000 One of my goals is to change the economics of security and open source. 17:22.000 --> 17:25.000 Because I guarantee each one of your businesses has product managers. 17:25.000 --> 17:29.000 Like me who have business goals, growth, success, various things. 17:29.000 --> 17:32.000 And then customers say I need to feature X or whatever. 17:32.000 --> 17:39.000 How many of those customers are talking about security now and how are you dealing with a CRA expectation of security and so forth? 17:39.000 --> 17:46.000 You know, but your organizations at your robot present sustainable lifeblood to a culture and a community like this. 17:46.000 --> 17:48.000 And so it matters. 17:48.000 --> 17:51.000 Next question, please. 17:52.000 --> 17:54.000 Stand you in the science. Yes. 17:54.000 --> 17:56.000 So going back to the XKCD. 17:56.000 --> 17:57.000 Yes. 17:57.000 --> 18:05.000 So what do you, resin, upper omega think about the long tail of the project down at the bottom? 18:05.000 --> 18:07.000 As we're seeing the person outside. 18:07.000 --> 18:08.000 Yep. 18:08.000 --> 18:10.000 How do you fix that? 18:10.000 --> 18:16.000 So the question was how do we add alpha omega think about the long tail of single maintainer or smaller projects? 18:16.000 --> 18:19.000 How are we going to address them and fix them? 18:20.000 --> 18:27.000 I would invite you to follow one of the links at the end of this deck here to read our annual report that will give a longer answer. 18:27.000 --> 18:31.000 What I can tell you is, and again, follow the QR code to the deck. 18:31.000 --> 18:32.000 Get the links. Click away. 18:32.000 --> 18:35.000 Don't bother taking pictures of text. 18:35.000 --> 18:38.000 It's a really hard problem. 18:38.000 --> 18:42.000 We have a try to a few things and we're still trying out different approaches. 18:42.000 --> 18:52.000 One of the things that we've been we had tried is essentially using automated techniques to scan literally thousands of projects. 18:52.000 --> 18:58.000 Find vulnerabilities automatically, maybe not all the ones, but looking for the, oh my god, you know, stupid ones we can fix. 18:58.000 --> 19:03.000 Generating fixes automatically and then sending them on to the maintainers. 19:03.000 --> 19:06.000 And it did not work out the way anybody thought it would, right? 19:06.000 --> 19:08.000 Some cases, they got fixed. 19:09.000 --> 19:16.000 The maintainers are already overwhelmed with other bots and other systems that may or may better or not as good as ours whenever. 19:16.000 --> 19:23.000 And the really important thing here, even tried to like talk to some people about having them go and do a basic security workshop. 19:23.000 --> 19:28.000 And we had GitHub is sponsoring a security workshop sort of one day effort. 19:28.000 --> 19:34.000 Just to tighten up your repo, tighten up your build process, basic hygiene of your systems. 19:34.000 --> 19:40.000 But when we talk to people, especially in this sort of broader community people, they're already essentially maxed out. 19:40.000 --> 19:46.000 They're doing nights and weekends, you can't pay them to have more nights and weekends because only thing to do is make them more stressed. 19:46.000 --> 19:53.000 So we are rethinking our approach, very open to ideas and suggestions, which doesn't mean I don't have any. 19:53.000 --> 20:06.000 And one of the things that I am looking at to do in 2025 is to normalize, commoditize and make widely available public data about the metadata across the entire ecosystem. 20:06.000 --> 20:15.000 Another thing I'm trying to do is metaphorically when we try to do these automated approaches, you'd go out, pay an organization, do some work, they come back. 20:15.000 --> 20:25.000 And they said we've scanned 3,000 or 9,000 projects, we found 10% vulnerabilities, we fixed 50% of those and 25% of those were actually accepted. 20:25.000 --> 20:27.000 I didn't know how to talk about that usefully. 20:27.000 --> 20:35.000 It was like literally sending some people out in a rowboat to the Pacific garbage patch, collecting a pile of plastic, coming back and say, look plastic. 20:35.000 --> 20:37.000 The world's better now, right? 20:38.000 --> 20:43.000 And so we're shifting our approach to thinking about it as sections of beach. 20:43.000 --> 20:51.000 And imagine a community beach or a local beach that has become overrun with pollution or dangerous things and, you know, tin cans and whatever. 20:51.000 --> 20:56.000 And there's no longer being used effective as beach or if it is, it's a high risk beach. 20:56.000 --> 21:03.000 And imagine if we can kick start a process to clean that beach, not of everything, but of a key set of common risks and vulnerabilities. 21:03.000 --> 21:07.000 And then if the community then says, wow, our beach is usable again, we care about our beach. 21:07.000 --> 21:10.000 We're going to stay in that beach and keep it clean, right? 21:10.000 --> 21:13.000 That's an effort that we've done now successfully with air flow. 21:13.000 --> 21:18.000 I'll be speaking tomorrow with one of the air flow security committee about exactly that process. 21:18.000 --> 21:25.000 And in many ways, what I'm hoping to achieve here is that the free bst, which is already a great beach and very healthy in a lot of ways. 21:25.000 --> 21:29.000 But we have to acknowledge there were things that were not as good as they should have been. 21:29.000 --> 21:35.000 Can we keep this beach even cleaner over time and make it a great place for people to hang out and keep maintaining it? 21:35.000 --> 21:43.000 So that approach allows us for to make progress and tangible progress, which, by the way, makes it easy for me to get more money to fund these efforts. 21:43.000 --> 21:48.000 Because when I go tell my stakeholders, hey, we did zero point zero zero one percent of the problem last week. 21:48.000 --> 21:50.000 Please give me millions of dollars. 21:50.000 --> 21:53.000 It turns out it doesn't really work that way, right? 21:54.000 --> 21:56.000 All right. Thank you. Is that a good answer? 21:56.000 --> 21:57.000 Yep. 21:57.000 --> 22:01.000 I think we have time for one or two more questions. 22:01.000 --> 22:04.000 What we've stunned you in the silence. 22:04.000 --> 22:05.000 Yes. 22:05.000 --> 22:27.000 You're hitting all of my hot points. So the question was, do you have automated ways to discover the dependencies? 22:27.000 --> 22:40.000 Of your code? And it's, it's axiomatic that even if you think you know you're probably wrong. 22:40.000 --> 22:45.000 And if your build environment is normal, it's pulling in random shit at build time that you didn't know happened. 22:45.000 --> 22:50.000 So hint, turn off network access after provisioning your build environment so that it can't do that. 22:50.000 --> 22:55.000 Break the build, find out what did it should in the head, kill it with fire, start again, right? 22:56.000 --> 23:10.000 So that from part of my goals around this space is also to create this what I'm thinking of as a public data set of open source project metadata, including hopefully a canonical view into the dependency space. 23:10.000 --> 23:15.000 I will admit that I'm less interested in telling you in your content exactly what dependencies you have. 23:15.000 --> 23:27.000 And more interested in getting a statistical thing saying uses a food 1.2.3, 70% of them bring in bar 2.3.4, 6% bring in bar 2.4.5 or whatever. 23:27.000 --> 23:32.000 And I can get a sense of where the space lies and where the risk is. 23:32.000 --> 23:39.000 And one of my intuitive ideas is that there are centers of gravity that have become stuck. 23:39.000 --> 23:48.000 Where people are using some version of something, the maintainers of that have moved on to a future version and are doing a lot of the fixed work there and their energies and intentions are there. 23:48.000 --> 23:52.000 But there's a bunch of dependence downstream that can't get off that version. 23:52.000 --> 23:57.000 And we don't know about it because each one of them knows they're stuck there, but then I don't have the global picture of that. 23:57.000 --> 24:13.000 So this, what's one of my major initiatives in 2025 is to have a sort of statistically useful and authentically as an like a tested data set from open source tooling that produces it in a very ways that we can start to reason across this space. 24:13.000 --> 24:21.000 I will point out that the world of CNC++ is a wasteland of dependency management and it's very hard to do it well. 24:22.000 --> 24:31.000 I'm actually probably going to look at what can we do there and more in terms of recognizing patterns of code rather than trying to sort of package for bar. 24:31.000 --> 24:44.000 The other thing I'm thinking about doing and it's another answer to your question is what do we do when the next exe situation happens to some soul maintainer who is already, you know, this high, right. 24:44.000 --> 25:00.000 I'm going to be working with people like Pierre and started to create or even just a reason about what I think of as a security engineering core of engineers an open source core of security engineers who will start to form policies and guidelines and playbooks. 25:00.000 --> 25:08.000 And to act as a collective, you know, Pierre can actually take vacations, but when something happens on somebody else from somewhere else can say, I've got this one. 25:08.000 --> 25:12.000 And so that when the next exe situation happens, first of all, there's already a human connection. 25:12.000 --> 25:21.000 There is a reasonable reputational trust that when you show up to help because right now if somebody showed up at the next exe saying, I'm from the government, I'm here to help you. 25:21.000 --> 25:24.000 What's the reaction going to be like bullshit, right. 25:24.000 --> 25:30.000 Get away from me, you're trying to hack me even worse or whatever, and so we need to establish those relationships first. 25:30.000 --> 25:35.000 Again, these are all early efforts that we're trying to figure out, but it's part of what we're trying to do. 25:35.000 --> 25:37.000 So, yep, please do. 25:37.000 --> 25:40.000 Yeah, so maybe I can add something to your question. 25:40.000 --> 25:46.000 So free based the, I mean, the open source spectrum is very diverse and free based is actually a bit different from what you explained. 25:46.000 --> 25:47.000 Yeah. 25:47.000 --> 25:52.000 You cannot just cut network access and expect the real to break because everything is self-contained into the business system. 25:52.000 --> 25:53.000 Yeah. 25:53.000 --> 25:55.000 But on the other hand, we cannot automate this process. 25:55.000 --> 25:59.000 So right now, don't know if you heard about SBOM, the software a bit of material. 25:59.000 --> 26:03.000 We have an initiative as part of the free based project and sponsored by the foundation. 26:03.000 --> 26:07.000 To look at this and document the provenance of every component. 26:07.000 --> 26:09.000 So we, this is actually ongoing right now. 26:09.000 --> 26:12.000 And I think it's also going to happen with the ports. 26:12.000 --> 26:15.000 I think there's also a third in this direction to make it work. 26:15.000 --> 26:19.000 But in the port, it's probably a bit easier because we already keep track of like the home pages, 26:19.000 --> 26:25.000 where the software comes from, where it was obtained from this is very systematic into the BSD world. 26:25.000 --> 26:27.000 And it's also strengths of BSD. 26:27.000 --> 26:28.000 Yeah. 26:28.000 --> 26:29.000 Excellent. 26:29.000 --> 26:30.000 That's exactly the right thing. 26:30.000 --> 26:36.000 And SBOMs are very powerful across organizational and visibility trust boundaries. 26:36.000 --> 26:38.000 When you're producing binaries and somebody else to consume it, 26:38.000 --> 26:40.000 they don't have access to your inner workings. 26:40.000 --> 26:44.000 SBOMs let them reason about your software even when you're not there. 26:44.000 --> 26:45.000 Okay. 26:45.000 --> 26:47.000 I think we're almost done with time. 26:47.000 --> 26:48.000 And so in the interest of sanity, 26:48.000 --> 26:51.000 unless there's any more pressing questions. 26:51.000 --> 26:52.000 Going once. 26:52.000 --> 26:53.000 Going twice. 26:53.000 --> 26:54.000 One more. 26:55.000 --> 27:13.000 So the question was, do packaging repositories effectively solve the what version are people using? 27:13.000 --> 27:17.000 I can't answer that question without wondering into quantum mechanics. 27:17.000 --> 27:19.000 I feel like it is actually not true. 27:20.000 --> 27:25.000 And the resolution of a package depends upon the package ecosystem. 27:25.000 --> 27:28.000 How it resolves pin versions or not pin versions. 27:28.000 --> 27:34.000 How diamond dependencies get resolved at the local client in the Python ecosystem. 27:34.000 --> 27:37.000 It actually get resolved by any one of six or seven different clients. 27:37.000 --> 27:39.000 Each of which will interpret the resolution differently. 27:39.000 --> 27:44.000 And so there is no correct answer, which makes me cry. 27:44.000 --> 27:46.000 But this is part of the problem. 27:46.000 --> 27:51.000 By the way, if you are contemplating designing a new package manager and or a new programming language, 27:51.000 --> 27:56.000 and you are not including the two things together and making the language aware of the package and vice versa, 27:56.000 --> 27:58.000 you're making a big problem for the future. 27:58.000 --> 27:59.000 All right. 27:59.000 --> 28:01.000 We have two minutes. 28:01.000 --> 28:02.000 So. 28:02.000 --> 28:04.000 I just want to say one thing for your question. 28:04.000 --> 28:06.000 The problem with the package is. 28:06.000 --> 28:08.000 I'm going to record your world. 28:08.000 --> 28:09.000 We kind of record. 28:09.000 --> 28:12.000 The problem is some built systems try to be helpful. 28:12.000 --> 28:17.000 And so they say, oh, you provided me with the path to lip curl, but I have my own built in lip curl. 28:17.000 --> 28:18.000 I'm going to use that one instead. 28:18.000 --> 28:20.000 And it's silently does it. 28:20.000 --> 28:21.000 And you don't even notice. 28:21.000 --> 28:26.000 And then this thing uses the vulnerable lip curl, even though you thought you had it all up there. 28:26.000 --> 28:27.000 And it's things like that, like, 28:27.000 --> 28:30.000 built systems are tried to be helpful. 28:30.000 --> 28:32.000 Most of the time are not. 28:32.000 --> 28:33.000 All right. 28:33.000 --> 28:37.000 With that positive and exciting note of the future. 28:38.000 --> 28:40.000 I want to thank again, Pierre. 28:40.000 --> 28:41.000 My colleague in this was fantastic. 28:41.000 --> 28:43.000 And thank you all for taking my close today. 28:43.000 --> 28:44.000 Your heartbeat's invaluable. 28:44.000 --> 28:45.000 We appreciate it.