Well, I'll get going then. So hi, welcome to this panel on cloud native security landscape, myth, dragons and real talk. And the reason I put this panel together was, I think, basically, as you would have seen from this morning, the keynotes and so on, this is a very active developing space. And I think even for those of us who are working in it, a very confusing developing space is to know, well, what is exciting for the next five years, what is practical now and so on. And so we'll get into why these lovely people are here, just a few moments of talk. So hi, I'm Ed. I work at Cystig on open source and Falco in particular. So I ask GPT, like everybody, what do you think of the acronyms that Gartner uses about security?  And surely it should be more simple to understand. So Gartner has got some of these going on. Great, well, maybe they like acronyms too much. Let's ask Forrester. Now Forrester have their own set that they really like and chat GPT thinks of theirs. So we have chance to reinvent the world in open source. We're standing on the shoulders of giants. Surely we can see more clearly than everyone who's gone before us in the industry and not follow the same confusing example. Well, I'm sorry, but we're inventing our own set of acronyms to go with them. Chat GPT, probably trained too late in the day to understand most of the ones we are swimming in. We think like guwak, salsa, or S-bombs, all these things that are coming out, all really important, all their place in the world, the way we sit. Well, one place we don't start is with the simple architecture. This was from the slide this morning in the keynote just demonstrating some of the complexity of the attack surface in cloud native apps and installations. So that's why I gathered four friends who know everything there is to know about their part of the world to try and simplify some of this for us, try and give us some guides as to what is the best place to pay attention in cloud native security right now. In addition to the technology, the other thing we want to make sure we cover in this panel is kind of all these human elements. We hear a lot about the software supply chain. We know that we have to pay attention not to just what is actually running, but the whole lifecycle deployed, distribute, develop. This is from the tag security report on cloud native security, by the way. So as we get going, I want to make sure you do some work as well in the crowd because I think we'd love to get a sample of where you're at. So I've got some easy things from easy to hard. Raise your hand if you use in GitHub in production seriously. Okay. Still not everybody, this is good. Kubernetes, okay. What about on clouds versus on-prem in the cloud? Okay, your hands down on-prem. Thank you. And who is using any open source security tools right now? Well, I know you are, Lloris. Could you catch any of those out, please? Falco, thank you crowd. Any others? I think Emily, you're cheating. I was like. Cool, that's awesome. Thank you. Well, hopefully this gives everyone here a little sample of where we're at. So I'd love to introduce my panellists. I'm going to get down from this sort of Godlike overview and come around the side now so we can have a chat. Over that order. Well, we can introduce in any order in particular. But I've asked the panellists to maybe spend about 90 seconds introducing themselves where they come from, kind of what they're working on. Kim, should we go from you? Almost, thank you. Sure, hey everyone, thanks for joining today. My name's Kim Lewandowski. I'm currently the head of product and co-founder of a new startup called Chain Guard. We're about a year old now, trying to help with all this software supply chain security stuff. Prior to Chain Guard, I was at Google for almost a decade, working on some developer tool stuff and cloud products and then security. And then before I was a product manager, I was a developer, so I went to the dark side. Yeah, that's me. So Kim, what are you working on right now that people need to know about? Oh wow, so yeah, I mean at Chain Guard, we have some enterprise products around security space. So two of them right now, one is a risk management platform called Chain Guard Enforce to help organisations get a handle on their supply chain security posture and give them some tools and help them get better. And then we have another product called Chain Guard images which are hardened container based images with all the software supply chain goodness baked in. They're reproducible. We carry the pagers, we patch them for vulnerabilities. They come with S-bombs produced at build time and yeah, pretty cool. And so those are the main focus right now and we've been growing our team, so a lot of management and getting everyone rallied. So life's easy, right? Completely. Loris. Hi everyone, my name is Loris De Joanni. I'm a CTO and founder at CISDIG. CISDIG is my second company. My first company was called Case Technologies and was the commercial entity behind an open source network analyser called Warshark. So I've been involved with open source pretty much my whole career. Now one of the roles that I have at CISDIG is leading the open source team. For the first part of my career it was more like computer networks and network analysis and then after starting CISDIG in 2014 focusing a lot on cloud native security and visibility. One of the things that we do at CISDIG is Falco, the open source runtime detection tool which is part of the CNCF. Loris. Randall. Hey, so what's up everyone? I'm Randall, nice to meet all of you. So I've been working in security in a lot of weird positions just for my whole life. I got started doing operating system security for OpenBSD a really long time ago. Then I wrote and sold video game hacks for years which was pretty fun. Then I got into the IAM space working on authentication and authorization for developers and I did that at a company called Stormpath and we later got acquired by Okta and then we built the developer platform at Okta and now I work at Sneak doing DevRel, which is super fun and basically we are just trying to make it easier to find and fix vulnerabilities in the software that everyone is writing, so yeah, that's me.  Yeah, so if you are not familiar with Sneak please raise your hand real fast. Yeah, okay, cool. So we're a developer security tool so you can plug us in and we do static analysis of the software you're writing to help find vulnerabilities. We also look at dependencies, container images, we have a cloud security product, et cetera, but just everything developer is security related. Thanks, Isaac. Hi everyone and thanks for coming. I'm glad to be here. My name is Isaac, I'm a product manager at Google. Right now at Google I work in supply chain security. Two parts of my work, number one is I work closely with the Google open source security team who are behind things like Sigstore and Salsa and Gwark is a new project I saw on a slide earlier that I've been working on as well. And then the other side of my work is on Google's internal first party supply chain and so I do a lot of work there right now on Google's first party production of S-bombs and conformance with the executive order. Some of you may be familiar with. My history last 15 or so years been at Google, Microsoft, Twitter, Stripe as a product manager and then in pre-history, again like him was a developer so also flipped to the dark side a little while back. Glad to be here, thank you. Lovely, well thank you so much for being here panel and hopefully you've got an idea of what everyone's expert on and what we can talk about. An exercise for you during the course of the panel, I had meant to sit everybody left to right in terms of the place in the supply chain. If you can figure this out and tell us what order people should be sitting in by the time we're done then there is a nonspecific prize of little value for you. Is some of us shifting left or shifting right? You must give your answer only in assembly code please, bit shifts, thank you. Awesome, well we'll get going. By the way, this is intended for you to be able to ask questions as well. I've obviously prepared some in case you're so full of lunch you just want to be entertained but feel free to stick your hand up, I'll call on you and challenge folks, ask questions. We'd like to keep this interesting and I think the most interesting people here are actually you, no offence panel, but we want to hear the broad range of concerns from the audience. So I'm going to kick off and just, you can choose your own order to answer panel but you've all talked about different places, different focuses on the supply chain and we hear a lot of things that are important coming from your regions, a lot of things that we as users and as operators need to pay attention to. So from your part of the world what do you think is the single most important thing you're telling people about or a single most important issue you feel people should be paying attention to right now? Go for it. I'll go for it. So I think people talk about the supply chain a lot and there's the standard diagram I've seen at least 16 times already today. And I think there are various projects particularly in open source addressing points of weakness in the supply chain. So Salsa focused on build integrity and tamper proofing artifacts and so on and being able to anchor your trust in a build system. I think more fundamentally or one of the areas that folks struggle with and seems to be a very high priority to me is really becoming aware, if you're not already aware, accelerating becoming aware of what your software dependencies are. And so looking upstream in terms of the software you're ingesting, we've seen stats around 85% to 97% of commercial software has some open source as part of its dependency. And I think there's a universal feeling that taking open source dependencies in your software introduces some risk. And I think that that's a well understood concept and people could get that. But it's very unspecific. It's rather a feeling or a vibe that people get. There's no very difficult to quantify that risk. It's very difficult to assess it. It's a latent risk essentially. And so in order to begin to reason about that risk and assess it and manage it and systematically reduce it over time, step one is really understanding what your dependencies are. And it's been surprising to me the extent to which folks aren't always aware of what even are all my dependencies. Do you have a good sense of the inventory of the software upstream of what you rely on? And it's a big gap. And I think closing that gap is step one to, as I say, beginning to quantify, to reason about and systematically reduce risk over time. You first got to make it visible. And step one in making it visible is really understanding what your dependencies are. And it's a very fundamental thing. And it's a step that many organisations are just beginning on. But it seems absolutely vital to me. Awesome. Thank you. Quick poll here. Do you think you have a good grasp on what your open source dependencies are? I think that validates very well at your point. Do you think you should do? Good for you. And what do the rest of you think? Awesome. So I'm going to jump in here because I was told controversial opinions, right? Yeah. Okay. I'm going to hit you all. So this is a security conference. But my, and this is not representative of SNCC. By the way, I know this is recorded. So everyone forgive me in the future. But I... If Randall disappears, we know that. It's a conspiracy for sure. But my opinion, so the question is like, what is most important that's going on that people should be aware of? I would actually say maybe in, as a security community, we like, you know, we overmarket ourselves sometimes in the sense that myself as a developer, I guess what I'm trying to say is, I don't actually care about security all that much. Like I like the idea of things being secure and building reliable software that's safe for people to use. I think that's obviously the goal. But I think the key part in making that happen is making sure that developers are embedded in the security life cycle and finding issues really quick and fixing them on their own, ideally without a big security team, triaging and managing all the risk. And I think a lot of the times in the security space, we like run the risk of trying to convince developers to care about security or trying to convince people to, you know, put a ton of time and effort into it and learn about all these new protocols. I mean, you saw the alphabet soup on the screen earlier. I think for developers, it's just way too much. And so as a security community, my thought is, let's just do our best to make it automatic for people. Let's build tools that are going to be super developer focused, give them a really nice experience so that they don't even need to think about it 99% of the time, only when it's absolutely critical. So that is my controversial opinion for the panel right now. Awesome. There's a lot of nodding heads, you've got friends. Sounds like GPD is in charge of security. I would love that. That'd be so great. Maybe latching a little bit on the concept of, it's important to start to understand what our dependencies are and what is the software, open source or not that we are relying on when we are running our applications. One thing that I'm seeing from my perspective, since they go first, a platform that essentially covers the full life cycle of security for applications in cloud native environments. But one thing that we are noticing our users latching a lot to is the idea of being able to prioritize. So not only to fully understand what you have, but also if possible reduce the burden. And for example, one way that we do that is by leveraging a runtime information. So you have a thousand dependencies. How many of them are they actually loaded in memory?  And so I think as an industry, there must be an effort not only on accuracy and precision, but also in this ties to the concept of let's make this easy for the developers, to reduce the work, reduce the burden and prioritize if possible in a way that is from one point to be effective and from the other point of view less stressful. Sure. Yeah. Sadly, I don't think I'm going to be very controversial because I agree with everyone. The way I've been looking at a problem which kind of encompasses what these other panelists have said is so it's a three-stage journey. It's no fix and force and this may sound familiar to some of the Googlers in the room because it was something I helped work on while I was at Google. But if you're clueless on where to start on the journey of supply chain security, like the first stage is no. You got to know what you're running. You got to know where it came from. You got to know how risky that software is. And then once you have that information, once you sort of know what the heck's going on in your production environments, the next stage is obviously you got to fix it and ideally fix it and prioritize it in a way that you're getting the biggest bang for your buck. So lots of tooling and stuff that's out there now for helping fixing things. And then the last stage is you got to enforce it, like throughout your organization. So if you've decided to take a stance that everyone must use 2FA or you must use a certain technology or do things a certain way, then you got to make sure that that's what's being complied to throughout the organization. So three stages, no fix and force, and that's where you start on this journey. Well, thank you. I'm going to provide, if not controversy, at least a searching question, because we said, well, you, you need to be you, but who is the you? Like I think quite clear on Randall's you is a developer that you can still talk about it. But like when you say you need to be aware of these dependencies, you need to fix and force. Who is that person? That's everyone. Now, I mean, this is maybe where the controversy comes in because I see it every day where there's a constant tension between the security team and the developer teams. And security team wants to do things a certain way, but the developer team says no, get out of our way. We're not using that thing. We're not following your policy and it's this constant conflict that's going on. So I think, you know, as Randall's point, like these things sort of need to be done easy and by default. So you really need to win over developers. You need to get out of their way, but you need to give them the tools that they need to do their jobs and make it so they don't have to think about these things. So it is the chain guard mission to make supply chain security secure by default. So that's something we take to heart and we realize like we're going to be done as a company, as a startup, if we don't do these things that are easy for developers and people to adopt. So. I want to add one thing to what Kim was just saying, which is like, okay, so what is the real key, you know, to like getting a developer to actually like fix some stuff, which is really hard to do. Like I know a lot of you, everyone in this room obviously cares about security because you're here, but one of the most difficult things is getting developers to care enough to actually go in and fix stuff. Even if you have like a backlog and prioritizations and all that stuff, right? It takes time and that's usually not someone's first focus. So my personal opinion, there's like three escalating ways to like achieve this. Like the first thing is providing enough education for people so they can Google something and like learn about it and like solve the problem. That's like step one, right? And thankfully there's like amazing blog posts and YouTube channels and stuff that cover a majority of that stuff. Then you have, I think escalating from there or like getting better would be like gamifying experience. So how do you incentivize developers to make security fun? And I think there's a lot of ways to do that. Maybe it's giving them points or giving them prizes for fixing things. This is a shameless self-plug but we actually run an event called the big fix every year where that's basically what we do. We try to get developers to just fix as many open source vulnerabilities as possible and compete against one another for prizes. So that's like the second thing you can do. And the third thing you can do is what all of us in the vendor community are always working towards which is having that like seamless experience of tooling that just like eradicates the issue to even think about in the first place which is super powerful, you know? In general, I think that if there is something that modern shift left security as drastically changed is the relationship between the security team and the developers. And the giant increase in engagement that the developers have, you know? They are much more part of the process. Now the question is do developers like this or not? That's a great question. Isaac, I'm hoping you can also talk about customers and what works well there as well. And we have an audience question. Great. We talk a lot about that. We sort of talk about security by abstention, right? And a lot of our focus, it seems like it's an industry, it seems like it's really been sort of like just take care of the problems that security is not filled, right? But security really likes visibility into the processes that's happening. And one of the problems that security's had for a long time is a mishmash of all these different tools that made their lives impossible with millions and millions of findings, right?  One is the SOC or the scene, right? Where all the tools interoperate so they have one view of everything. And the other was baseline, right? We can't fix everything. Let's focus on where we're at now and getting better while not making it worse. So how do you think that we work better with security teams in their terms and not just tell them, don't worry, we're safe? I'll just repeat the question because there's a recording you saying basically we've talked a lot about Dev and Ops left security out of the equation and they have two ways. How can we bring them more into this pattern that we're talking about? When they're not going to look at any of our tools. Right, right, they want their own world, the things they're used to, how can we plug them with them? So I think, I mean, I think partly it's about providing a common view of a common set of problems. And one of the things I'm working on at the moment around the topic of S-bombs and so there was an executive order 18 months or so ago and what do you know if you supply software to the federal government then starting real soon, in fact June, if you're on a certain list, you'll be required to produce S-bombs to provide alongside your software to the federal government. And so there's thousands, perhaps tens of thousands of organisations on the country right now in the US getting good at producing S-bombs and getting ready to ship them to the federal government. And on June 15th, the federal government is going to wake up to a quarter of a million S-bombs in their inbox wondering what are we going to do with these things? And what they're going to do with them, I hope, is start using tools like GUAC. And I'm really excited about GUAC as a product being an aggregator of this metadata. And so if you imagine, we're going to be, thanks to the US federal government, we're going to start swimming in a sea of security metadata about our dependencies. And we're going to be overwhelmed by data. And GUAC as a product is about how do we turn that data into information? And I think there's a secondary question then is how do you turn that information into value? And that's that second process is audience specific. There are certain things that developers are going to want to do with a sea of S-bombs. Like when I import a new dependency into my IDE, I'm going to want to see it pop up and inform me about the risk of that dependency transitively down its dependency graph and so on. If I'm a risk assessor or a compliance expert at an organisation, I'm going to want to take that data and have tools to convert that information into value for me if I'm a security professional. I'm going to want to look at a same view of the same data but customized to me to give me value. But I think it starts with everybody looking at the same set of data. And I'm encouraged by things like the executive order to start to force the issue to have the industry and open source and enterprise produce more security metadata about their software. There are these missing pieces that what do you do with it then? But gathering it all in the same place and so various audiences can share a common view of it seems absolutely key to me. So can I just ask Isaac before you give up on the mic? As you're touring around and listening to people and we're talking about security folks and the executive order on S-bombs, do you get the sense that security professionals are ready to access S-bombs in this new reality or it's just like another thing coming their way? And we talk a lot about it, but when it's going to hit the security professionals desk, are they ready? What are they going to do? Absolutely not. And I think it's a good point and there's a lot of focus right now when people talk about S-bombs and the executive order and you hear it at this conference as well. There's a lot of focus on how do we generate S-bombs, what are the tools we use to generate S-bombs? That's only a part of the problem. What do you do when you do wake up to a quarter of a million S-bombs? I think something that's interesting about the S-bomb journey of the industry is on at the moment is it's the very beginning. S-bombs is the beginning of end-to-end instrumentation of a supply chain. Once you've built the bus to transport S-bombs from here to there, there's all kinds of things you're going to want to put on that bus as well. You're going to want to put salsa providence on that bus. You're going to put open SSF scorecard information on that bus. You want to put open source project lifecycle events on that bus, but S-bombs is forcing the creation of a metadata transport layer throughout the supply chain and it is absolutely the very, very beginning and I think, Ed, to your point, there's a massive tools gap around at the moment around how do we process and reason about this supply chain metadata? We're about to drown in it. I don't have a great answer apart from pointing to your point. There is an enormous tooling gap at the moment and I think it's an opportunity as well as a challenge. Thanks. I'd like to keep on this question of the security professional and where they mesh in with the operator and the dev and what you see work already. So I don't know if anyone on the panel can talk from customers and what they see in the world. Okay, I'll add one other thing, sorry. I love this topic because whenever people talk about a lot of tools and security professionals wanting that visibility and measuring everything differently like what is success, is it baseline or this without a reachability or whatever the discussion is, like my instinct always is like, we should just build another tool to centralize all the tools and then like, you know, that's always a solution but then it's always just like another thing, you know? And the way I like to think about it is there's like states, you know? There's like the perfect state and then there's like the current state which might be terrible. Some places are really good at other places.  Like you don't necessarily have to be perfect and have a single, you know, security operations center that aggregates everything and perfectly classifies and prioritizes everything all the time. You know, one day I'm sure that's going to be the standard for everyone but today like it's just not really feasible. There's just too much going on. So and again, this is not the sneak official opinion but my personal opinion is what you want to do is just like build a culture of like action, you know? So whatever your security team is doing, if they're measuring via just how many net vulnerabilities do we have or whatever thing they're looking at, that's totally fine. You just want to build a culture where the security team is assisting and empowering the developers and operations people and everyone else to just go in and fix stuff without a lot of process. And the less process you have, the easier it's going to be for people to like get excited about it to actually do something to make a difference. So just basically like just like just do it. And then other than that, like it'll sort of sort of sell out in the longer. It's a social problem, you're saying. Well, is that a social problem as much as a tool problem? It's yeah, like an everything problem. Lloris? And that's why in my opinion, especially, you know, going back to the question, how do we make the different personas talk better and that would generate the right data that can be consumed by multiple teams? I think it starts from standards rather than writing more software. And that's why, for example, this conference is really important, you know. And the work that the CNCF is doing in a way that is biased toward building tools, you know. And having these tools becoming like a way for people to interoperate, stuff like OPA, stuff like common formats or S-bombs, stuff like the Falco language. These are the only way in the future that we have to sort of agree on a common language that then we can all use. And I think that visibility comes from there. I think that communication and the correct sharing information then comes from that. And that's why I believe and Cystic believes that the future of security is open exactly for these rates. I agree too. And that was kind of my answer to your question. Like these tools and stuff, they need to be rooted in open source standards and all the solutions. And I hope most vendors are looking that way too. Like that's what's going to kind of connect us all together and all the security stuff. It's an open source problem. Like we're not going to get away from not using open source code. So I think the solutions need to be rooted there too. So in some ways security is one of those fields where standardization is coming a little late too. You know a lot of computing we've had that wave already so you're seeing that as a powerful force. Security and JavaScript are the two lagging communities basically that's what we're hearing. We have assembly we'll solve everything Randall. That's a question. Let me take the mic. Can I borrow your microphone too? We've got time for one question I think. This is a quick follow up to Lowry's point regarding enforcing standards and between security and the developer. Like is there an example like how would you enforce that through some kind of technical products or some kind of process to ensure that standards is being applied uniformly across the enterprise for example? Yeah I mean going back to the OPPA example for example OPPA is like a CNC project and so it's very relevant here. But I think that you know as a concept OPPA the open policy language is pretty simple you know let's just define a domain specific language to define policies. But it had and it's having a profound impact on the community because for the first time this is sort of a lingua franca that can be used interchangeably by different teams inside the single organization but also across organizations to define anything that is a policy and that includes security but it goes actually beyond security. So there are other examples but I think that there's a huge difference between approaching things like that and throwing the data in the custom format of a sim vendor you know. Then of course the data is locked in there and you cannot really do a lot out of it even if you have APIs and so on. So something that is driven by the community agreed upon by different groups of people and then used as a standard to do multiple things then just enables you know this kind of cooperation and collaboration. I mean I would echo that and I think you know one of the interesting things I've seen from where I'm sitting at Google is there are really three flavors of supply chain security at Google is the same set of problems across three what I've been calling delivery domains and delivery then domain number one is open source. How do we make open source more secure by default? How do we look at supply chain concerns and open source? Flavor number two at Google is Google's first party supply chain our internal build system, source control policies, binary provenance inventory and so on. How do we think about Google's first party supply chain? And then the third flavor is products that Google is building to help its customers with their supply chains and so products shipping through GCP. And looking at these three different domains what's really interesting is that the problems are the same the supply chain security primitives and problems are essentially similar but what's very different is the economics in each space and the set of incentives and the actors and the way that value flows in these spaces. And that means that the way that we need to solve these problems is characteristically different across these three different domains. Things which are going to work for Google in terms of its first party policy. Things like executive mandates exist barely at Google but they do. Where you have top down control and say we're going to do things this way that's not an approach you can use in open source and so different techniques are needed to solve these same set of problems in these different domains but what's common is open standards, open frameworks, open tools and a common vocabulary which can be shared. And so I just echo Laurie's point that actually there's a lot of power because this standardisation can cross these domains which are characteristically different in rather interesting ways. Thank you. So it's great to end on this note of how important basically the topic of the conference is here today. I asked the panel to quickly finish off. I'm going to ask them to tell us what the most overhyped technology acronym thing in their field is and what they think is receiving too less of attention. So deliver just again on the topic of the panel what to look at, what to be a little suspect of. Kim, are you ready to go? Oh man, this is going to be quite a hot take because I live and breathe this but I honestly think software supply chain security, that word is so overhyped right now and it's really hard to weed through the noise and understand what's going on. I think to round all this out together I think the people that are claiming to do stuff in the space and everyone, a lot of it is again rooted back to open source so I would make sure that whoever it is is investing in open sources as they should because this is an open source problem above anything else and kind of understand what's actually happening under the covers there but it could be because I've been living and breathing the term for several years now that it's life everywhere. It's insane. Awesome, thank you. Larvis. I operate quite a bit especially in the open source community in the area of runtime security and my controversial take on something that is overhyped is EBPF. I think that I mean, I find it personally controversial because I personally have invested a lot of time on this technology and my company as well but it feels like now everybody is just jumping on the acronym Ben Wagon without even fully understanding what EBPF is, you know. How many people have heard EBPF? How many people think they understand exactly what EBPF does? See, improve your point.  So, and that is detrimental to the whole community because then it feels like a vendor that uses EBPF they just have a great solution, you know. While in practice it's a platform, you know. It's sort of a mini computing platform in the kernel of the operating system and you can use it to do magnificence and stuff and stuff that is completely useless. So that's my one. Thanks Larvis, Randall. So everyone's just saying their own company is overhyped personally, which I find really interesting. Yeah, like everyone's just calling themselves. I was going to say CVEs but I didn't want us to get in a fight. No, it's totally like, you know, whatever. So I was going to, I actually crowdsourced mine. I asked a bunch of colleagues and friends like what they thought about this question because I thought it was really interesting and the one that I resonated with the most is a very particular type of supply chain attack, just typosquadded packages because typosquadding is something you see a lot in like tech press, like in security news, like someone created a version of a popular library with one letter difference and there's a lot of PR that goes into that. However, in reality, those things rarely get used by developers, like single digit numbers across the board and the things that are underhyped are that there's a ton of open source projects that have a lot of utilization and usage, that have a ton of known CVEs in them and like known problems that are just like not remediated yet. And so I think that's a really big opportunity for like literally all of us in this room, maybe after we all just like whip out our laptops and just go fix, send one pull request to fix one of those and that would make a bigger impact than like all the typosquadded stuff since the beginning of time times like 1,000, you know? Awesome, thank you. So as someone who spends a lot of time at the moment thinking about S-bombs, I think S-bombs are overhyped. I must say that's not because I don't love S-bombs, I do love S-bombs, I think they're awesome but at the same time I think they're overhyped. I think what's, there's a misunderstanding.  And they're truly not. But I think that, you know, if you are required to live the S-bomb lifestyle, you will be forced to adopt a whole number of different practices which themselves will increase and better your security posture. And if you look at the executive order, the policy goal of the executive order is not a sea of S-bombs, it's not even S-bombs. The policy goal of the executive order is better security. And they're pushing S-bombs because it's a vehicle to begin this journey with. And so I think looking at them in that way, I think there's a ton of value there that is super important. I'm really excited the industry is working on it. At the same time, if there's an expectation that gosh, if we just do S-bombs we'll all be okay, absolutely not. Awesome. Well, thank you so much, panel, for being here, you're a noble bunch and thank you for your insights. And thank you very much for attending and your participation. Thank you.


Neolithic man is often talked of as if he were a very different being to that of the modern man. Throughout the modern era, a well-funded, close-knit, often aristocratic academia has portrayed Neolithic man as an illiterate figure, often leopard print toga-wearing, club-wielding, bearded nincompoop, a grubby, forceful, filthy beast who had barely managed to master the art of creating fire, let alone complex language or societal behaviors. This paradigm of us emerging for the first time from the last Ice Age, developing into the complex advanced civilization we find ourselves in, means that Origins of Man is somewhat of a closed book, for to preserve this influential dominance within modern society, anything which contradicts this long-attested claim is simply thrown out, discarded as an anomaly, and any who pursue such avenues of inquiry a mere conspiracy theorist, this regardless of the evidence we so eagerly put forth in our defense. Countless still existing astonishing anomalies, unexplained, simply baffling feats of ancient engineering, so often covered here on our channel, either merely ignored or claimed as absent in explanation as to how the work of our well-studied more recent ancestors, people who were simply incapable of completing such mammoth tasks. Many of these ancient ruins, claimed as more recent achievements, we feel, possess sufficient evidence to support far greater ages littering many said sites, clearly built using far more advanced precision technologies, and neolithic sites are of no exception. We believe here on the channel that the size of many of these highly eroded prehistoric stone trilithons, and indeed stones contained within many enormous dolmens, are also left by this ancient group, dolmens made using similar, if not identical techniques throughout the world, from Scotland to Ireland to Japan, all of similar design and possessing inexplicable features, board entrances, multi-ton megaliths. It is as if this group still possessed the knowledge of how to lift and work such don'ts, but had lost the technologies used to carve with precision. It is as if they were a surviving remnant of a once more capable or more precisely better equipped civilization. How did this ancient people, academically claimed as never having had any contact, build such similar structures? Or perhaps, more importantly, in the feature which initially attracted us to neolithic ruins, the size of their stonework, megaliths often incorporated into their structures, forming trilithons or entrance tunnels with top slabs upon dolmens, sometimes up to 8 feet aloft weighing well over 100 tons? There are discoveries at New Grange in Danor in Meath, Ireland with a slab tunnel entrance, like so many neolithic granges and barrows, regardless of their immense size, once precisely aligned them with solstices, yet they remain mostly buried and thus most conveniently concealed. Some argue that the most impressive neolithic dwellings can be found dotting the Japanese landscape. However, we feel the most archaeological interesting of neolithic sites dot the United Kingdom, France, and some areas of the US, yet particularly Scotland and Ireland. Sites which have fragments of ancient symbols left within, celestial alignments, and a similar pattern decoration or possibly coded message which crop up over and over, especially one found all over the world of a strange enigmatic spiral. And although usually found sparsely decorating neolithic sites, barrows, and internal earthworks, its reoccurrence so regularly must indicate it as once having been significant and important to them in some way. Yet for some reason, gavernous is undoubtedly the most spectacular of them all.  Located in France, to have so many of these patterns clearly arranged in careful and concise manners by a people capable of aligning 100-plus tonne rocks with pinpoint accuracy, we feel should be perceived as a very deliberate and important undertaking, perhaps in an attempt to convey a message to a future people. A people far removed from themselves in terms of language. A fact they may have fully understood, having, as we believe, experience global cataclysm within living memory, so encoded messages yet to be deciphered or even recognized as such hidden within symbolism rather than writings. Are gavernous's spirals mere decoration? If so, why go to such great efforts? Are these spirals an ancient code? Possibly a warning, a message yet to be unraveled. Whoever created gavernous and for whatever purpose remains a mystery yet to be solved. Gavernous is a place very much still unexplained, yet very rarely shared academically. As such, it is a place we find highly compelling.