Rise8’s Post

Transcript

So good afternoon everyone. I am Adrian Salgado, I am a solution architect with Red Hat and I will be your lunchtime retainment, right. So for a little bit while y'all are munching away. Hey, thank you, thank you. Well, you are much in the way. I mean, this is supposed to be a lunch and learn, right? So instead of me sticking with, you know, the higher end topics that you guys have been hearing today, instead I'm going to go down a little deep technical, not too technical. I'm gonna keep it very just over the top. But you know, just go over some of those concepts that you guys keep on hearing about in case some of you all might not have actually know what it looks like or what it's supposed to actually be. So we'll go over some of that. So essentially I'm going to cover dev set cops with secure supply chain on Openshift right now. This is not necessarily an open shift presentation. This is really more dev SEC OPS with secure software supply chain, which if I would speak about, it's actually pretty important, especially with the way we do Business Today. So today I'm going to cover Executive Order 14028 and and a company memos that it comes with gonna go over what is a standard Dev Secops pipeline. And then what is the dev Secops desktops with secure software supply chain. And then I'm going to go over a little demo. The demo was supposed to be live, but we had some issues. So we do have to have a video of the actual pipeline itself and I'll go over that as we go through it. Alright, so Executive Order 14028, right? That's, if you're not aware that it's this, it's a big deal, right? When that came out, that's really what added the fire to the fuel for actual software factories, right? Do you guys hear a lot about Kobayashi Maru? You guys know about platform one? All these software factors that are coming out, A lot of them came out just specifically because of this or really they were already in place and they really picked up after this came out. So as you can see, right, the charges, multiple agencies and clearly including NIST. With enhancing cybersecurity. Develop guidelines which ultimately aimed at U.S. Federal agencies, but which are available for industry and others to use. So it does layout to where you have these these software factories that actually are open for everybody. They're not locked into whatever service is using them, and they're widely available. And then doing business with U.S. Federal agencies will require SDF compliance and that's we're going to be talking about here today. Now there is a company memos, right? This is where it talks about emphasizes the need for software building materials or an S bomb. And we're gonna go over that as we go through the presentation. And it underscores the significant of continuous monitoring and iterating. So you guys heard a lot about the CTO going on, right? It's been spoken about here throughout the day, this place into that and we'll talk about that as we go through. And then agencies must only use software that is provided by software producers who can attest to complying with government specified minimum secure software development practices. So again, this is very important because we all do business with the DoD and doing that, we need to be aware of this and be able to support this in its entirety. Alright, So what is the big deal with secure software supply chain? Well, it's it's a really big deal actually, as you guys just looking at the slide really quick, right. There's just one of the many cases that have happened here recently where there were attacks in the DoD networks, you know DoD infrastructure from packages that were included with software that they consider to be safe and easy to use. So once that came about, that's where this specific 14028. Guidelines for S bombs, for secure supply chain, all that stuff. All that stuff came about specifically because of these kind of attacks. Now speaking about S bombs, right, do you gonna hear that a lot? So what is an S bomb? It's a software building materials, you know, quite simply it is the list of ingredients of a software product. So essentially. And the DoD, whatever software factory you're using, when you're bringing in an external product in, you have to make sure that everything that's actually in it is supposed to be in there, right? So for example, with Red Hat, if you consume a Red Hat product, whether that would be a, a Ubi image or whatever the case may be, right? We sign it and provide the ESPAM with it. And then that way you take that in and you're able to verify that what's supposed to be in there is actually in there. And nobody modified that somewhere right in between the chain between Red Hat and the DoD. So same thing, this, that's where spawns become really important and that is now a necessity. It used to be kind of an astronaut. It'd be great if you had it. If you don't, OK, it wasn't really part of dev SEC OPS in general, but it is now. And that's all because of this executive order that's come out. And this is what an spam looks like. As you can see, most of it is human readable, but it's a lot of information. And that's just a quick little snippet that's simple app that I run for the demo. It's over 3000 lines for the S bomb. So it's a lot of information. And you need to be able to not only read that information, but recognize what's supposed to be there and what's not. And so that goes a little further down the rabbit hole then I will cover today. But that's a whole other conversation for that. But at a minimum, you need to have an S bomb, and you need to know what you're looking at and how to scan in how to review it. Alright, so along with S bombs, you have attestations, right? An authenticated statement? Metadata about a software artifact collection. Software artifacts, So. And at the station is another document that tells you that, yes, this is one that you received with the signature that you have is good to go because I have all the metadata for it that matches, right? It's not a reviewable document. It's not something that you can just pull up a file and be able to look at it. It's something that's ingested by whatever system is actually reviewing your signatures for your S bombs and your images and things of that sort. But this is now also a requirement. So not only do you need dev Secops pipeline, but you also need S bombs and you also need an attestation. And then now, simply, right, what is dev SEC OPS? This is a standard dev Secops pipeline. Alright, you guys have seen this many, many times before. This in particular, I mean, this is what I kind of run on my environment. And so it's very simple without getting too deep into the details, right? You got your code that comes in, that's a quick unit test. You got code quality from Sonar Cube. So that's kind of the static code analysis to make sure that whatever code is in there, there's no mistakes that are gonna mess anything up. You got your artifact repository. With Nexus and then you got your security suite, right, where you do your image scans, your image checks and your deployment checks, right? That's where you check for CVE's and anything like that. Then after that you do your deployment, that's part of your CI CD and then your pen testing and then your performance test, right? This is the standard it basic dev Secops pipeline as we know it today, right? Nothing major changing up here recently, right? It's been like that for a little bit. But now it is changing. Now this, this slide is a little little crazy, right? But it's really not. It's really the exact same thing, but we've added now the particulars for the secure software supply chain, right? And So what you're seeing now is so you got the, you get your developer that you know, makes a change in the code, comes in, does its code test again, same thing, the static code analysis and that sort of thing, right? Your release image build. And then after that, that's where you start seeing the differences. That's where you start seeing the signature, the store and the signing of the image. Right. And you'll see that it does ACS, Advanced Social Security, whatever security suite you're running, it's going to do your vulnerability scans and it's also gonna do a signing of it. So it signs the image right there, then after that creates and assesses the deployment. So again, another scan, but then also sign the deployment after that, right? So again, not only do you sign the image, but you also signed the deployment. The part that you don't see in there is the creation of the S bomb. But I will show that as we go through the demo. So it'll go through, it'll just internal test and then it actually does goes out there and promotes to prod. So again, it's the same pipeline, right? But now you're adding, you're adding signatures, you're adding attestations. So now your image and your deployment. Are both signed and you got an S bomb that is also signed and you got your final attestation that says that all those signatures and all the things that you actually brought in and ran through that pipeline are actually good. Another part that you don't see in there is so down at the bottom left, you see the attest pipeline task. That's another part of all this, right So yes, you sign your image yes, you signed a deployment yes, you got an S bomb right that's also signed and you got your attestation great. Well, how do I know that whatever did all that actually did it the right way? Well, now you also have to attest for your pipeline. So the but pipeline attestation essentially is a BLOB, right that has the information of what the pipeline is and. What it did, how did it check for those states? How did it sign? How did it store their signatures? So it does everything. So not only do you have that information particulars to that particular app and it's built, but also the pipeline that you used in order to run all those tests and be able to actually put that out. So it's essentially who watches the Watchmen, right? So you got to make sure that not only is your stuff safe, but is the stuff that's watching it safe, so.