 So, I'm happy to introduce one of my good friends, Russ, COO and co-founder of RapidCorp. And we also have, you know, Sam here joining from the amazing Defense Unicorn team. And this crew today, they're gonna talk about, really, it's kind of a journey. How has hardening at scale gone inside of the DOD? So, over to you too. Thank you, Carl. All righty, why don't we kick things off? So, this is a somewhat of a practical discussion. And what we're gonna be talking about is what it's like for a commercial vendor like RapidFort to interact with a software factory. And hopefully we can share some encouragement. It was certainly a wonderful experience for us. And some lessons learned and then give you some direction. And at the end, I'm gonna be handing out leaflets and trying to recruit more folks to join us on this journey. So, we're gonna go through a bit about the software, what the DOD software factory ecosystem is. We have some experts in house. And then just talk basically about the project that me on behalf of RapidFort and Sam on behalf of the space camp went through in terms of taking a commercial application and deploying it into a DOD environment. Awesome, so a little bit about myself. My name's Sam Cremier. I'm currently with Defense Unicorns right now, but like Russ mentioned, I was active duty. Kicked off my time in 2018 in the Air Force. And then when this new interesting thing stood up called the Space Force started to happen, I was like, oh, well that sounds really interesting. So, threw my hat in there and then joined that service in an acquisition type role. Found myself at an organization called Space Camp. Actually, my first day there, I was talking to like a one star general and he was like, well, what do you do here, Lieutenant? I was like, well, I work for an organization called Space Camp. And they're like, okay, that's really cool. What are the age ranges of the kiddos? And like, how many people do you live? I was like, no, no, not that Space Camp. So, see, I was previously an officer in the Space Force and was with Space Camp. I'll give a little overview of what that software factory did. But had a lot of fun there, learned a lot about what it means to deliver value to the DoDN user specifically in the Space Force. And then recently exited out of the military and joined an organization called Defense Unicorns, which I'll talk about in a little bit as well. But I have the privilege of sharing this talk with Russ and thank you for allowing me to do so. I love how you still have the calendar invite from a couple years ago. But yeah, it was a technical point of contact for this cyber contract. If folks aren't familiar with that, that's small business innovative research. It's really a great way for small businesses to get their innovative technology into the DoD or to the federal market. So it's a federally funded program. It's really just a grant for individuals to fund their product and kind of do discovery and different types of efforts there. And of course, here's Sam's signature on the original contract. I don't think you could see some of that stuff. For posterity's sake. I can blur that out. So we are beneficiaries of a lot of the cyber efforts and we work with a number of organizations across the federal and defense space. But as I mentioned to you, we're a classic Silicon Valley cyber security startup and our foray into the defense space is a new journey for us. There's nobody in our company who understands this market. I'm actually supposed to. And so it was really quite a wonderful experience to connect with the folks at Space Camp and Defense Unicorns who were able to guard us through this journey. And so what we do is we essentially in the container hardening business, but we have a number of open source initiatives that I'll talk to you about in the course of this presentation. But the key thing to understand is working with the DOD can be extremely beneficial, but there are some fundamental differences. I mean, we've heard this morning that an org chart would be a superpower. For the rest of us, we've got LinkedIn. We can understand who we can speak to, their roles, their authority and all of that stuff. When you start working with the DOD in particular, it's unclear who's doing what and the websites certainly don't enlighten you at all. So it was really quite fun to partner with Sam and his team. Yeah, so I think a lot of people have probably heard the term software factory and if you ask one single person what that was, they could probably give you a different answer. I don't even know what a software factory means anymore, but we see a plethora of them kind of standing up and continuing to do so. And you can see somewhat of a map right here of some of the ones, but where it kind of started and really had some traction was over five years ago with one of the more famous ones called Kessel Run. You saw a lot of individuals wanting to find a way to take all these common and best practices, we'll call it, in the commercial software realm and figure out how to do that with the DOD because if you're familiar with how the DOD would try to deliver software, if you're familiar with the term waterfall, you have these big R requirements that you try to map out on the front end and try to build up that software capability and then deliver it years down the road. So by that time, maybe the mission has changed, the software sucks, they can't even use it. And we find that those that were developing the software may not even had a conversation with the person that's going to be using that software. So how do we actually find ways in different principles, specifically these DevSecOps principles, and put that in the federal government, specifically the Department of Defense? So we saw a lot of success at a Kessel Run, and then some folks kind of started to stand up other innovative groups. And the one that I came from, Space Camp, is one that was particularly in Colorado Springs, working with some space organizations before the Space Force stood up. And then so what we wanted to, or those individuals wanted to get at, was how do we deploy secure and reliable software to the end user rapidly and not have to wait half a year to a year to just release a bug fix or something like that, or maybe even longer. And so with this image right here, you saw back in the World War II days out in San Francisco, the time it took to build a ship was 58 days. And then after that, they built a new ship every 2.3 days. So imagine doing that in a weekend even release, a bug fix in like a year. So something is definitely broken. And so a lot of the folks that started Platform One and wanted to go and figure out how to change that. And then so a lot of the different value streams that Platform One has, if folks are familiar, one of those was this service called Big Bang. And so what we wanted to do at Space Camp is take that and stand up our own instance of that because what we found, and I think some folks in here would agree, and someone at Platform One had told me that, Platform One isn't really necessarily in the business of managing this entire tenant environment for everybody in the DoD. What they wanted to encourage folks, specifically software factories to do was maybe stand up your own instance of Big Bang, this capability leveraging open source tools and really develop your own DevSecOps platform that was DoD, CIO, DevSecOps reference design, accredited and compliant. So that was the big push in Space Camp. And I know they're still kind of going through those pains right now. A colleague of mine kind of talks about the AOs and the DoD is they're kind of like mayors of their own wild, wild West town that don't ever talk to each other. So there's a whole another problem that you kind of have to tackle when doing this type of stuff, but definitely think it's a step in the right direction. So what is Defense Unicorns? So it is a secure software delivery organization and we're open source, we will always be open source. One of our main projects that we're working on is called ZARF, what that really is, is a way to package up whatever capability or artifact that you have that you want to deliver to whatever end user, we can do that in a declarative and immutable fashion. The big goal of Defense Unicorns is to deploy any software anywhere. And so it seems like it may be a loaded term and there's a lot of different things that go into that, but that's what we're striving after. And so I mentioned one of our main open source tools is ZARF, we have two other ones that we're working on, just announced one within the company a couple hours ago. So a lot of exciting stuff going on on that front. And then, yeah, we're working with the federal market because there's a lot of highly regulated, disconnected environments there and quite frankly, we're just passionate about that mission. Defense Unicorns has a lot of veterans and people that are really passionate about national security and progressing the world forward in that manner. So everybody at Defense Unicorns is passionate about delivering value to that specific end user. So Space Camp, so one of the co-founders of Defense Unicorns was a co-founder of Platform One and a co-founder of Space Camp. And so a quick little history lesson Space Camp set up, I think, back in November of 2019. So it was still kind of formulating. Took a lot of the talent there, developing the platform, a lot of goodness from the CIO's or CSO's office, saw that, hey, this is kind of what we wanna do and scale to the rest of the DOD. Took those folks and partnered with some folks down in San Antonio to develop this thing called Platform One. And I think a lot of people know about that, so we'll go too deep into that. So in that moment, Space Camp was like, okay, well crap, what do we do now? And so this was around the time that the Space Force was standing up. And so it was one of those services like, oh, we're gonna be digital and we're gonna be transformative. But what does that really look like? And I think it starts with software. So at Space Camp, we wanted to find ways to really partner with the end user being the space operators, those that are on console, doing the specific mission like, hey, really understanding their problems and pain points, developing, delivering software the right way. So had a lot of different missions and roles. Space Camp continues to do a lot of great work out there. I think there's a lot of different software factories. There's software factories that have a ton of money that don't deliver a lot of value. And there's software factories that don't have a lot of money and deliver a lot of value. So that is a brief overview of Space Camp. Okay, great. So with the scene set, we partnered with Space Camp to solve a couple of fundamental challenges. Now, Space Camp and the software factories are in theory building these digital ships as it were. And one of the key aspects is to make them more secure so that this pipeline of continuous software delivery can be more readily secured. And so when we engaged with Space Camp, we had four primary objectives. The first was to essentially deploy our solution into gravity, gravity stroke Big Bang. Big Bang is actually a complicated tool suite. It's got Kubernetes, it's got Istio, it's got logging and so forth. And just essentially getting it running in the early days was non-trivial. Then we would take this application through the Iron Bank onboarding process. It's actually changed quite dramatically in the past 18 months. But when we first started, it was a slightly different journey. And so some of the things that we experienced have been approved upon and so forth. And then to take this application hard in some containers and get some results. But we had been working with other organizations in the DoD and we were starting to see success in the sense that the sizes of the containers were shrinking down dramatically. The number of packages was shrinking down quite dramatically in the number of vulnerabilities, which is essentially what most people care about was shrinking down as well. So this is an application that had five containers and so if you can think about it, each container had on average 100 vulnerabilities and we were shrinking those down quite significantly. So the name of the game with this particular project was to reduce software supply chain risk. In fact, the engagement came about because we were approached to reduce software supply chain risk. So what is software supply chain risk? Well, there's a number of definitions, but we call it the systemic risk that arises from using software or applications that you don't own, that are not developed internally, which in the modern era means practically all of your software except the nine or 10% lines of code. And so where does software supply chain risk fundamentally come from? At its core, what is the cause of it? And I would argue the cause is complexity. And so if you imagine your application as being a corridor with a series of doors and the bad guys are gonna come and rattle the handles, shoulder the door and they're gonna go down the corridor. And if you've left a door, a jar, if they can sort of shoulder it open, they can essentially breach the perimeter for want of a better word. And so just basic probability mathematics suggests that when you start chaining things together, the risk increases. So if each of the doors was 98% safe for that year, but you had 20 doors, when you chain them all together, there's a 33% chance of you getting in, of you being breached, which is a really, really scary statistic. The second thing is you're only as strong as the weakest link. So if someone's left open a door, it doesn't matter whether you've got 100 doors that are secure, you can just walk through the one that's open. And one thinks of Uber, for example, had a very reliable security program and essentially had some human engineering breach. And then suddenly all of that effort is essentially lost. So only being as strong as your weakest link and you having 10,000 links is a scary proposition. And that's a real challenge. And of course, we all know that software attack surfaces are growing and all of this stuff. And so the challenge with space camp is, what can we do with these doors? Because we actually don't own the doors. A lot of the infrastructure that they're building is on open source. We're aligned on vendors for patching and things like that. And so one of the philosophies of rapid forward is, what happens if we remove the doors altogether? And that's essentially what we decided to do. And so the life of a modern CISO is a very difficult situation. They don't own any of the assets. They don't have, often at times, influence over the people that do own the assets. The people that own the assets is not even their assets. It's sitting on a cloud that they don't own. It's software that they didn't write. And all of this stuff. And so it's a very difficult, problematic sort of systematic challenge. And one of the ways we think we can start to see success is to simplify the problem. And so we essentially took our application and we went down the journey of onboarding to Iron Bank. And it involved finding a DOD sponsor, which was SAM. We set up our application in gravity. We opened an account at Platform Run. At that time, they didn't have documentation that was readily available. It was firewalled behind a DOD firewall, so we couldn't get it. And they fixed that. Now there's some really excellent documentation and so forth. We had to then rebase all our images onto UB8, which is non-trivial if you've ever done it for a 12-container system. We had to add a licensing component because Iron Bank is completely open to the public. And so our containers were now sitting out in the wild. Anyone could pull them down. And so we had to license them. We had to obfuscate the code and we had to really harden them, which is a very hard bar. If you think about a financial services company, they don't have their containers sort of publicly available. If you speak to Goldman, they won't even tell you the name of their container, let alone what it does. Let alone have it available in the wild. We also used Iron Bank base images. Iron Bank curated a large collection of images. And so we used the Iron Bank key clothes, the Iron Bank Marsiqua and all of these things. And then once we got it all together and running, we kept that in a steady state for the majority of the project. Once you sort of get into the Iron Bank, you have to remain compliant and they broadly follow. In fact, there's some folks from Iron Bank or Platform One here. They broadly follow the OSSF model where you remove DevTools, unused software. There's a scoring component and all of those things. And you put it into a vulnerability assessment tool and you interact with the curators there to essentially make sure your container is approved. And then once you're finished with that, you're then entitled to market this to the software factory community. So for us, it was a really solid experience. And in speaking with people today, I don't think the DoD themselves actually realize that they are pretty advanced. So we actually interact with a lot of Fortune 100 companies and there's the Googles of the world and so forth, but there's the John Deers and there's all of the others. And when you compare them from an innovation perspective, I really feel that not enough credit is given to the DoD. Innovation is hard. And we interact with lots of innovation offices. Our office is in an innovation office for the Fortune 100. And when we interact with those innovation offices, it's the same cultural challenges. We can't get projects moving and all of this stuff. So being on both sides, having scanned infrastructure and enterprise and in the DoD, I can tell you that you are gonna learn a lot about DevSecOps. We did, we've got great engineers. You're gonna be exposed to some leading edge thinking, leading edge philosophies and things of that in those dimensions. Platform one has a really pure ethos, they're open source. Everything is open source and you can start contributing to that and you really will meet some fascinating individuals. So I can't speak highly enough about it. I'd love for you to chat to me a little bit about our journey. But here's what we learned. And reading this, it's embarrassing, but you should read all the documentation before you begin. And the reason for that is the DoD is not flexible in the sense that once you have a work order, it's very difficult to change. And so getting direction and getting clarity and getting all the stakeholders on one page is excellent. It's fundamental. Of course, we didn't do that. We charged ahead and we learned from it. Let's just say that. There are actually excellent reference materials if you dig around and actually look for them and find them and read them. This is kind of something that's very helpful. I've actually got a reading list for anyone who wants to chat to me about these are the things that you should be reading. This is an excellent sort of place to go just to understand the philosophy of what you're trying to do. It's crucial for you to have a strong deal champion. You need a strong deal champion in enterprise, but you really need a strong deal champion in the DoD because in enterprise, there's other people you can go to. So if this guy stops speaking to me, I can go to his boss, I can go to his colleague, I can go in the DoD, they don't answer the phone. So you have to really develop these relationships and you've got to nurture these relationships because that is essentially the owner of the project. And so forth. So we got our system running in Gravity and Big Bang and I think what happens with Iron Bank is the Iron Bank process is there's a desire for vendors to charge ahead. Really what you should do is be getting technical stability, make sure your application is running extremely well and do a lot of the front loading work up front so that by the time you take it into the Iron Bank, you're reasonably mature and you're not going to be essentially a distraction. They are resource constrained. If they don't necessarily feel that you're doing, you know, meeting in the halfway, then you get bumped down the priority. They're very busy. And so definitely go into the engagement with some degree of technical maturity and things of that nature. And then once it's working, don't change it because it's a finicky piece of software. Anyway, definitely take advantage of the AMAs that are available there. One of the challenges we had is there was no synchronous communication between us. We didn't get CAC cards and so it was very difficult for us to interact. There's a matter most slack that's very responsive and what have you in it would have been my absolute delight to be able to have real time support but as an external company, we didn't have that but I think that is one of the things that has been resolved and it's going to pay dividends. And then shameless plug, we wouldn't have got through the process had we not actually reduced the size of our containers by 80% in the first place. So good news is if any of you want to go into the Iron Bank, we will provide a free service. We will shrink down your containers and there will be the delight of the Iron Bank team when they get there because they'll be 80% smaller and hopefully a lot more secure. Okay, so the question now becomes how do we get rid of these doors? Supposedly that's a metaphor we believe in. Well, interestingly enough, you don't need a lot of these doors. Depending on who you believe, 50 to 90% of software running in production is actually not needed to support that specific use case. And we've scanned a lot of containers and we've hardened a lot of containers and language dependent depending on the programming languages node, it's always more than 90%. If it's Java, it's 60 to 70, a lot of the sort of languages like PHP and Python and so forth, it's always 80. There's just a lot of software that you don't need to actually for your application to function but it's pulled in as a function of the build process and we've been talking about zero trust. I think the thing you should least trust is your package manager because that brings in a lot of the bad juju. Anyway, so what we do and did in this process and we built out some pipelines with the Space Camp team is after you've written your custom code, you've got a little container, we instrument the container, you exercise it and then based on your behavior, we intercept memory accesses and things of that nature and there's an APR that you essentially send some arguments to and we return in theory a smaller hardened container that flows into your development pipeline. There's a little more to it than that and I can get into the technical details with you offline but that's essentially what we do, we instrument containers as they are exercised, we understand fundamentally what they're doing and then we go from there. We did use this application to do a very small pilot program which was, you know, it was successful where we took a lot of the common Iron Bank containers and we actually hardened them with our Iron Bank tool that we developed with Sam and his team and it's successful. On average, we were removing between 60 to 70% of the unused code and it's available today. We'd encourage you to pull down these containers, run them, use them and all of those things. So this would be successful in the sense that we've had this project running for about five or six months, the containers are working, we've had less than 100 tickets and so things are running sort of end to end. All right, I can give you a quick demo if you so want. Yep, I think this could be a repeat because I wanted to make that point. All right, here you go. So the summary before we go to the demo is essentially this is an example of what industry and defence collaboration looks like. It comes down to personalities and people, it comes down to simple things like making sure you've read the documentation and things like that. But the key thing to understand is that a vendor's responsibility is to understand that the DOD is not going to change for them. Everyone's saying, okay, we need to do this, we need to do that, the reality is it's a big machine and a small company like us needs to adapt and actually needs to not swim against the stream so aggressively and so forth. And finally, it always takes a lot longer in industry to complete projects and it takes a lot longer in the defence space. So create both a time, scheduling and financial cushion. So should we open the floor to questions and I'll do a quick demo? Thanks, sir. Yes, sir. Because it's harder, it takes longer. Did you need a silver contract in place to make that business case or would you have been able to, like how do you enter that conversation? So to be perfectly transparent, this is an ongoing discussion in the company today. Whether the DOD is viable for us and whether it's a good use of our good engineers and I actually have to compete for talent to partner with the DOD. So the reality on the ground is that for venture-backed companies like us, DOD contracts don't amount to wins on the VC scoreboard. They are interested in enterprise deals. They want you to be sort of pushing through and creating classic GTM motions and things like that. And so when we talk about our DOD relationships and things like that, they're all very deeply discounted. So I'll give you some hard numbers around that, being perfectly transparent. When we speak to venture investors, we're always talking about multiples. So what is the multiple AR you're gonna give us on our business? And they'll give us between 20 and 40 on our enterprise and three on DOD revenue. And I have to say to them, well, listen, the DOD is a legit customer. They're not going anywhere. And I would argue they've got deeper pockets, a more fertile market, and they're gonna be around a longer. And you're much stickier in the DOD and it's much easier to compete there because of all the contracting friction and all of this. So the short answer is, and I've given you the honest answer, is you are going to have to make some decisions. And one of the keys for us is we looked at what we wanted to build for enterprises and we looked at what we wanted to build for the DOD and then we sort of married up that roadmap. So a big decision for us is that we were a SaaS service, we needed to go and serve financial services. So we needed to go on-prem anyway. And so we could go on-prem through this journey with Space Camp and that was one of the gating things. But for a small company, I wouldn't advise just going out and randomly pursuing the defense market. I think it needs to interact with your enterprise strategy. There's a lot of things around the DOD that we didn't know, we didn't know that there were these things called stop-work orders. So in industry, we, you know, a contract's a contract. Whereas in the defense space, they can just email you and say stop work. And so if you don't know that, it sounds like you've done something wrong, the contract has been canceled. It's major drama. But in the federal space, that's business as usual. And so educating our investors, educating our auditors, educating all of these folks, was and remains a challenge. And the reason we're big believers in this relationship is because it's obvious that the DOD needs to go to cloud. It's obvious that there's a large receptive market. It's obvious that they're gonna have to use these technologies. And we wanna be involved in that journey. I personally, you know, I'm more interested in the DOD space because, you know, I've had some modest entrepreneurial success. It's operating at a scale that excites me personally. You know, I've sold enterprise software and a lot of it. So this is a new frontier for me personally. Is that a nice one? Yeah. Not yet. But we'd like people's help. So it's an open source project. And I'd like some tired lift resources to do that. Our open source project is very open source in the sense that we have a number of contributors, some of them are interns, some of them are sort of seasoned professionals. And they come and they work. They do their thing and then they go away. So we haven't reached the scale at which we'd like to be. But there are some interesting case studies in there. We've got a lot of data. We've got a lot of downloads that academia could be interested in. But if you wanna understand the patterns that we're seeing, are we seeing patterns by programming language in terms of vulnerabilities and reductions? Absolutely. Are we seeing, yeah. There's a lot of interesting things that I can share with you. Are you interested in anything in particular? Yeah, yeah. I've even bought my leaflets with a barcode. You can scan it and you can get going and you can download it and use it. Yes. Hey, I was just curious, how portable are these iron bank containers? Say if you were to use it for open banking or an electric vehicle powering grid or something? So they do have a large catalog, but it's, I'd say they're very portable. So you can go to Docker hub and you can download the latest engine X or you could go to iron bank and download the latest iron bank that's been curated, that's had a team of security professionals pick through it and the cost is essentially the same. So I can't see why anyone isn't using iron bank. Be that as it may. A lot of the common technologies are there. So all the databases are there, all the low balances, the web servers, essentially a pretty rich DevSecOps toolkit. So definitely take a look. I think you'll be impressed with the coverage and you'll like what you see. All right, thank you. You bet. I got one bonus plug for iron bank. I think this is a great example of the DoD really working to give back and the images that are inside of iron bank today are inside of nuclear submarines in nuclear missiles in aircraft. So it's something that I think as a community we can really work together on to improve that ecosystem. So again, we can build better, more secure digital infrastructure together. Yes, very, very definitely. We're all good, we're good here. It's actually, it's on the website. All right, any other questions or demo time? Demo time. All right. It's gonna be a relatively boring demo. But here you go. So let's see if this is the right one. Okay, so what you're looking at, I believe, is the MongoDB iron bank image that we hardened during this project. And you can see that the original container size was 68, 680 megabytes. And once we shrunk it down, it was around that. And so what you'll find with a lot of the databases is that the central functionality is essentially in a couple of basic binaries. So if you preserve those binaries and a few of the dependencies, you get all that functionality. And so the databases are examples of applications that make really good containers to shrink down because the use cases that they need to support are pretty simple. Then we have the vulnerabilities and the packages that we removed. But the, excuse me, the real sort of interesting component is which packages are being used. And so you can see these are all the packages that are actually in the container itself. And when there's a green dot, that actual application was used. And so essentially this long list is, you'll recognize that it is a classic S-bomb. And then we call this list the runtime bill of materials, what you're actually using, the real bill of materials. And then we can essentially direct the hardening. It uses a GitOps kind of construct that allows you to keep different files, different directories and all of those things. And so forth. And so that's essentially the extent of it. Our was gonna show you something really interesting, which is the next version of what we're building. I've just had some networking challenges. Okay. All right. Thank you. Thank you. Thank you.