 Hey, Michael. Hey, how's it going? Yeah, not too bad. Happy Friday. Be good to catch up with you later on today if that's all right. Yeah. Yeah, sounds good. Very cool. And wait for people to join and then hammer ruthlessly through this document that I know people have been going through. I've got a couple of passes and I am spoiling myself ready for another top-to-bottom review. It took me ages to get here, but Michael, I finally got halfway through your section today. So excuse the unfinished business, but I will get more done today as well. Finish that off. Yeah, I'll actually have some time this weekend. So I do a lot of volunteering, so I tutor a lot of folks in programming. So in the past, they have a big project coming up, so I haven't had a lot of time to focus on this thing. But this weekend, that's over. So I should have more time to to go back over. Well, I don't do anything quite so selfless, and it's taken me weeks to get here. So you're doing better than I am. I'm open to suggestions here, but I was thinking of just going top to bottom, see how far we get. It's like a joint edit. I know multiple people are then going to take separate sections. And I for one, I'm going to take another sort of run from top to bottom tonight, if not Saturday again. Any other suggestions? We're efficiency. I'm going somewhat stir crazy at this point. We're doing the same document over and over again. It's good stuff. There's some really good stuff in here. I'm just I'm. And I think to be fair, it was a small victory for the the British with Artifactory Artifactory. Oh, did you guys want that one? Clearly, I wanted to be like, hey, what's the major tech company that stores artifacts called? Is that RTE? F.A. factory? I think the company's called Jayfark. Yes, the tool. I'm sorry, Michael. I misspoke. Also, I always forget that that's the company name. It just does not connect to me. Very good. Very good. All right, look. If unless people have another approach for efficiency, I was going to suggest just going through like that and reading and joint editing and closing out some of these comments. Completely up and further approaches. No. All right, let's go. So if you can open up the report. What do we do? Maybe go through and just look at a section at a time and then offer feedback or we can update the text or pull in the different comments. So I guess if I look at executive summary. The comments for that. Oh, what's going on? There are any comments actually in executive summary? I don't think so. You can see everyone piling in anything specifically to change on that. I don't think there's any comments assigned to it. No, I'm going to take that to me forward. Open source tools and project map. I think that's a really cool idea. I'm just wondering about whether that's a race place to put it. It seems like something that would be at like an appendix or, you know, down its own page, really thumbs up. I think it's a really cool idea. I'm going to copy that then and paste it to the bottom. I'll be back with you in a second. That's a long document there, right? OK, into the introduction. Got a comment and in how we want the reader to use this paper. I have a question about the scope, actually. I think you may have missed it. So this paper is not covering container funkiness, right? You know what I want to go through? Yep, the container funkiness. I missed that day in college. What do you mean, Nisha? So the scope is general source code practices versus container best practices. I think, yeah, I think it's definitely not just containers, right? It's we can we can solidly say it's not focused on containers. But I do think containers are a big part of it. And we do mention, I believe, in the actual document, how the the I think on the signing side, specifically, how that can apply to containers and built deported artifacts. I think when we say artifacts, a lot of times this group means containers. OK, the comment says container recommendations are very specific and could stand as an entire separate document. Where is this? This is Emily container recommendations are very specific and stand as an entire separate document. Defense is container design from trusted supply chains. I'm not convinced it would be a separate document because it's so intertwined in some of the things we're suggesting. Can we can we maybe point out just to help frame it? Can we point out a few things that we're referring to when we're talking about container recommendations? Obviously, we've got the signing, we've got multiple bits of scanning, but. So there is probably something we could add about the base images that are used in containers. Yeah, evaluating those, we could add something about make files and build scripts that use containers as build stages. Some stuff about multi-stage Docker bills or multi-stage builds in general, keeping track of those. Um, I suppose signing is I mean, the sign is signing that the data image is what it is. It's the best we can do for now. And then probably some best practices around Docker files because it seems well, best practices around, you know, pulling using a mutable tag versus pulling by digest to keep building reproducibility using. Yeah, so I am I am just pouring all of this out. So that's why I'm asking what all of this in this document or a separate document? Well, that's the thing for my view. I think it's difficult because it is kind of intertwined, right? And the reality is we are the CNCF. Um, and I wonder if if we we sort of start to expand upon that. And if we get to the point that, look, it kind of gets in the way of the general flow of content, maybe it is kind of an appendix or it's a reference to material already exists, but at least we reference it inside the document. It would that be an approach, right? That's what I did for my paper on my side is I mean, containers are kind of a part and parcel of the entire thing. It's pervasive throughout the entire supply chain because ultimately that's in a lot of ways that you're deliverable, right? And so you're acting upon them. And all of the points you made are absolutely spot on. I think they need to be mentioned, but there are other documents you can reference out to. So you don't have to explain. OK, let's talk about multi, multi stage builds. And you know, here's some pros and cons. We don't have to do all that. You can point to different things that say you definitely need to focus on that and make sure you have the most minimally smallest container to give yourself the smallest security risk at the end. Stuff like we can give those recommendations, but based off of other documents and articles that already exist, and I definitely think it should be a part of it. So the reason why I am advocating for writing out all of those recommendations specifically here is because the existing recommendations around building container images actually contradict all of the stuff that I've said over here. For example, you know, oh, use. Oh, use. You can you can just pull from an image from Docker hub. You don't have to check the base image. That's that's not something that's not something that is recorded anywhere. I don't think. Um, so I think it makes sense to add this. And I think there's a valid point as well, right? And then we but but I guess my my mild concern here is is on the the size of that scope in increase in certain timelines, right? And frankly, who's going to write that? So but I think I think it's an appropriate statement, right? So I think a way forward, is there anyone on the call who actually wants to take that and perhaps initially suggestion, but maybe write it as an appendix? And then if we're able to get to the point where it is a consolidated whole, maybe we can actually push it into that document. Or someone to focus on it, I guess. Well, I can do that for you. I've written this for VMware internally anyway. So it's just modifying it. I have added some wording around hardening containers based upon upon the Department of Defense approaches. It's more focused on the abstract of taking scratch and adding stuff with this or this or the inverse just reducing or copying into a multi-stage file. So it's it's there at a high level, but there's no there's no detail on the actual Docker file hardening steps. I'd be happy to add a few more bits to that if if you want to just collaborate on that or or I'll follow your lead or whichever. I'm happy with that. That's fine. So Nisha and Andy, do you want to maybe on that comment and add your names in there that you take that? And is it is it reasonable to add that initially? Is that appendix and depending on the the speed and detail we can look to integrate that because I do think it makes a lot of sense to add it in, you know, it's just annoying that it's additional scope. But actually, it's the right team, the right place to add it. It's the right scope to add. Yeah, yeah. Yeah. Does it also make sense to maybe just highlight the differences between, you know, building because I think that there's the there's the other concern with, for example, a build worker container, like something that's going to be running your build is going to have a like increased set of concerns over just sort of normal, you know, if you're building like a random application or something like that. Completely. Now, that that is I don't recall whether it's actually in there, but that's what I was referring to last week when we were talking about, you know, having the pipeline to create those really hard and build containers for those workers. And that that absolutely has to be in the middle of the document, in my view, because there's a lot of. I can I can take that one. If it's maybe a science, I can have a shot at writing that part. Yeah, I briefly go over a little bit of that in my section, but not really like just saying like, hey, you should have a minimal build container, but not really explaining how you would then do that. Great one. Yeah. Oh, I don't know what I actually is a comment. I'll do that. So in the life cycle management of that build is pretty important as well. So, Nisha, can you if you wouldn't mind, I wouldn't mind joining you guys on that conversations for the hardening of the for the better practices for containers as well. Sure. So I've given a note for myself to add that appendix for container images so we can collaborate with it. Great. OK. We move on there. So, Mike, you have a comment on the introduction software supplying checks. I would soften the stance. Yeah, basically, the way I read that is like the only attacks are coming from an outside entity. And so, and I think the side comments are probably pretty pretty important, like what exactly do we want to determine is the what is the supply chain? And I always consider software and my own internal teams to be a part of that whole software supply chain. It's not just from outside, but I could write pretty poor software that exposes vulnerabilities pretty easily that have no dependencies on outside resources. Indeed. So that was all. I just I figure we could probably soften it up. I can provide what I what I would potentially write for it and be just expanding lightly what it is. And if you like, I didn't know where my scope is just reviewing or helping contribute. So I just kind of love. Both. No, no. OK. Both or everything. OK. Welcome your feedback and input into that. So if you want to. I can I can update it. Yep. I also very much agree with that at the previous place. We definitely that was one of our biggest concerns was we actually built the majority of our software in-house, but we were concerned about developers injecting stuff they weren't supposed to into our internal supply chain. So moving on. Right. So couple of just minor additions in here. So Alex suggests deleting supply chain security. It's a detailed catalog of supply chain. It kind of makes sense to me. Thumbs. Yep. Done. Add the supply chain. Supply chain effects. Yep. Makes sense. Aggregated risk from software supply chain compromises continue to grow. That was just a simplification of that sentence to make it flow a little bit better. So whatever you want to do there. Got it. And you deleted the from Atlantic Council. I just moved that into the footnote. OK. Cool. I like the ominous. The problem is not going away. I guess there's a couple of ads and deletes from Alex. Do we want to quickly just look at them and agree on mass? Yeah, it makes sense to me to be fair. There's a home and a half from. I just made up a term there, but there's no Richard you look coming like you're hiring. The four example few architectures exist for implementing recommendations of secured software factories. If is including that. Actually useful for the overall objective and what if that changes. You know, I think we should write stuff that is. Maybe. I don't know. This is nitpicky at this point. It's fine. This is still the introduction. People are going to scan right past this. I do wonder if that I mean, I do think open source often has a problem with identifying exactly what its scope or current level of maturity is. I wonder if we put something like as of date X. This is not a well developed or it's a nascent. Something to that end. This is a nascent rather than sort of dating it perhaps. Yeah. I think that that's. That's actually not terrible. We'll look back at this time. We'll say, yeah, there was really nothing. I'm not bad. I have a high level question. About this. How far down the stack. Are we going to provide recommendations for. Do we provide recommendations for IOT devices. Sand and chipsets, right? So at this point it looks like we have a lot of recommendations around the top level securing the source code. Do we. Do we put the onus on people to, you know, check all the way down to their firmware? Would they really, I mean. I guess if we, if we think about the. The, the sort of actors, we're looking at moderate security, whatever that means in high security. So if we would say to someone, look. Whatever that most moderate posture is. And we're going to have to make up what a moderate posture is. What would be the reasonable assumption. If you were doing it at that. Moderate level of a risk assessment. Would you. Start looking at the firmware on a chip. Would you harden your operating system. Would you at least check the source code. And I guess that's might be a way of trying to figure out where we'd stop. What do you think. If I was going to throw my hat in, I'd say that we. We have to define the trust scope and making that up. And maybe shared responsibility is a good thing to fall back on. And we just say, we expect the hardware is not back door to compromise when we're using it. I think it's a great point of stating that. Yeah. That's, that's what I did in my paper is I literally, I basically said that there's going to be a hardening process you're going to do in order to build your software and run your software. Like the scope of this paper doesn't include that. I can say there's a few things that we can do, like minor things we do, but really it's picking up from the responsibilities of a developer and a platform admin. And then running that through the completion up to the point where it goes into a production at that point, I'm pretty explicit on my side to say at that point, there's tons of tools and techniques and things that are well-defined outside of that range. It's just the scope of the developer and the platform operators. And we have, and I think it's great, right? Because we've got the assumption section, right? So that's effectively where we'd state that, right? This is assumption of what's in and what's out. Is the OS part of this? Well, I, I think we'd state, I think to Mike's point is that look, the assumption is that you have hardened the OS, you have, you have, you have, we're not going to look at chipset backdooring and such. I think we make that up in the assumption. Yeah. So it's the shared responsibility model. You need to make some assumptions somewhere. And, you know, and maybe that spawns another paper in the future that talks about how do you go further down to the hardware level. And, you know, that's that part of the supply chain, you know, the physical supply chain, but one paper is not going to handle all that. So just draw it, draw your lines in the sand and say, this is where we make the assumption that at this point you, you're working on this and then the exit the same way. Like we assume that you'll take responsibility from that point on. Here's the recommendations for that gap in between. But container OS is in scope, right? That be the running it or the building of it? Both. So, because that's, that's kind of like I, I looked at that as well and I kind of left it off my side of the paper because it introduced more scope that it wasn't, you know, that if you think about it from a developer's perspective, you don't have a lot of control over that. It's kind of what's there. And so I assumed that was, or I made the assumption that that was the part of scope that was out just because of the, you know, it's how much scope do you want to put in? And you could make an argument for both sides to say, yeah, it could totally be a part of it. You could also make, you know, an equal argument saying that who has the ability to make the decisions or changes within that. And it's probably not necessarily the platform payment. Maybe it's, you know, operations or something. So I, I just kind of, I, I left it out of mine for that reasoning, but I could use both sides too. So yeah, we originally talked about having this paper provide kind of a roadmap for gaps in the open source ecosystem. So if that's still a goal of this white paper, then we should definitely include that. I think it's also worthwhile to, to make the distinction between obviously some of it's going to be like the hardening of your software factory and all the things that are sort of all the components of that, like your build systems, your CSED and whatnot, and the hardening of the OS and separate from, you know, building of an end user sort of application OS. I wonder if we would say that we are forced to trust a couple of vendors. One is the infrastructure provider or cloud provider. Another is probably the vendor that ships the operator or the Linux distribution that we're using under the hood. And so we say that we trust those not to be compromised, but then another vendor who might be shipping us binaries. And it's just that one, my magic binary that does everything kind of thing. We would trust that less and then model the build processes if that was already compromised and then decided not controlled based on that being exploited. That's, I think that's where my mind is. So I'm down in the assumption section. I sort of jumped down if people are following me in the document and I've just put a brief summary of text in there. I think covers what we've been discussing under the shared responsibility section. Feel free to, you know, comment. Paper doesn't detail recommendations, protectors against hardware vulnerabilities, backdoors, nor does it detail operating system hardening. This will be part of the shared responsibility between developer build team infrastructure provider and operating system provider. Not wedded to any of that text. It's just that I think that was a summary of pretty much where we went. I think we can also maybe state the assumption that, you know, your hardware is not backdoor and your operating system is not backdoor and we're just going on top of that whatever. Yep. Is that covered in that first sentence or would you suggest changing that somewhat? The first sentence doesn't include the operating system. I feel like it does, but it doesn't. Like it doesn't say that, you know, the operating system is in backboard. Oh, I see. Or backdoors. This does not protect events. Backdoors in hardware or operating system. So that might be a good area also to link out for if you've got other areas that we can share links to to say if you're interested in or while it's outside the scope, go read these things because it's still important. But go read them here. This paper just doesn't cover them. So you can, if you want, you can tag me on something like that and I'll go drum up a list of a few different ones that we can vet what's our most important to do. But I'm more than happy to do that work. Excellent. Thank you. Alex who added in network provided you want to finish off that comment change. I think I think I heard Andy saying something about the cloud provider being one of the other things that we had to assume we trusted. I was just trying to make sure we caught that before we moved. Is that infrastructure? Is that more specialized in that infrastructure cloud provider? It's a funny one because I guess if we're in the cloud, then we trust that our shared data stores are not compromised. For example, if we're on prem, that's probably slightly more in scope as somewhere that something might persist. I wonder if we need to draw that distinction. Just updated. Right. So if we, I think we missed a chunk. I appreciate we're still in the introduction at this point, but we've solved that. I believe where, yep. This paper is intended to provide the community with a best practice and reference. Yep. Right. So onto audience. The issues in audience. So we've got comments there. Scope. So I've got a comment just, I just hung it off goals. It's just a sort of point of order really of how we actually structure our recommendations throughout the piece. We should probably do that when we get a bit later on, but. I went with the approach of. One line explains a, you know, one line to explain what the recommendation was, the insurance, assurance category, risk category, and then the text of the justification. The only thing I would say here, John on this is along the lines of like, this should be, you know, in the abstract, it should be the very first thing somebody sees when they get in the paper, right? Like if I don't know in the first, that first paragraph, what this is going to do for me, I'm going to click acts on the, the tab. So I, the, I, if we're already putting it there, I would say, let's hope not to repeat ourselves. How do you, how do you mean, Richard? You mean like a legend to where to look for, or a summary of each of the recommendations? No, if there's a goals, if there's an overall goals. Oh, I'm sorry. Right. Section that, that that's going to say what you're supposed to get out of reading this paper. I would expect that to be, you know, the very first thing that you see when you open the paper, one of the first, probably two paragraphs. It would be in an abstract if this was like a scientific paper. Right. Which I don't know how we, if we're, we're planning on doing such a thing. So the realities, is it the same as the executive, the executive summary? Just, I would say so. It's the goals are the first couple of sentences of that executive summary, hopefully. Is it actually. I don't think so. The executive summary kind of gives sets of backdrop. And maybe what I would, I mean, I'd recommend the first, this goals section to be the first paragraph and then the second paragraph. For the everything else. Any other thoughts. I agree with that. I think my understanding is the executive summary is just a stub right now. And that it's going to need to get rewritten after we're fairly happy about the rest of the content. So I think that'll probably get addressed once that happens. It would be my guess. Should we just make a comment there in the, in the executive summary to outline goals initially. I'm not sure if Mike ends or what, what you guys, whether that's something similar, you all did in the Google paper. I mean, writing the, the executive summary late. Is that what you mean? No, the, the putting the goals right there in that executive summary. Yeah, they were, they were bullet points and ours, I believe, if I remember right. Yeah. So I don't, I don't think I had a subsection of goals. It was just, it was a part of that because it was like, that's the statement. Yep. I'm just going to throw it up there at the top and then put a comment on it that. Oh, there you go. I think you just did. Well, I did. Yep. Okay. So we don't know assumptions. We did the shared responsibility. Also assumptions on software sources. People live just so wrong. So I think these terms under software sources are all good. I would, it doesn't strike me though, that we've really used them very much throughout the paper. So I wonder if that's something that we should go back through with an eye towards sort of. Having a common vocabulary that we're using throughout the rest of the paper. If we're defining these terms up at the top. Also, do we need like a glossary at the back of the paper? Is that over the top? I'd vote for back. This is a lot of words to read. I'm going to lose interest. I think John, you're talking on mute. I am. It was absolute gold. But what I meant was, I've, I've added a glossary and should we take the software sources, sources and software groups and just put that at the back of the paper here. Great. Okay. They kind of also align a little bit with like a bit of a persona in a glossary. Yeah. I think that's a good one actually. We had to do for all of our documents is writing out personas or using a persona. I think we touch on it a little bit, but no one here enough. Assurance personas, but. Don't worry about that. We don't have things like admin. Or a platform admins or stuff like that. That might be able to be used within the. Like for ownership and responsibilities within the different phases of the set life cycle. Yeah, that's a good one. Actually. We had to do for all of our documents is writing out personas that we don't really go into that detail, right? Yeah, it makes sense. They don't have to be explicit if you don't want to just. Sometimes it's just figured out. I think it is good to make them explicit. Yeah. But I think it's. Yeah. Back matter material. Like don't make everyone read it. Yeah. Yeah. And what sort of personas should we have in there? Right. So if you want to tag me, I can put the ones that we typically use on our side. It's abstract. So it's not specific to any vendor of any type, or just entity, but I can throw in a few of them. You've got a couple already for like the raw source. Like you've got a couple of areas in there. So I'm more than happy to take that on. Awesome. Thanks. So it's right at the back of the paper. Okay. So assurance personas risk appetite. It's fairly light and commentary. Yeah. Yeah. Yeah. You see a bit of a typo. It says two security levels, low, moderate, high. I think we should either get rid of the low or call it three. Do we actually mention much about low in the rest of the paper? I mean, I don't know that we should recommend a low security. Right. Sorry, Vinner. Baseline. Instead of low. But I think if we, if we think through the actual. I think you've, well, maybe there are some recommendations, but I don't, I don't recall any that actually were only pertinent to low. What is baseline? Is that what everyone's using today? The defaults and therefore we don't need to document it. I'd say moderate and high me. You know, what do we think? Three or moderate and high. Any thumbs for moderate and high. Yep. Whereabouts did it say two? Is it in the risk environments or assurance? I can't see it now. Oh, got it. Do you want to change that, Josh? Sure. Yeah. Cool. All right. So then we're all the way down into actually securing the supply chain. So would footnote. Power grids from Andreas. Life sustainment systems may include resultant power grids and water facilities. Right. So I'm on that commentary existing research indicates. And then there's comments from Russ Anderson. And address. Well, it's quite a lengthy. What's the recommendation for change there? So I think it's basically stating that. When it was rewritten, it fixed the issue. So actually is that comment. Solved by the change in that paragraph. Existing research indicates. Or is there a text that needs to be added there? Yeah. It's think to me it's actually addressed in. Whoever rewrote that paragraph. Yep. Yep. Okay. It resolved. Is this a risk factor or a risk factor? Yeah. Yeah. We'll get to that. Whoever rewrote that paragraph. Yep. Yep. Okay. It resolved. Is this a risk factor or exploit path or attack vector or target back to risk commission? Existing. Major. It's the, so what do we call that risk vector attack vector or. Vulnerability. What is the appropriate. Term in that context. Any thoughts risk vector attack factor. Risk factor. Risk factor. Risk factor or attack factor. Isn't, isn't a tank factor more. Yeah, I've always heard it as a tack factor, but a vector, but. Yeah. Or a threat vector could be the other. I don't know. Yeah. It just depends on softening. How, how, yeah. How mitigated language you want to use for it. Like what doesn't sound as rough, but they're both largely equal. Attack vector makes it sound to me like we are suggesting that the most sourced software that you're ingesting is. Automatically going to, going to attack you. Threat vectors. I use the word threat more often than attack. So. I'm going to push people to open source. Maybe this is the way. Okay. Threat factor. Diagram needs review to ensure we are not using copyrighted or trademarked data. Very true. We've got a reference to it, but we should definitely follow up on that. Okay. Move on a little bit. Nisha, your comment was interesting. I've lost track. I'm sorry. We're, we've managed to make it down to securing the software of supply chain. And there's the picture, the image figure one. Yeah. Oh, that was a suggestion. It seems that it was. Accepted. And so. Yeah, I think the, I think the explanation is fine. So we can. We can resolve that. Yep. Okay. Done. Now it's a general guidance. Alex's. Verification. This is the heart of the software factory method. Is verification looking okay now? Are we doing. Yeah. I'm sorry. I said it one more time. Does metadata have a dash? I don't think it matters. I just think we have to decide. I've seen it elsewhere without the dash, but I don't know which is more common. Well, what's the English way of doing it? Google n gram search. I have absolutely no idea. The OED has it without a dash. We're going without. So the general guidelines looking okay. So, uh, just a small comment on the secure authentication part under general guidance, right? Uh, uh, I just need to, in the secure authentication section, I want that people to multi factor out first. And, uh, when, when we generally talk about public key infrastructure, generally people tend to move towards certificates. Right. And not SSH keys. Uh, so, um, so, uh, let's just put it like, okay, multi factor authentication, A, and then B should be like, okay, well, um, SSH keys. And at C, uh, we then, uh, discussed, uh, I don't know this biggest explicit limiting of an authentication mechanism to particular activities through app passwords or personal access tokens. I think we just need to kind of give examples here. Okay. Like established multifactor authentication, BS, SSH keys, C, personal access tokens, or application app passwords. So something like that, right? I would actually say that probably all of these options are like subsets of multi factor, um, authentication, because they're all like factors you could use for your multiple factors. Uh, no, no, it doesn't, uh, it doesn't fall under multi factors. Uh, multi factor has a very different definition. Uh, and, uh, you have to basically, these fall into only one category. Okay. When you explain multi factor, there are different factors like, I mean, you can give thumb print and there's a particular definition for multi factor. They all doesn't fall into that. Yeah, but they're, they're a part of the, one of the factors and maybe we can also include like fingerprints, biometrics, anything else that you can use to authenticate. I don't know if it matters to me. I tend to agree with, with Marina there. Like, I think like they, they are multiple factors. And I agree. Like if we, if we want to like be strict to the word, I think, uh, I can't remember it on the top of my head right now, but it's like multi factor is like a, who you are, what, you know, where, what you are like, there's, there's a depth, that definition, right? And we can probably get a little more pedantic about it. But I do, I do agree that those are one of the components of a multi factor. So. And also aren't we explaining that further down somewhere? So we don't have to think this, this section right here, it doesn't have to be highly specific. It can be, you will be reading about this. So we don't have to, at this moment, we don't have to define it yet. Yeah. So, so let's make it generic then, right? But, but as I said, uh, um, it's fine, but, uh, multifact, this, all these examples that we have, it is only one factor of multi factor. Okay. This is technically the, how the things is. So if we are, we are mentioning this thing at the other, uh, sections like securing source code. So yeah, we can keep it generic and we just don't give examples here. Right. But, but yeah, I did. There are a few terms, uh, which are used, um, which have particular meaning in the security community. So let's, uh, let's try to. Make sure that we stick to something. Right. Yeah. I think when we go through it and do like another sweep, we want to make sure that any of those terms we, we do refer to. Are accurate and then perhaps add that as the, as the glossary to the end to make sure that we're keeping ourselves, hold ourselves to account. Yeah. Okay. So moving down below the general guidance. Um, Is Mr. Martin and I clash on updates. And ours. Um, Secondary. Uh, those are, are they? What happened there? I don't think that was me. That was an anonymous elephant. Um, that might have been me. Sorry. Don't worry. Yeah. Uh, right. So this methodology for securing a software supply chain, uh, a comment here, should these two be merged in terms of paper organization into a testing and verifying? Um, Testing the trust with the artifacts and verified. Alex, you want to. Yeah. So I just, from the perspective of how we're laying out the paper, do we want those to be treated in two separate sections where we have a section on, um, You know, on the attestation and then a separate section on verification, or do we want to kind of merge those together into the same heading is what I'm asking there. Um, and, you know, Um, At the sort of like heading one level, I guess, um, in terms of our, our major sections. So I guess I, I sort of, if, if I'm reading that right, I, I, I split them out in that, um, Sort of map it to technologies and such the attestation is, is assigning the in total, et cetera, et cetera. So the, the, the validation would be at the end of that pipeline, potentially just sign it and get slightly or a actual runtime when you validate the, the artifact in the metadata afterwards. That's how I'd sort of see it, but. So I was seeing it separately, but. Open suggestions. Anyone else. Separate separate. Um, Subtly separate, but separate. Um, I think we'll comment about this, this block of text right here. Um, we're essentially reiterating the heading titles that are on the left. If you have the, the Google docs windows. I know we have an anti checklist block, uh, amongst us. Uh, but I think that maybe it would be pretty straightforward to take the heading titles and then the definition because reading through that, that comma, uh, the list of, the sections here. I'm like reading definitions and I'm just sitting here going like, it looks like a really long run on. Um, I'll be honest. So if we break it up into that here, the header, the section titles that you can see when you, when you go to the abstract or whatever the table of contents is going to look like for this. And this is what they mean, which is, I think what somebody did here, they extrapolated out. They, they, they mapped from the heading title to a definition of that or at least an explanation. It might just be cleaner and I can do that recommendation. I can do that real quick. Um, and I'll put the recommendation. I won't even say. Sounds good. All right. So we're down to securing source code. Yep. Not much to change down here at the minute. Yeah. So, um, so, um, on the slack channel, there were two points that I still have to edit. Uh, I mean, there was a consensus reached. I think we all discussed our points. Uh, so those two aspects, I do have to change. Um, I couldn't change it last week. I'm, uh, sorry about that. Uh, it's just, I got busy in something else, but I'll make those changes, right? Those two aspect one was related to define a list of allowed files, right? This recommendation. So we need to kind of, um, I mean, we, we have different opinion here on the group. So, uh, so, uh, right now my point of view is we keep this thing and we'll just try to make it more smoother or softer. Right. Uh, so I have to think about the con content. What to put here, right? Um, but yeah, these, uh, one thing that I do like here is that we have a lot of recommendations and, and this is something that I do want to keep explicitly. I do not want to write paragraphs. I just want, if somebody wants to secure source code, they go into this page and they say, okay, these are the recommendations and they are out of it, right? And similar should be the pattern for other sections. If we are doing image hardening, somebody goes to that section, reads the recommendation and then go out, right? Because the paper will be long. No. I don't think so. People are going to read a lot. So yeah. I almost think in the interest to see how other people did it, but, but you know, we've got multiple different, um, recommendations. You know, almost if we have like a, we're loading up in summary sections, but maybe like literally the summary section that lists all the actual recommendations or a checklist. I think the OSP, um, SB CS standard is written in that sort of way. So it's easy to pick up and just get a general idea of what people are looking at doing. Yeah, that's a great idea as well. Okay. At the top of the section, when we are starting like securing source code after giving the description, we can just list all the recommendations and bullet points. And then for details, people can go into the sections. But I guess I was thinking the back of the paper. I've also got to, you can also run it as a series of blogs and other stuff too, because those are largely going to be out there. So it doesn't have to go into paper. You can say, here's the consolidation of it. You can also run it as a series of, you can also run it as a series of blogs and other stuff too. And you can also reference the, from the blog to the paper or something like that too. Right. Because to me, I mean, one of the goals of the paper is to provide those recommendations. It's, it's not just a, a text that you. You read necessarily, but it is, or the way I was thinking it was, this is a punchy list of real recommendations, actionable things you can do. To, um, To secure your supply chain. I mean, I think it's just sort of a, um, you know, not to use the word checklist, but something to resemble the checklist in the, um, in the executive summary and, or I guess it couldn't also be an appendix. There was some talk of that on Slack. Just to throw that out. Yeah, I'm in favor of that blog thing, right? Eventually when the paper comes out or even before that, we can write a blog on each of the big sections and we can then write a blog and in which we iterate the context. These are our recommendations for more detail. Go to the white paper best practices and stuff like that. But, but yeah, I, I'm, I'm not attached to anything, whatever the group decides we do it, but, but yeah, we have recommendations here and they should, I think go on, go out in this format, right? Also looking down, um, you know, correct this spelling there hopefully to assets, not, not assets. Um, I appreciate we're sort of running out of time. Uh, we get to defining roles. Uh, this is actually the roles that we specified at the back of the paper now, right? The suggestion is the section would be to use code owners style features, particularly good. Yeah, I mean, if you are defining personas in, in some other section of the paper, then, uh, I can reference that section to make this section more readable, right? That okay. We have defined personas in XYZ session and based on that within the software, uh, securing software context, only these personas are applicable and you should define then roles according to these personas. And then I have said that, okay, well, they will enforce the fine grade permissions and they will enforce the four eyes principle, which, which generally means two person approving something before anything goes into, uh, any kind of, um, uh, build by, uh, sorry, a release pipeline or a deployment pipeline. So, so if you have that persona section already built, just let me know. I'll try to hook into that section and make sense here. I think that's part of it. We're trying to add at the bottom. I think for sale. I appreciate we're sort of at the end of our, our time there. Um, I think we've got through a fair chunk to be fair. It's only about a third of the paper, but I know that we're multiple people are going to go through it over the next couple of days. I'm going to have another go tonight. Um, I certainly think the front part of it's now a lot cleaner. Um, more to do. I wonder if, um, how many, how many people are going to are interested in having to go through editing? Yeah. One, two, three, four. Okay. I think that's five. Um, six, six. Everyone's going to have a go at editing. Okay. Um, Okay. Just a small comment. So, so I'm also started going to review the paper. There are a couple of comments in the bottom of the section where technically some things we are referring to. They are not, they are not correct. Like somebody referred like long lived certificates. This is, this is not a thing of today. Today, people are moving towards short lived, uh, certificates. There is crypto policies around it. Right. So we cannot recommend long live certificates. Okay. That, that cannot, that shouldn't happen. Okay. So, so I will appoint those things out in the paper, because there are a couple of technical aspects, which we should completely avoid. Right. That's not the way how things are. Yeah. I mean, I think any of any of those sort of commentaries or things we need to discuss that I think, I think as a group, maybe if we use the Slack channel a lot more over the next week or so. Um, any of the issues that, you know, a little bit sticky and it's probably one for comment and feedback, maybe raise that in the Slack. Um, and, um, yeah, I think I'm just going to go top to bottom and then do all of the, all the appropriate edits and I'll post something in the chat that, yep, I've had to go and over to someone else sort of thing. Any other bits of logistics we need to cover, because I think a couple of people are going to be going through it. I think it's a couple of days. Nope. All right, other than just real quick, would it be helpful to take summary by, or section by section and summarize what you, you as the reader thinks and saying that might be, I think I'm going to do that just for my own personal, like understanding and see whether or not there's concise recommendations. That's a good idea. I personally, I'm going to print it all out and read it like a book because, I'm just going to get blinded by looking at the screen. Yeah, Google Docs doesn't help really in that regard. So, um, okay. Cool. Cool. All right. Yeah, look massively appreciate everyone's, everyone's effort and math, a huge amount of work that's been put into this paper so far. So thank you very much everyone. And I think it's going to be really good, useful end product for the group. So thanks very much for your time and, and joining and look forward to seeing you on Slack. Then it's a couple of days. All right. Thanks very much. Thank you. Cheers. Have a good weekend. Bye.