 Hi, Nisha. Hi, John. Hey, Michael. See, I'd be glad to know it only took me a couple of days to get over the whole time zone situation with alarms and multiple alerts that it is actually now. Hey, Richard. Good morning. As I said the other day, Richard, I was seriously impressed with that T-shirt. I need to find that online. I think it was swag from Reinvent, I think. Like two years ago. So you can reach out. It's one of the big security vendors. I was thinking if I could hunt it down, give me a second. It probably sold still. It's a quality item. What's that? Who knew it could get fashion advice from the middle of a CNCF working group print? It's probably the least expected of all outputs in this group. Did we scare everybody away with the talk about this? I wasn't sure whether it was sort of coming up to Easter and people taking time away or whatever. It's been fairly light on the ground with multiple different meetings and things. I haven't heard from Emily or Anders actually. I think they may be away. Yeah, Emily's on vacation. Yeah. I think she comes back next week. Give it a minute and then kick off. It's Blake. Hey Blake. Blake, I hate all your recommendations, but I accepted them all. They're all great. And it takes something to be a tercer right now. Tercer? Like it was, it was like really like, you should, what about, I don't know, it's fine. I'm not sure I can face going through pages 24 to 40 again today. I got to tell you. I didn't make them all the way through yesterday. You know, it's significantly better. I was talking to Alex. Yeah, I'm still convinced that parts. It's actually that first. The introduction is way more concise. We decided, we decided the structure we even wanted to do. I think it was a problem. We just. We started with that and say, it's automated. And came to it backwards. Yeah. Right. So let me. Is that you anonymous crow? Hmm. Adding, adding in more sentences, Blake. No typing. I'm typing, but I was. I was editing existing sentences. Got it. Got it. All right. So I'm looking back through some of the notes. And I know that. A number of you were good enough to, to also go through. And do a review. There's certainly a group of us got together yesterday. Myself, Alex. Blake and Richard to go through pages 20 to 40. And do some pretty heavy. Commentary and adjustments that document is the same. It's sort of getting in the shape. Alex coming in. Excellent. I think we still. Have some way to go on that piece, but we'll see. In terms of, in terms of going through is in this, providing a single narrative. Can I ask maybe. Rich Marina. I think Alex as well. Was that really your intent as you went through it? Or is it more just editing it from top to bottom perspective? At least for me, I think I, I mostly just went through and read the whole thing top to bottom. I made a couple of like minor, like grammar, like changes in line and then just listed kind of general inconsistencies I saw. But I wouldn't say it's like a full. Like single narrative. Right. Rich. Marina. We just lose Richard. And then we just lost Richard. Okay. So we still need to do the, the single voice narrative. In terms of. Areas of the document, the choppy. I think. Like you, me and Richard are probably. Chewing on 20 to 40 still a little bit. Let's face it. But. What about the rest of the document? I guess from, from your review. Everyone else. Are there comments that we need to add in? I note that from. Pages one to about 20. There are. Hardly any comments in there at the moment. Yeah. I'd say that a couple, I think the biggest. Things we can do to get it kind of in shape is there's a lot of the. Risk assurance levels missing. Closer to the end of the document. Yeah. And then in the very last section, there are a couple of like section headers that don't have content filled in. I think those would be like the two biggest things to get this whole thing in order. And then there's a lot of little things as well. But yeah. Yeah. I think I added a chunk or at least created the suggested edits for they may have been merged in actually. Or deleted one of the two. Or lost somewhere in between that. But so let's do that. Let's go in high medium risk. We can certainly do that part of it. The other bit that I kind of wanted to highlight was the actual recommendations that we've made. And whether we actually agree to that. I think that's a good group because I think that's pretty fundamental. Right. If we've got someone here we disagree with, or we're missing something, we should probably evidence it fairly promptly. Yeah. So it was actually. Hi, Magnum. Welcome to the group. I think it was. Last week. Oh, the 22nd of March. I sent through a document and all it was supply chain recommendations. Yeah. And all I did was I just pulled out the recommendations, put them in as bullets just so that we could sort of stand back a little bit and figure out, look, all things being equal. These are the actual recommendations we've made. Do we, do we actually agree with this? Or are the chunks were missed? Right. Just wondering if we can spend like five minutes just reviewing that to see if we've actually missed something. We agree on it. And then we can add that into the paper and move on and then look at the high, medium and low recommendations at the bottom. And then figure out any recommendations. Yeah. So if you, if you go back in Slack. To like the. 22nd of March. I'll also see that. He just replied to the thread. Yeah. Yeah. It's not the prettiest of formatting. Yeah. It gets there, right? And this is literally just copied out of the headers. Right. So if we start at the top. That was the top. I don't know. Individual items. Is it possible for you to share the screen? Yeah, I can share the screen too. One thing that sort of here that I was not quite seeing where we have it is do we recommend container scanning specifically? Anywhere. Yeah. Yeah. So. The elicit is tools at the very end. And sort of mentioned indirectly a couple of times throughout the document, different places. You know, distinct from Sastin dust. Yep. I'm trying to figure out if that's a set. It overlaps with other things as a problem because it can perform, can perform vulnerability scanning. And can perform configuration scanning. But I was actually wanting to reference it from the bill pipeline steps. So. No, I think you're right. No, there was a Claire anchor or whatever we list. Some tools at the very end of the document and table, but I don't think. I think it deserves a first class possible. Automation is probably where it belongs because that's where we have software scanning. Yeah, you're right. It overlaps with all these. The thing is it's the tool that performs them as a problem, but otherwise. Oh, so I have thoughts on this. Sure. Sure. Yeah. I've noticed that there are some things in the controlled environments section that. Well. Maybe contradict with the container section in the okay. With regards to scanning. That's right at the bottom of the document. That was what I had said I do is put an appendix at the bottom of the document and then list out all the stuff over there. Now. Container scanning. Because of the way containers are built. You know, is, is not something that someone can totally rely on on. So I think. With regards to containers. We could. I would recommend, you know, taking the results with a grain of salt. I would never say it's the only option, but it's what you should do. You should use static source code scanning if you can, but there's nothing to say you can't do the other one. In addition. Yeah. Yeah, what it mostly comes down to is when you're building from binaries, it's the only option you have frequently. Yeah, I agree with that. Yeah. So it's, it's defensive depth. And that's what I was going to try to say actually is. My recommendation might not be container scanning. It's performed configuration scanning and perform. I don't know. I don't know. Not as bomb from source, but as bomb from what's actually installed. So it's not. If you could accomplish the same thing by other tools, it's not strictly container scanning is my recommendation, but it would be. Figure out what you actually have in your containers and figure out if you're containers are configured correctly because that is vulnerability. So yeah, Yeah, the application layer also, right? Like it is, there will be some level of overlapping between the S forms, but it can be a heuristic approach here. Yeah, all these overlaps slightly, and I don't know if that's a problem or not. Yeah. It's like, we're not enforcing, we're not enforcing anyone to use any of the kind of SAST and DAS solutions here, right? No. We're just providing some guidance and, okay, these are the ones that, if you want, these are the ones that are available, right? You can either do DAS, SAST, or you can do both, or you can also do container scanning, right? So I think that's a good approach. What drove me to recommend this is I was gonna get to, I was working in the section of the build pipelines, where we're saying build hardened images for your build pipeline. If you're not building from source, the only tool you have available is, Yeah. and it won't hurt anything to do it in addition to it, to SAST analysis on your standard pipeline. Yeah. So, yeah. And there are a lot of open source tools available for that, so. We have a list at the end of the document already. We have that on the container security map as well, I think, not just for open source, for commercial tools. So what we're doing in the container security map is we're doing CNCF tools, then open source tools, and then commercial tools. So, yeah. So let's add that in. I think that's a good shot. Perform, I mean, in terms of verbiage. Yeah. In addition or when it's the only option. Right. But yeah. Often only option. Yeah, yep, yep, yep, yep. Cool. Other thoughts, anybody else? I have one with that secure authentication, right? There is a usage of PAD for a CI CD pipeline, which is not really weighted against SSH to say that, you know, that should go as a recommendation, right? So if we can't put the pros and cons for both approach, I think in my view, we shouldn't recommend, I mean, just blindly recommend one option, right? So. Yeah. So there is a consensus, yeah, go ahead. I think what we got down to is we didn't care as much if you, this Pat, I mean, that text went back and forth a lot, but it was used to unique credentials for the pipeline. I'm sorry, Vinod, Vinod, can you put your mute? I don't know what ice cream van you're next to or something, but. All right. Yeah, I would be happy to, I think we're saying Pat still, I think perhaps relax it slightly to still say a unique credential for the pipeline, not shared, because that was what Pat implied, but if you do SSH with a unique cred, I think you're just as good. So, yeah, I think that's a decent one. Should we state use unique credential and then as like a subcategory? No, I think we can drop the last one and turn it into that. I think that's, we're having a discussion or arguing about the last one. Sorry, I had to turn off my son's tablet. So you put up just unique credential. I think we should mention short-lived unique credential. Like that is important. Oh. No, it is using a long-lived credentials, shared signals are not good for any automation. Short-lived or even better as a femoral? Femoral, yeah. That's harder, but I'm sorry, I just made this time. Bum, bum, bum, bum, bum, bum, bum. And how do we cut this, right? So use the short. I have to drop for another meeting, I'm very sorry. No problem. So how do we cut this though, right? Use the short-lived credential and then effectively slightly adapt the usage of Pat to highlight that's an approach? Pat, it is complicated, John. Pat is not a standardized increment that's across different vendors. So, yeah. So most of the vendors are doing a long-lived shared secret. It is just like an API key. It's, yeah, so, yeah. All right, I'm just going to say that we need to add that one. Okay, let's sort of move on in a bit. Is that all looking good? Fair fine, third part artifacts and source libraries, dependencies on libraries, makes sense for high security. Makes sense. Vulnerabilities, management, licenses, composition analysis. This one jumped out a little bit. The controlled environments, it was kind of often in their automation piece. Secure materials, when we come back to it. Yeah, maybe scratch it for the time being or let's color code it somehow. This one. Yeah, not enough dirt to warrant. Like, what does that mean, right? And I think there's a whole lot more controls and controlled environments. Right. It just optimize, use a container optimization strategy. This all looks so much more real once it's on a Microsoft Word editor. Just so you know, and what we're doing at the moment is just we pull, so we've done huge amounts of editing. Huge amounts of editing over the paper and such. What we've done here is pulled out the actual recommendations we're making to see if we actually believe the recommendations and see if there's any gaps. Okay, awesome. Yeah, we want to make sure that we actually believe in what we're saying at a high level, right? Oh, I have one a little bit up that I just read. So the building libraries from source section. I feel like that could probably use, like, build them from source or use reproducible libraries. Because I think if they're already reproducible, it's a little bit redundant to have to build them yourself. Basically, like, I think the idea is to have some kind of verification, but I don't think that's the only way to have some kind of verification that the resulting artifact comes from the source code. Yeah. I think especially with the six store and everything, there is a possibility that you don't need to verify everything from the source, right? So is that, I mean, we've got reproducible builds in here as well, but I mean, is that in the similar sort of section suggests that well, behind security environments, you can either build totally from source or rely upon a reproducible build. Yeah, exactly. Like, I think in the real world right now, mostly you'll be building from source, but I think that's another option as these things progress. We can certainly reference it, right? By the way, I'll run in and just add that, just putting people next to these things so we actually have someone to get on with it. Vinod, do you wanna take the ephemeral one? Yeah. From container scanning. Who wants to take the container scanning one? I can do that. Thanks, Magna. And I'll just delete that. Okay. Right, so we had loads of verification as you'd expect on the secure build pipeline. I think we did this one to death. The first recommendation feels very ambiguous to me. I don't know if it's a headline to the rest. Well, any configuration security, we can probably tighten the language, right? Let's see what, I'm gonna look in the update. Where is that? Securing build pipelines. Oops. Like third line item says, cryptographically guaranteed policy adherence. That feels much more concise. Yep, just trying to find the section. Alex, I think you're on mute. Are you talking? Yeah, sorry, sorry. I thought I had unmuted. Looking at it in the dark, it looks that validate the configuration security of the system after deployment. Recommendation looks pretty minimal as well. And I think it probably is mostly covered in the cryptographically guaranteed one. So it might be a candidate for cutting. Yep, I'm fine with that. Any other take is just deleted? There's one more, which is validate environments and dependencies before using, using what? Seems like a truncated sentence. That might have been me. Oh no, that really is the actual sentence. All the environments and dependencies before. Before using verification, before deploying the software. Before using the dependencies. Before usage, I guess. Yeah, usage, yeah. The build environment sources and dependencies come from secure trusts, I think it's a valid recommendation. It's just a really bad statement. Usage. And on the first one, would that, would that be, yeah, the one that you're saying to delete there? Is that something that, for example, I have my binary or my container image and I have that on my artifact repository. And once that's deployed into production, I do some kind of like hash validation. Is that related to this first recommendation? Unfortunately, I've deleted it and now I'm more than happy to put it back. But I think that one was more sort of post instantiation of what you've actually done. Just make sure that it's secure. So we're gonna automate the tests to make sure that you're happy with the security posture of what you just sent. Okay, so it's not, it's not just like a checksum of what's deployed and what was generated by the source code. No, I think it's much broader and it's like admission controls more than that. I mean, I guess the way that I'm thinking or was thinking of that one was like, you've stood up your, it's like the power on self-test, right? It's like, you've stood up your software factory. You've done, or your pipeline, you've done everything you can to make sure that you've secured that thing. But do you wanna run a suite of tests against it to validate that it is still stood up as you expected to be stood up, fire payloads at the thing, try to fire off certain attacks against it to make sure that it is secure as you expected it to be. Not just check to make sure configuration files are set up, but can you connect to it via HTTP? Can you just manually insert some step or something? Yeah, it could even use formal methods to, hey, does this actually have this set of inputs? Or does it have metadata at all? Does that metadata match what you're expecting? So now it's deleted it, maybe I put it back. So that would be more like a brief detection of your infrastructure as code, right? I think it's more than that though. I think it includes that but it's more broad statement is that I wanna make sure that it, I wanna provide efficacy testing. I wanna prove that some of the two, and this point, you know, almost to the formal reasoning perspective, I know what these inputs are, I'm gonna put these inputs in, I'm gonna run this build or scan and I'm expecting it to show this output or I'm gonna flat out try and, try and delete one of the stages, it's supposed to be immutable, so it shouldn't allow me to do that and just validate that I can't do some of that sort of stuff. So part in total is giving you some of those things at every build stage, right? I think this is more like runtime at the station of providence. Well, in my mind, this was more just make sure that it isn't broken, right? It's, you wouldn't run all the time, it's just, you know, it's like, you know, you built the house, you made sure you put the locks on the door and everything, but try the door after you outside, right? Did you? Yeah. Great, it looks like there's a lock on it, but can you open the door, you know? So it seems to me that's more like testing your instant response plan and from just an example there, but it would be more related to something like chaos engineering, right? So break stuff and see how it behaves. It's closer to the chaos engineering, it's closer, just run a suite of tests against the thing to see if it really is secure. Isn't it more like a regression testing, like? Yeah, kind of, but it's security regression testing, it's like, you know, it's like, if you think of an infrastructure, we should probably move on a bit, but think of infrastructure as code, right? You've got an S3 bucket. You know, I've written some terraform to secure the S3 bucket and I can see it says, make sure that it's encrypted and it's only, you can only connect via HTTPS, but as a test, just try and connect it via HTTP. Does it work? That's what you really care about and that would prove the efficacy of the controls we just implemented. Has it just come back to this one? But yeah, it's tracking that in practice there are no deviations from what you think. Yeah. From what you did. I can put it back and put more verbiage into it. I'm also happy to delete in it. Okay, I'm happy to tag team on this one with you. So you can go to the first pass and I come after, we can go to Async or... Yeah, sounds good to me. So, re-add. And then, because there's some cool stuff you can do in there actually. All right, so a test each stage. What's here? How are these two different? We've merged them already actually. They're fine. Yeah, that was right. This was after, right? Cool. You're still in the build pipelines. Can I go? I just noticed this control environments thing. Which one? Above the securing the build pipeline. You're gonna delete that for now. Okay. Yeah, would you want, or do you need to keep it? No, I don't need to keep it. I actually raised a concern about it in the original document. So... Use, I think we fixed it. I think this is kind of objective to build repeatability. I would like to describe the section in detail in appendix one. John, I'm sure you have plenty of perspective on highly regulated environments. I don't know if like controlled environments is too ambiguous, but we would like to call this air-gapped. And then we can talk about, well, reproducible builds are a key there. Also, well, people are not pulling things off the internet. So how do those things make it into the environment? And everything at that point, whatever goes into the repository in the air-gapped environment should be strongly attested. A lot of things can be said about that. There's several different dimensions, but should we spin it that way? I think we should actually, and I prefer the air-gapped. So your suggestion is to change the name of it to air-gapped? Yeah, and we talked about air-gapped recommendations, which there's several, because you now have like intermediate repositories so you need to trust and the artifacts in there. How can you tell they actually come from where they presumably come? And this is kind of an open number that kind of worms here a little bit, but I think it's a valid one. I like changing that to air-gapped. Is there a list of additional recommendations? And I guess my question is, who's in a position right now to add those? Because I think that's really valid, right? Air-gapped environment, how do you actually inject those, that software, other than the artifacts? It feels like at this time you really can't. You have to like lift and shift your whole pipeline and build environments over to the air-gapped environment if you wanna make everything work. Well, that's not, is that how it works? I mean, I'm not that familiar with truly air-gapped environments. I guess that's probably one for Blake, Colin, perhaps yourself, Anders. Sure, I can take initial step at it. I could benefit if there are additional threats to mitigate. So like, what are the vectors for release tampering? Is that like, what's the impact of compromise developer account credentials? Because we can say in air-gapped environments only do things that have been signed and you can validate out-of-hand and follow like, out-of-hand validation of those signatures. It feels like a great topic for a slack thread. Yeah, yeah, yeah. But it also feels like a good rabbit hole, right? Because I think I just, no, I think it's a really good call, right? Do you wanna have a shot at it? And maybe, I think call would be great to a pine on that. I'd like to chip in or probably look at that. But if I put you down for initial pass, Anders, and then I'll follow up with Cole, perhaps, see if he's interested. Yeah, thanks, Nisha, for drawing attention back to this item. I'm glad we were visited here. Yeah, yeah, really good. Yeah, Cole might say just set up a mirror of Docker Hub or Artifactory. He's very pragmatic, which I like. So I'm going to need that. Hey, it's still air-gapped. It's just an air-gapped Docker Hub, yeah. Yeah, or use that Amazon tool that clones connective environment to offline environments. I forget what it's called. Use teleport, too. Teleport. Oh, right, yeah. OK, shifting on a bit. So where were we before? Ness, were we down here, I think? Authentication, roles, short-lived workload certificates, secrets management, women, securing the artifacts themselves. Is this in the wrong place? No, it's not. In securing the actual deployment, we're pretty light on securing deployment. But any thoughts? I think I agree with all of that, to be fair. Can you just scroll up a bit? Sure, sure. Oh, actually scroll down so that the text is up. Yeah, sorry. Oh, that's the end of it. That is it. Yeah, that is the end. Oh, OK, I thought that was a little more. Yeah, since we're giving explicit project recommendations, should we also say use open policy agent, use Aspire? Not sure. That's an interesting one, because I think we've sort of slightly shied away from it. Sorry, Magna. Sorry, yeah, use container signing or artifact signing, yeah. And then we provide over here some tools that do that, but point directly at our tools, as CNCF tools, I'm not sure. They can have other options, right? And sometimes they prefer the enterprise version of that because of support and other things. So yeah. So let's talk categories. You say policy engine for policy. Yeah, exactly. You're an admission controller, right? So something like that. So keep the compliant to station engine that also distributes credentials and can act as a PKI. Yeah, you kind of disappear into madness, right? I know, how did we do this in the container security paper? Because we're in the middle of the CNCF, right? I mean, I think we should state the generic, but also reference the specific, especially within the CNCF. It's like a first or identifier. This is a gap. But I'm interested in how it was been done in the other papers. Does anyone know? I think we can do whatever we think adds the most value to someone writing the paper. And our view of the world is very cloud native, right? Yeah. We got this reality of, or the reality around this is these are the things we see really close to us. Therefore, those are the ones we'd recommend. So I think it's fair game to call out explicit things because people read these things like, oh, conceptually, this all sounds great. But what tools should I be using? Yeah, totally. I think we need to draw the line between referring to a company specifically or a non-open source project, perhaps, but I think that's reasonable. Yeah, we don't want to do what the CNCF decorator did for secrets management and say, go use cert manager or go use a recommendation as to adopt, vault, but to explore a cert manager or AWS KMS. When those things are not even secret stores. Right, that's, yeah. Wow, really, OK. Yeah, I'll share the link, yeah. No, I didn't, wow. I have to go on the TOC call, the last one, to try to get that retracted. Wow, that's not great. OK. So isn't it better to use the generic term and give back samples, right? Yeah. Instead of giving a title, it will look like that secret manager in a mind map. I like people will think that it is just, you know. Yeah, I think that's what we're going to do, right? So, you know, use some form of artifact signing. It's probably not even a tough approach. It's probably notary, right? Or use a schema for metadata. I'm not sure if we want to discuss it just for first. That's a good distinction of the nuance at play, but the update framework is a spec. It's not an implementation. Yeah. So it's good general advice to give, follow the principles or the ideas that this framework seeks to standardize. Yeah. We could say use artifact signing approach that implements that the update framework. And it's not a explicit go use, like, we're still safe of the lines of no kick makers. Yeah. Cool. All right. I think that's reasonable. I will make a few of those notes. I'll put that back into the Slack and go and have a couple of first sabs. I think there's a bit of homework there. A few people too. Right. Got a few minutes left. Or what I was going to do then is to look at the actual, well, two things. One, go through and look at the assurance categories that are blank and make sure we can add them in. Two, I think Blake, myself, and probably Richard, are going to just finish off some of the chewing on 20 to 40. I can then integrate the feedback from the different reviewers. Thanks for sending that through yesterday. That's cool. But from what we talked about earlier, we don't really have. We haven't really gone through and done that single voice element of it. So what I would suggest is if we do a bunch of edits, because I think I'll probably get everything I've just referred to done over the weekend. But then I think we're probably at the point where we need to lock it and then give it to someone to do the single voice over. You think we're at that sort of point? Apart from, Anders, there's a couple of little bits that we're going to have to add in there. I feel like it's closer, John. I mean, just seeing the edits from today, I'm like, this is so much more readable. They're still not in a single voice yet. Right. Yeah. On a scale of 0 to 10, what's the readability score, Richard? Six. I'm at about a six at this point. It's at least one of my notes was like when I got to that section, it was like starting a new paper. And now it actually feels like it works with the previous sections, which is good. It feels like one cohesive paper. Yeah. It'd take a day. Yeah. We are getting into the length. I mean, I get that we'll probably have derivative works that will be the condensed. This is all you need to know. You know. The ontology, the supply chain ontology. Let it simmer. I actually really liked the graphics Emily made and like that whole section. I think that that could be on its own. I really do think it could be a standalone. If you don't understand what build pipelines need here, take a minute. So yeah. Someone has to submit a proposal to O'Reilly. Might as well be you. There we go. But John, in terms of the next steps, I mean, we have, I think edit wise, we're mostly focused at this section with the recommendations, right? We Alex, I guess we don't have, we definitely, we don't have coal or or Blake anymore. But the the preceding sections, do we need to go over that at all anymore? It feels very concrete now, this, this whole area. There's a couple of recommendations. Yeah. I think with between the four of us, we kind of hammered that yesterday. I'd say. So it for for this section, it's really just these, these, these recommendations. Make sure they're all sound. Yeah, exactly. And I think too, I think it was Nisha's point. The reality is right at the bottom of the document. There are a couple of, you know, a couple of orphan things. I think these couple of things that could do with an owner. Yep. But I think in the next 15 minutes, if we just get the assurance category and risk category and everyone's happy with what those are, we'll add the feedback we just had in today. We can do with someone to adopt these two sections and finish them. And then I think we need those three people that go through and just give it the once over and put it into a single voice. Cool. And if we don't get around these, we can, we can have some text that conveys, hey, this is not an exhaustive list. These are some other considerations and these become bullet items rather than like fully spelled out. There are other things you should also be thinking about. Yeah. Yeah. Who to just to finish this up then, who's going to own the deep, who wants to do the D bomb S bomb and who wants to do the sharing of S bombs? So it's basically D bomb. Any owner for that? I wonder if this whole D bomb thing is mature enough to be recommended. I don't know who added that in. I'm also curious. I don't know what D bomb is. I'm going to throw that out there. It's a digital. We have a lot of in TOTA. We have a lot of in TOTA sprinkled throughout. Yeah, it does feel like there's, there's one. It feels like a very, I saw that in a couple of the recommendations where it's like, oh, this is a TOTA language that's being crept into general recommendations. No, it's actually not. But what it is, is actually this one, really. It's the, or my view of it is, it's the sharing and exchanging of S bombs. D bomb is a mechanism of doing such. Okay. There are other things available and D bomb is certainly fairly early in my view. But if we are, I think this is reasonable because I don't know necessarily is a particular solution for it. Maybe that's a gap when we highlight it, but we have to have the ability to share the S bomb data securely. Yeah. And what's good about that is it's, that's a generic recommendation, right? You know, we know what the word sharing and exchanging. We know what S bombs are. Organizations can figure this out, how they see fit, right? If other tools emerge in the next couple of years for doing so. Right. We can even references a couple of things going on, but we do need someone to own that one. Anyone want to own and fill that one out? I guess I will. Excellent. Many, many thanks, Nisha. So I'll put you down for that one. Do we want to throw D bomb in the glossary? That's probably a good idea because right now there are a lot of folks who are asking what is this D bomb? So. Yep. D bomb is looking a little bit poorly as well actually. We probably, sorry, the glossary looks a bit poorly as well, still. All right, cool. So we've got those two things. 12 minutes. I was curious, sorry. Hi, teacher. Yeah, I was curious about the bullet points under ensure clients can verify the freshness of files and there's a comment that they need to be converted into recommendations. They're basically about validating S-bombs and total metadata admissions controllers, so on, right there. Your clients can verify the freshness of files. Yeah, but the bullet points with the, yeah. Those do need to go somewhere. Yeah. I haven't got down to this bit. Well, that's interesting. Are these, why aren't these actually recommendations? Or are these recommendations? I don't know. I would expect that, you know, if anyone wanted to validate any of the supplemental artifacts such as signatures and S-bombs, they would validate the signatures. On the, on these things. So I would expect that if anyone is creating an S-bomb along with an artifact, they would sign both the S-bomb and the artifact. Yeah. So I think these are, sorry. These are different. These, and this is probably what you're saying, but these are not connected, right? They aren't connected. I think that a leftover from when the section was first kind of put together and we were thinking of what needs to go under securing deployments in general. And also if, I think this is similar to what Nisha was saying, but if someone is using, if we've already made a recommendation that they need to use in total, they need to do, you know, create S-bombs. We may not need to go in detail about actually performing verification or validation, but maybe we could kind of combine all of them into one section saying perform a verification or validation workflows for all of the metadata you've generated so far. Yeah. Yeah. I think we could combine this with the previous one, right? Instead of ensure clients can perform verification of artifacts and metadata or something like that and merge it like in the previous category. Yeah, that's probably right because that's exactly what you're doing, right? You're validating. That makes sense. Yeah. For, I can only really speak to the in total verification workflow here and we do have a, I can drop in the link to that particular one, but I don't know how we want to point people to the right places in general. Well, like John said, I think that, you know, linking or adding verification to any kind of signage recommendations is the way to go. I mean, the only reason you sign a thing is so the person receiving the thing can verify that you've signed it. And then you don't, you can't really verify anything if it's not signed. Yeah. I think there's a bit of a little bit of increased verbiage that needs to go in there. And we can delete those too. But good spot, right? These are kind of orphaned. So we do need to update that one, unfortunately. I, yeah. I can, so I think, okay, sorry. I really don't want to make this very in total specific, but I do want to note that the recommendation there probably goes beyond just validating the signature on the metadata files because in total has its whole verification workflow as well, the link in there files are matched against each other. And total is a state of the art. And in the absence of that, we have nothing else. So you do need to fly the path towards that and exemplify it. Do you want to take a go with Disha at expanding upon this one? Oh, I can, I can give it a shot. I think I, okay. Do you want to take a look and we can just review it or change it or what about this last one? Admission controller potentially ordered only to start on this. I'm not actually sure what that really means. I think we should get rid of that because the Kubernetes admission controllers is an implementation detail. If anyone wants to make an admission controller that does the verification for them, they can. Wait, are you saying that not everything cloud native is written and go and deployed to Kubernetes? Is there any world outside of that? I'm being facetious. I was wondering in this paper, we're gonna acknowledge that. Okay. In total is written in Python. Go implementation. If you want, you can make a go implementation. Oh, there is one, right? Yeah. Yeah. And didn't they just rewrite tough and rust recently? I'm sorry, there's a, oh yeah, yes. Yeah, I saw that. That was quite cool. The Roth per bottle rocket. Yeah. John, you're talking about assurance being a piece that's missing. Was that what we just covered or is there another section of assurance? No, I think there is that missing, but I think we can just add that further up. You mean the comments we had about the build pipeline? Mm-hmm. Yeah. I wonder if that's like a higher level section on its own, which is incorporating formal methods like S&P filters, automated reasoning, provable security, kind of like to add like net new stuff. It's not really general guidance, is it? I can make the verbiage and we can figure out maybe where we put it. Okay. Get feedback on that maybe. Yeah. I don't think it is missing. It's just, it's wanna, it is an element of it, but I... Yeah. And the biggest challenge with any of that is, well, setting constraints to the scope of policy, right? To this non-pollinomial. So by when will you, like, yeah, you really need to constrain the problem. And I think constraining it along supply chain might be a way to grow rather than talking about all software. Yeah, exactly. Otherwise you'll never end. Okay. I think we've got to the bottom of that. We've updated the, that list. We haven't had time to go through the different assurance categories and we've only got three minutes left. What I'd suggest is maybe does anyone want to have a go at it and dedicate themselves to just adding initial thoughts around the assurance categories and risk categories and then add a comment back onto Slack for review? Any takers for that? We're looking at kind of, I think it's from down here practically. Where is this building systems? Does everyone know like what makes something high over moderate that we're going to take a stab at this? I may be sounding silly here, but I don't even know what assurance and risk categories are. I think we have a definition at the top of the paper, I think somewhere. Yes, it's in the top. I think Marina also raised this point in her review that she sent in, but a similar point that I would make is I'm not sure reading through this of any situation where those are going to diverge from one another. So I'm wondering if there's any point in having those as two separate, but I think it's worth defining them as two separate things, but in our recommendations, I feel like they pretty much are always going to be the same. So maybe we just put in one level and however we want to phrase that level, but put one thing in. Alex, to that point, should we just write a sentence here that all the recommendations below are either moderate or high and then we just get rid of the byline underneath each of the items? I think we did have one sentence that says there are no low. Yeah, I kind of agree with the risk and assurance thing because I think it's useful to stating that there's a problem or there's differences at the top, but actually kind of almost state a single one. But I think there are situations where we have moderate versus high, certainly when we get to those controlled environments. It'd be interesting actually to see if all of the highs are actually corralled effectively in the air-gapped environments. I don't know if that's actually, no, it isn't right here, right? Well, we could leave it to the sermon of the reader, but it looks a little bit of a pie chart to have for every single item, assurance categories, risk categories. That's what I'm saying. I think we just have one, but I think there is a difference between moderate and high. We just need to ensure we define that. Should we have it at all? Do we have it at all, you saying? Yeah, what if we remove the risk category? And sorry, what's the other one? You scrolled it. Assurance, I think it's assurance, I think it was. It looks like great metadata for like a companion file to check in on GitHub, but... But what are we saying though? Because there is, I guess if we, I think we need some level. I agree, we probably don't need two, or from my view, I don't, it gets lost really, whether we need assurance and risk. So maybe just have one, but I think it's useful to have one of them to say it's moderate or high. Okay. You're saying you don't think there's value in that and that most people are just gonna go for it? I think even for the moderate ones, they are moderate slash high. A lot of it is, well, we're trying to get people to improve their posture. So we want, yes, like you're gonna have higher degrees of assurance and like we want you to know the risk that goes with it, but it's almost implicit. So... I guess the one that jumps out to me is the rebuilding your libraries from source in that most people are probably not gonna do that. But in the environments that are, depending on what your definition is, like highly secure and super, super regulated. And even then only the absolute top of the top. Yeah, that's a great recommendation. You definitely do that. But if people read the paper and think, wow, the recommendation is we actually wanna rebuild the source for all of our libraries that might give the wrong impression. Yeah, so how about I suggest the following and I volunteer to do it. Instead of having it assurance categories call and risk categories call I can collapse this into one sentence. Yep. Before the paragraph to say for this particular item, we want you to know that the assurance category is between moderate and high and the risk categories are for such. It's softened from like a just looking at it and not actually reading through. And we have a little bit more room at qualifying that. Yep, I'm good with that. What does everyone else think? We might be splitting hairs here. I think it's beneficial. Yeah, in turn to agree. Hello, Andy, have you been here all along? I came in bang on the half past four. So I caught the latter half of the discussion. Well, half past my half hour. Good to see you. Yeah, good to see you too. I'm not sure if it was a time zone issue or a retoddiness issue. You're an hour late and we're closing the meeting. Really? Yeah, I did it last week. Don't feel bad. Oh, thank you for having it. We had this discussion and... I told you about it. It's like I was an hour late for that meeting. I missed security last week. Well, there you are. Same deal. This whole time zone thing. It's a killer. Yes, that was a slightly different answer to your question then. I have been working away for the last hour but just not on the call. It did occur to me as well. Ah, okay. The one constant is the still beer o'clock for you. There you go. I don't feel as bad now. It's good. Safety in numbers. Good. I think that's a great idea, Anders. Yeah, that's cool. We're a couple of minutes over but I think we've... I think this is really coming together. I think the sort of focus really on 20 to 40 made a big difference. Then we just need to collapse all that stuff in and then we're in decent shape. What we didn't identify was who was going to go top to bottom with the single voice commentary. Does anyone want to take a shot at that? So we had Richard, Alex and Marina on the hook for that. I can also... I'm wanting to do the same. Yeah, I'm wanting to do the same. I guess that the approach that was taken rather than single voice was just actually manually editing stuff. Unless I misinterpreted that. It is. Right. I haven't done my review yet, so I will go through with a more of a single voice when I do it. Right, right. That's what I thought is some really, really good reviews and commentary that need to be factored in but not as much just from a single person perspective. Yeah, it's really about Ward Smith-ing and giving it an editorial review. Yeah. Cool. All right, same reviews. Great if people are up for that. And I will certainly do that too, as you really self-understand. Great. We have Andy. We can use some of the Queen's Royal English incorporated in addition to yours, Don, just so we meet the standard. I'm happy to represent Her Majesty in her absence. Yeah, I've got a couple of book deadlines coming up soon. Which is why I'm not instinctively jumping in. But I am happy to be in there. Just you understand what I'm trying to work my way around. Yep. That'd be awesome, Andy. Thank you. And if we left it to you, the graphics would be all sorts of cats and massive amounts of very cool animations. So if you just stick to the verbiage, that'd be awesome. Very good, yes. Great. OK, thank you. We're a little bit over, so apologies for that. But thanks so much for your time. And I'll put notes in the Slack and we'll take it from there. Don't forget appendix one. I still don't have any container opinionated people to review that bit. Andy Mardin. I certainly qualify for one of these things. All right. OK, thanks, Andy. Right at the bottom. Thanks for reviewing, Andy. Sure, thanks. Sorry I missed your message the other week as well. Yeah, I will get it. OK, thank you. See you, everyone. Thank you, everyone. Thanks for your time. Good to meet you. Thanks, everyone. See you later. John, you want to talk about KubeCon? I've got to jump to another call I'm supposed to be hosting, but I can certainly ping you back on Slack or. OK. And I know it's later than Friday for you, if you want to talk early Monday or whatever. I'll be on for a while yet. No worries at all. I'll be here for the rest of the day. Great. Thank you. Talk to you soon. Just wait.