 Hello, do you know if there's a link to the meeting notes for today? I believe it's actually usually just the, the white paper. Oh, paper notes. I think that's where we've essentially just been keeping all that. Okay. But when Jonathan joins, I think we'll be able to confirm. Awesome. Good afternoon. Good morning, everyone. This is vessel. Hello. Morning afternoon and evening. How are we all doing? Good so far. Good stuff. Hey, Emily, thank you for a lot of the feedback you put in that document. That's really going to help that, I think. No problem. I wanted to make sure you guys were set up for success. We need a lot of help for success. But we've got a lot of good, good data getting into that spreadsheet now. Sorry, that document now. Cool. So what I was going to suggest was kind of go through top to bottom, because now I think we've got a lot of feedback in it now and figure out and go through the scope and then work from that point down. But suddenly open to any other suggestions for the agenda. One, but I did want to pick out was, I don't know if Cole, have you been able to add your chunk in or is that still in development? Up your mute. The software factory part. Yeah. Yeah, I need probably about four more hours on that. Got it. Okay. Is there, I can have that done. I can have that done probably Monday, Monday evening. I'm going to spend a bit more time with the weekend. We have to help, right? I mean, I dumped my software factory piece in there with the recommendations, but we use that as a framework or such. Yeah, for sure. Yeah, my family's out of town this weekend. So actually I'm going to be doing a lot of work. I'll be able to get caught up on, on a lot of that stuff. Cool. Okay. So, unless there's any other suggestions, I was going to go top to the bottom and pick out different, different commentary and take it from there. Makes sense or someone got it up. Cool. Most of the commentary comes from Emily. So I don't know if she, she wants to direct her attention to something in particular or like, you know, you jumped in yesterday that not a ton of work. Well, maybe past couple of days would be better representative of, of the amount of work you've done there. So curious what your takeaways are. You left some notes and slack, but I wonder if you want to like raise that up. Yeah. So I went through the paper all the way down to the software factory because I mean, you guys have a lot of stuff in there and I only had so many but some things that came out in the paper that I thought were important to highlight and draw attention to, to make sure like as we're writing, we're being consistent. So what, one of the things that will end up happening is the paper is going to end up going to a community review, but prior to that there's this single voice narrative pass that happens and anything that we can do to help make sure that the person that's doing that single voice narrative pass has an easier time of it is going to be super beneficial and make things go much quicker. So any kind of consistency in format for like recommendations and best practices in particular, whether or not the recommendation is before the justification for why we're recommending that. Whether or not we use terminology as that we recommend to this or if we call it a best practice and this is what the best practice is. So just trying to make sure that we have consistency across the breadth of the document for what we're calling particular things. The other part is some of the acronyms that are in use. So it's generally best practice to anytime you're introducing an acronym for the first time to spell it out, then shorten it later on and typically add that back into a glossary towards the end. It makes it a lot easier for reviewers that may be unfamiliar with the concepts. So for instance, one of the sections had a recommendation of SSH over Pat, and I'm familiar with SSH, but not Pat. And I couldn't Google anything on it. So providing that initial explanation or at least the acronym breakout is always beneficial. One of the other key things was there is a lot of supply chain chatter on the internet about like how people should be doing things, what we should be doing, what we should be doing to stop it from happening, lots of personal opinions on a lot of these things. But if we're looking at some of the content that's already available, such as things from NIST or from MITRE or other organizations, it's beneficial to refer to their documentation instead of pulling the content into ours. NIST I know has a really long timeframe from when they start a draft to when they publish and any updates or changes that happen there. But if another solar winds were to happen and the recommendations within a document that we refer to were to change, we want to ensure that our document is standalone enough that we don't have to go in and rip out an entire section and rewrite it. Those were the main points. Yeah, that's awesome. I think that definitely we need that run through to make sure it confirms the same sort of standard, right? We've got five or six people contributing with totally different voices and we haven't got any standardization. So we definitely should do that as an editorial pass. But that last point you were referring to, right? And actually you made a different point about other material coming in, but effectively as we're referencing other documents, we've got the references right at the bottom. But are you suggesting like take a cut from the particular document, paraphrase the reference document and then paste the link into it at the end? Is that the... So it really depends on the content that you're working on. So there are a couple of areas where we introduce a concept that is reinforced by a separate document. And that when... And if we're introducing a concept that has some reinforcement or like for more information go here, sometimes those work better as footnotes so that the user doesn't lose track of where they are. If they see the footnote, they drop down to the section, read it and go back up and move on instead of scrolling all the way down to the bottom of the document. In other cases where there is a particular content element from an external source where we really, when I drive reinforcement home, we talk a little bit about why that thing is important. So like the NIST appendix, I think C is what it was, or appendix two, something like that. I made the reference in there, that we talk a little bit about why that particular area is important and how we expect the reader to use that or leverage that as they go through the document. That way we're not copying and pasting or paraphrasing something. That makes sense. But one of the other things that I think it might have been on Slack channel that you pulled out, which I think is really kind of poignant, is now everyone's a fan of supply chain and there's actually a reasonable amount of, now it's cool and there's lots of documents talking about it. I think we need to differentiate, what's our differentiator? Why are we writing this document now? Everyone else has written stuff. I mean, I've got my view in that basically this is kind of a best practice guide in reality. But why are we doing this? And why hasn't the document from MITRE already caught the market or the one from Atlantic Council? I think that's something we should probably discuss. I think it's because within the CNCF, we have a bunch of tools that we can recommend, right? If you're looking at these other documents, it's kind of wishy-washy about tooling. So that might be part of it, right? Maybe like some sort of a reference architecture or recommendation or gap analysis. I think we're uniquely positioned because of the community that we have to provide that holistic level of integration about how multiple CNCF projects can work together for organizations to solve this problem or at least reduce the level of impact where they to be attacked. So one of the conversations that I've had in the community and with other circles is that the landscape is massive. There's only a select amount of actual CNCF projects that are well and truly within the landscape. And they're designed to work together. But understanding the nuances about how InToto works, how you would use Notary with InToto or OPA or a Spiffy Inspire or Parsec or add another cloud-native project to that ever-growing list of awesomeness, it's confusing for a lot of people. And when they're tasked by their organizational leadership to start a supply chain working group, so how do we fix our supply chain so we don't become another SolarWinds? They're looking to the community to provide a singular document that kind of executes like a playbook and whether or not that's a high level for as an architect that I would want to read through. And then I can provide a reference implementation schema to my development team based off of that. So I have a foundational understanding. They have a foundational understanding and they have an execution path to be successful. And that's the thing that I wanted to do whilst kicking this off right at the start, right? Is that this is a best practices document that then maps directly to a best practices architecture with the CNCF tools and then as a best practices implementation using those tools that you can take. And then that's the bit. Although we kind of need those second and third bits to prove out to be truly useful, I think that's the differentiator for me because I just haven't seen that still, right? I think we're starting to arrive at... I think we're starting to arrive to who our intended audience is for good part. Those of us who are gathered here in this call are people who have time to think and question the status quo, the question supply chain today, but the industry is at large, they often have to go with, well, what's seen as the accepted solution and they follow the docs and they don't question why. The question is, is this the right tool? Is this the right framework? They just go with things. They're not questioning, well, are there better ways to do signing and verification? Are there better ways to do this other things? So, Emily, I know you put an intended audience in there. Maybe we can fill it in with a straw man or these practitioners or these operators who these people are. The other thing, I think it's a number of people joining the group for the first time. I want to make sure that everyone feels like, well, they can come up to speed, know what we're doing, and they can find a place to start themselves. There's areas we're looking for help. Blake, good to see you again. Amazing to have you here. Blake is doing some really, really cool things in his work. So good to have a practitioner and the groups. Tiffany Jordan, Tiffany is product manager for a lot of the app delivery efforts over at VMware. Gary Yang, like Gary, you've been around the group for a little bit. Been joining meetings also at VMware. So welcome, welcome on board. Good morning, guys. Let's take a good point. Do we have a kind of guidelines or north star for new folks that are interested in doing this? One of the problems that we had with the cloud native security white paper when we opened it up for community comment was either we didn't define our scope or intent clearly enough that we had a lot of feedback that we're trying to like shift what the focus of the paper was. Did we have something like that? No, I think there's a fair comment. We don't, right? And when we were trying to define that at the front, it was still a little vague. So I think maybe that is something we can add. There's, you know, this is not only the scope as number one, but number two would be the, okay, if you want to contribute, this is how. So I think that would be beneficial. I'm going to find the read me that we have for the cloud native security white paper, but I think that would be a good idea. I think that would be a good idea. I think that would be as a template for. How we do the contributions as well as what the original intent was. And maybe that could be a good jumping off point. Yeah. The one guidance is perhaps we're really biased towards action and getting things in writing. We don't want to like make this a discussion for them. But if you have, if you see something, you see it's not covered the right way, or like you feel certain ideas would be represented better, or there are some ideas that are haven't been captured, write them down. Yeah. Absolutely. No, maybe you should maybe we need somewhere actually within the paper to identify that what we were doing initially when we went through it is putting out placeholders for the sections that we've been discuss. Maybe there's some, you know, we need to mark out some of the placeholders. If you're creating a completely new section, you know, okay, we'll put it in bold like text to maybe, you know, somehow put a comment next, next with new section or such. And then fill it out maybe. Yeah. One of the things we stopped. Bring those in once, once they're like sort of fleshed out. So if you, if you see an existing section that you feel the ideas can be elaborated further, and you like, that's what you feel a client and have the most energy to work on. Jump right in there. No one is really too attached to the words we've put in place. So if you feel you want to rewrite something or you want to add on to it. That's for a game to write Jonathan. Absolutely. We need to figure out how we're going to do that. I think that's one of the questions, one of my questions in that. If we are going to suggest rewriting, and I think when we get to the point where we're going to do some fairly heavy editorial across it. We are going to need to change the document quite heavily. Probably need some form of versioning. It'd be interesting to see how people collaborated on that with the other white paper. So the way that I worked on the last one was we did an editorial. We did an editorial. We did an outline that everybody volunteered to like work a particular section and they either jotted down some mental notes that they had about what would go in there, or they provided a complete text for that particular section and quotes that way. We knew that that was kind of their final effort on it. And then once we got all of those done, we did a group review to ensure that. Like all the areas were covered. That was provided was one in scope and addressed at the target audience. And then once we kind of had an agreement on, yes, this is good. This is going to be our starting point. It's a very rough draft. We kind of like snapshot of that and then moved the content into a separate document. And that's, that's where we did our working editorial. We did a little bit more writing, moving and shifting things around that were redundant in other areas. That makes, I mean, that's kind of what we followed in that we started with those high level straw man of, you know, these are different sections. And then we separated out into, right, he's going to take that section. Cole took one, Rich Julian took one, nothing else to you took one, I took one. I think we'll probably be on that at this point. We've got chunks of it filled in. And I'm just trying to think this point adopter section is probably gone unless you find a completely new section in which in case just throw it straight in there. So there, there are a few sections that were either light on content or they were missing right at the back of the document. I think is where we're, we're hurting a little bit. Yeah. So that, that was one of them. I'm looking for where the other one is while my page finished load loading one of you want to share the screen. Yes. So this is festival. So there's one section called securing source code. That is the section. I mean, I do not know where, where we have defined the ownership of a section, but that is a section that I would want to take kind of ownership for or work collaboratively with somebody because I have few ideas around it. I work days in, I mean, this is something that I do today. So I would want to, I mean, I'll provide the complete content and how to structure this thing. And yeah, I don't know. Yeah. So Richard Julian took that one, but I definitely work with him to update it absolutely and pile in there. Right. I mean, maybe I take it back. If people think that there's still huge chunky sections that we, that they could adopt, let's go for it. I don't think there's any reason to say no. So this section here is one that. I think needed more work or more understanding about. I'm sorry. All right, hold on. Give me one second. That's a nice paper too. See if I can get it right now. It takes a lot of confidence to, to share your entire desktop. Not just the window. Oh, it's very ugly. All right. Can you see it now? There we go. Yeah. Yeah. All right. Good. Examining us bombs. So that was one of the sections that was, seemed a little bit late in how it mapped to the particular role of into the paper from a flow perspective. There was also, and I think I had a comment to that effect. We also had like this trailing section for record traceability tracking dependencies, a WASP dependency tracker, which was covered higher up. I moved a lot of things around to kind of like ease up on the flow a little bit. So they made a little bit more sense in the context of what it was we were discussing. There was one other one. So the third party risk assessment. And Vinod had a really good comments that. So I took that and I made a first pass at what recommendations would fall underneath of that. But I think that one also needs a little bit more attention. So that we're deliberate in what it is that we're intending a reader to do or follow based off of that. Thanks Emily for explaining. I don't know how detailed we should go and make it too long. Yeah, I will definitely have a read through of what you have suggested already and we will see how we can prioritize remaining items in that. All right. So if you're taking that one for sale, you're going to work on the secure, the source code one with rich Julian. Yeah. And if you guys want, I can explain that what I'm thinking about on this call as well so that I bring everybody on board that, okay, why I want to structure information in a particular way. And then you guys can give me comments, right? Okay. This is wrong. This is right. So that we move for, I mean, because I want to establish the structure first for that section and then fill in all the details for securing source code. And of course there, I'm not sure this is the right call for it or we need to establish another call or something like that. But yeah, at least that section is something that I want to go through today so that people can give comment that okay, and then I'll try to fill up every detail and of course, working with others as well. So that we know. Thanks for, thanks for taking the initiative. I think it's, it's great if we take that on. If you could give us a quick rundown of what is it that you want to discuss, we can try to discuss this right here right now, like for five minutes or so. Or if you feel like you want to start on the outline, we can, I don't know if we want to put people's names downs to know, like, oh, face on Richard and maybe someone else in this call wants to jump on that. And you want to have a breakout discussion with those people first and bring it and bring it back. Emily and I recently participated in writing a whole book over two weeks with other 15 people on a call and we'll learn a few things on, on what should be group discussions, what should be breakout discussions. But I think we like, Emily, what, what do you think we should do here? I think something like that might be beneficial. In the white paper, we use the assignment feature of Google docs to ensure that we knew who was working what section or if we, as, I believe we did that on the book as well. It made it a lot easier to understand who was working on a particular section if somebody was assigned or if it wasn't assigned. As well as if we came across a particular sentence, topic area or paragraph that we wanted to have somebody's review on just kind of like sanity check. We use that assignment feature as well. And it made it a lot easier. Let's do that. So do we want to have. Folks go through on the MD, on the less complete areas and self assign. I believe it's a comment with a plus in front of your name. Do you want to show that? Let me see if I can try it. It's been a long time. And so I've done this plus. Oh, look at that. There, I can assign that one to me. So it's really a comment with an app. Or a plus sign. You can assign it to yourself. It's based off of who you have in your address book. So. Pretty simple enough. And then when you're done, you can leave. Market is done. I think we should wait to market is done until we've gone through a review that we know, like who to, who to ask questions to if we're reviewing it and have a, have a question about a way something is worded or if we feel something could be enhanced. Makes sense. Okay. So do you want to self assign yourself to your section? That'd be great. And before we move on, I don't know, like Tiffany. Blake Marina. Do you guys have, have thoughts or comments like we don't want to like this bulldozer. We're going to do this this way. And this doesn't meet your expectations as you're coming into the call for the first time. So I think that sounds good to me. I need to take a closer read through this before, you know, signing up for anything and kind of collect my own thoughts. But Andreas, I'll probably. Reach out to you just because I'm new to. To joining sessions like this. With some of my initial feedbacks. I'm not too sure where to put it up front. Yeah. I'm just joining this for the first time. So I'm going to give it another read through. See which pieces I think I might be able to help with. And then go from there. If I recall correctly, we met at puke con over dinner with some Piago and Justin, and you were at NYU at the time. Yeah. So yeah, I'm a NYU PhD student working on tough and update security in general. So feel free to tag me on any update things if you want. And I'll just go through and see, see where it can be helpful. Our, our work's done here then. We'll leave it all to you. The expert has showed up. I wouldn't say that, but yeah, I'm happy to help where I can. Glad to have you on board. Blake. Yeah, I'll give it a read through now that it's getting a bit of bigger picture of what the plan is for this white paper. I guess maybe comments drops them just in Google. Google.com answer chat. I don't know what's the best. Yeah. I think it was reading through the software factory part, which is, it's good, but it's yeah, trying to figure out what it's mean. I think if it's a question or comment on the particular area, just highlight it and do it on the doc. If it's more a thematic comment or highlight, put it in the channel. Yeah. One of the things that's going to bring up the software and I'll quickly mention it is one of the things we do is typically standardizing build processes when possible. And also introducing more oversight to it and moving it out of individual developer control. You can't change your, your, your code inside the repo to change your build process. You have to go to something external. So that's a topic that's not showing up here. And I didn't know what a best mark that. That's a good one. Just, yeah. I guess just add that in as a, as a big comment, right? So it's like opinionated pipelines within the pipeline factory. Yeah. It's, I mean, you have an insecure pipeline, but it's more than just make a secure pipeline. It's standardized it and increase it oversight of it. Yeah. I can limit. I can sidebar with you too on that. Yeah. Cool. Yeah. Nice. Then Mike Lieberman, last time we were on the call, you had some great ideas of all the other aspects around, well, how do you, in order to trust the machines that are building your software, you should have secured this things. You saying like the fence in depth. I don't think that has quite been captured. Sure. I can put some notes in there. Right on. Very cool. I think we should make a link to the, at the top of that document to that read me as well for how to contribute. I know that it's for the cloud native security one. Maybe we copy into. Something for this or at least point to it. Cause reading through it, it makes a lot of sense, right? So I just added that link to the white paper read me. I wrote up the contributions for like assigning yourself. And I also added a reviewing area to talk about the comments that way in case anybody had another question. Come across it. They kind of know what it is to look for. So one of the bits we didn't really go through is the bits towards the bottom of the document that are still pretty often. I just wondered if we could have a look at those. Maybe you've seen, see if people were interested in adopting that right in the back, just before the production of the software artifact distribution mechanisms, the actual signing of the software artifact. Okay. So this section that I'm scrolling through here, it looks like it's got some content still being worked. And then established trust for the software factory. That's the one that Cole's currently working on. That has like four more hours of time. Is that correct? Yeah. I'm working on that in the software factory. So if somebody wants to take some of the establishing trust in the software factory, I'm happy to give that up and work with them on that. They send it up. I'll talk team with you. Okay, cool. And then verifiably reproducible builds. Yeah, I can work on that section. Okay. Make sure that you guys are self assigning. I don't have all of your email addresses yet. Production of software artifact and associated metadata. This one will likely need an introduction further up. Cause we introduced S bomb and D bombs further. Up within the paper. So if you're working on this one, I would recommend also tackling that one. And making sure that it works within the flow. John Scott. He didn't make this from, but from ion channel. I invited into the working group and he, he expressed some interest in that with his team. They've been doing a lot of work around there. So if I'm going to see if we can get him to do some of that. Yeah, that would be really good. Yeah, I can also help John on that. Yeah. And it would be great to get a review or input from Marina. Yeah, sure. I'd be happy to take a look at that. Okay. Distribution mechanism, including mech metadata. What was with thought behind this? Cause there's no. Text to help support what, what we mean. It would have been useful, right? I think this was when we were looking about how, when we go through and we've collated the in total data, how do we distribute that to other people further up the chain? Cause the reality is this is for. You know, this goes back to the. You know, the use cases, right? The reality is you're probably in the middle of the supply chain. You're not the end user. So you need to send your data and your metadata to the next person in the chain. How, how do we securely distribute that? And I think some of the ideas are on recall, maybe in that sort of area. But how we can talk about, you know, what platform one's doing to you for prior art with the iron bank, they're doing some of that distribution and metadata. A little bit. Yeah. We put some auto metadata that we, that's appropriate. It's key value and container metadata, but we have not actually established something. The standardized or something in general purpose, like, I don't know, I'd be interested there. I want to say like OCI has good answers here, OCI too, but it's not done yet. And the integration isn't ready to join. Yeah. The other thing is I'm just is expected to. I don't know if that's expected to be a build release person or is that end users? I think we need to do both. Right. But I think, I think the reality is. Yeah. We need to both. Three. There's people in the middle. There's a release approver. If you will. And then there's end users. I think. So that's actually a good question. And this is something that I struggled with throughout the document was that we had the raw suppliers. We have this software producers. And then we have the software consumers. And I started that lexicon earlier up. I didn't add the software consumers. But ultimately. If we're talking about particular areas, it might be good to highlight which persona we're referring to for a particular thing. If it is one. Yeah. Yeah, I think that's reasonable. Yeah. Yeah, I'm a software producers. I think it doesn't make sense. But also some frequently, I think individual like pipeline stages, some sub components of it. Or effectively. For this. Yeah. And then. I'm sorry. I don't want to. I thought you were done. I'm trying to figure out how to explain it better. Go ahead. For distribution. Metadata. I think there's two things we need to concern ourselves. Right. The actual metadata. And then the signatures of the hashes of the metadata. Right. So we need that transparency in the actual metadata. I think those are two separate things. It's kind of what I'm starting to realize after talking to a bunch of people. I think you're right. Yeah, some of the notary to work might actually be relevant here as well. Cause talking about how to. Yeah. Things on registries. That's exactly what I was thinking. I mentioned OCI. Yeah. The OCI work with notary to is how to stick notary signature data into OCI packages. And I think it's very general purpose. I'm loosely tracking some issues somewhere. Do you have any reference material? Yeah, I can post a couple of links. It's kind of in a few different places right now. Cool. Okay. I forget was it Cameron or someone else in the six security call had started talking about treating metadata. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. One of the things that my security call had started talking about treating metadata as. Data. Maybe that's a recommendation to make here. It's actually not a bad point. You can do a lot with metadata. Yeah. You're about to say Emily. I was thinking that. There's a lot of information that you can gather out of metadata. such as not only source and destination, but also the absence of information within the metadata that could be beneficial for a potential attacker. One of the practical challenges I think I've run into over and over is when hashing happens, so it's turning something into an idea digest. Is your metadata the inside or the outside of that signature, if you will? In other words, like a doctor digest effectively includes all of its labels because they're inside the manifest of doctor images, which means you can't change your metadata post-signature without invalidating things. I think things are, it's one of the many improvements to the Notary B2OCI stuff that after building an artifact, you can add additional metadata to it on the outside. It's just a practical detail, but it's, as you consider tools, it's one of the many problems I've frequently run into. Does that make sense? Okay, so do we have enough to move on from the distribution mechanism, like somebody volunteered to tackle this? We need an owner, definitely. I'm not close enough to that. I mean, I'd like to dive into it. It's definitely on my list, but... I did hear just to volunteer in the chat. Okay, please make sure that you all are self-assigning. Blake, and if you don't have to sign to this one, but if we could get the thoughts, you just expressed in writing, I think it'll be easier for people to digest and inform the audience. It's mostly a difficulty of actually selecting tools, understanding the limitations, yeah. Sure, that's right. Awesome. So, signing software artifacts in the context of supply chain, don't everybody jump at once? Hey, and folks, if you're not an expert in one area, a lot of what's really needed here is like asking the questions of what should the text answer here. So, if you don't know about signing software artifacts, but have questions around how should software artifacts be signed and questions that like this following that thought process, that would be really beneficial here. And then as you disengage from that section, someone else can take ownership and start to fill those out. That's gonna help us accelerate a lot of the work. Yeah, a good reference here might be the Cognitive Security White Paper. We do have some discussion content on software artifacts signing and how important it is. So, go ahead. No, no, Blake, go ahead. Yeah, sorry. Sorry, I'm really bad at talking over people. Sorry, I was gonna mention is yeah, software artifacts, this generally probably looks like standard industry code signing, I think is my expectation of our output. This is signing of artifacts delivered to users. That's one thing I wanna highlight. This is not a sign or maybe it is. You can distinguish between artifacts produced in the middle of your pipeline and your final artifact at the end. And I think that may be worth mentioning here. You have automated signatures for sure inside your system. That's what Intoto is doing. But you might have some different kind of signature at the very end like St. Otary for your signature delivered to an end user. So it may be worth mentioning that these are not always the same. One of the things I can be very confused by is how do I actually connect meaningfully cryptographically those two chains of trust together? I don't have good answers. Yeah, so it's one of the end of your software build process and then the delivery to the user might be different signature mechanisms. There may also be different keys and different thoughts. Use automated signatures and build versus delivering might be a manual process. Maybe it's not. What is the meaningfulness of automated release signatures? I don't know. That's my final thoughts. I think you're all good thinking right there. So we're assigning you to this section. Oh! I have lots of problems with it. I don't have a solution to that. I don't know how to hook the Odery. Yeah, I think I have a couple of ideas here about where you can fit in. You combine different pieces of metadata to discuss it. I'd be happy to write down some thoughts. I don't know if I could finalize them, but... Yeah, so in the past, on this section as well, I had communicated this thing before as well somewhere that first we need to identify what different software artifacts we are talking about, right? Because S-bombs are one, many fests are there, there are executables. Now, the landscape is very big, right? And many of the things are in enterprise today. They work for people. They do this thing day in and day out, right? And then some things are exploratory, like in Toto or something like that, right? They're exploratory in a sense because they are not prevalent in the enterprise, right? So we need to identify that, okay, what kind of assigning artifacts we are talking about, right? And then once we have identified those artifacts, then based on each of them, we can kind of give recommendation that, okay, this is the way we sign, okay? Or this is something that you should do or look into it, right? Because right now, I think signing of software artifacts in itself would be a very giant white paper, right? Because there are so many techniques out there, there are so many interfaces out there. There are CSPs, KSPs, PKCS 11, then there are GBG signing in Toto is there, notary is there. So I think identification of artifacts should be the first step. And then the next step should be, okay, based on each of those artifacts, this is what you do today, right? And that could be one of the, I mean, this is how we fill out this section eventually. I mean, I don't want to say much. You already have, you also have opinions, so you can help us fill that in too. Yes. I think that was a request. I just heard three folks volunteer to put down some of their thoughts for this section and do not worry about whether or not they are cohesive or comprehensive. We can always tackle that later. Sometimes the hardest part is getting the art on the canvas and then we can fix it later. Yeah, and I'm familiar with some previous work on this and I'll contribute, but I think one of the things that I've seen some folks do is they create like a merkle tree of all the signatures. No, just photo people, yeah. I do have one question that kind of triggered in my mind as we were having this upper artifact discussion is, I have not seen anywhere in the document an explanation of the components of the supply chain as they relate specifically to software. You mean them? So we've talked a little bit around the code itself that's being written whether or not you're a raw supplier, producer or consumer. We've talked about the source code. We've talked about the build itself and the pipelines. We're kind of going to talk about the distribution of that and the verification of all of those things, but we don't actually have those components described, which I think is important, especially when we need to identify what software artifacts we're talking about so that we can illustrate to the reader who may not be familiar with these concepts or at least has not been introduced to thinking about it in this abstract manner that this software artifact comes out of this particular component of a supply chain. I think if I were to release, I think adding at least an extremely simplified flow chart pipeline diagram might be meaningful at the beginning. Yeah, because it would identify the stages, the identities of people at each stage, the names you mentioned, and what artifacts or what stuff is at each stage, inputs or outputs. Yeah, which basically it's what are the inputs, one or more intermediate and an output, an extremely simple pipeline, but just showing that the existence of those things. If you saw that paper delivered on Compromised, there is a diagram in there, I believe, that's pretty close. That shows the FS station steps. Is that kind of what you're talking about? Yes and no. Mostly all these things we keep talking about are glossary, if you will, just something that includes the same exact names we're going to use throughout the paper and introduces them in a diagram. Yes, we probably could copy a diagram, I haven't seen a diagram you're mentioning, but we probably could copy it for reference, but just making sure it matches the terminology we're going to use the rest of it. Yes, it introduces like a really super high level architecture before the architecture diagram, to introduce the concepts, that makes sense. Maybe an architecture diagram is good enough too, but it's usually going to get more detailed. Yes, I would caution against copying something from another source, because you don't know necessarily what the licensing or copyright restrictions associated with those images are. If we have one. That's not one comment. I just wanted to make sure. The steps. Yeah. I just want to make sure that we're all clear. But if there is something that we could potentially use as a reference to create from, or at least use as a starting point, that would be beneficial if somebody were to link it. Another thought that elicited would be, really need to be on the reference architecture to provide a reference environment and give configuration files to stand something up. I know we talked with Andrew Martin to do something possibly supply chain ish or capture the flag for a security day. Maybe we can tap into those folks, but if someone is feeling eager to like write some code or do some configs, it would be, it would be like a great, we can say it's out of scope for now and make it a stretch goal, but if we can go beyond like a reference spot for this, it would go a long ways. Cause it's easier to demonstrate and have a playground for people rather than a bunch of warts and a document. So not just the reference implementation, but literally an environment so we can go and touch, feel, implement, deploy, hosted. Yeah. What do you think about that? We have, there's an open source training platform called hobby farm that rancher and box boat have been collaborating on. I think that might work well for something like that. It's, we can host it at like NGK or AWS, but we don't have the money to host it obviously. Yeah. I don't know if we want necessarily want to like host it and have it online, but at least give people the configuration files to bring it up in their own account. Yeah. Oh yeah, that would be good. If there's existing configuration already, I definitely reference it. But I think we've mentioned this early on, this working group of starting, what was the scope of it? I think we said also like we'd like to say, provide a function of usable reference implementation. But I think we're starting with this paper. So I think it's creeping out of scope. I don't know. That's a, I'm not leading this. It is. So I, that was actually something that I had also learned is that some of the content of the paper appears to be more expansive into a reference implementation area. And if you're doing a review and you, you feel that particular section that you're looking at has more reference implementation specific information, highlight it and tag it as reference implementation. That way when we start massaging and cleaning up the content, we can extract those into a separate document to revisit after the paper is complete. Since just an environment thing, because I'm trying to figure out. Cause the differences between that and the actual reference implementation, cause the expectation would be that that reference implementation is literally press, well, it would be great. Press a button, we instantiate the whole shoot and match. And now you can start building out your code. So it would have the configuration, the environment with it, everything that someone would need to be able to instantiate this thing. That's kind of where I think we were going initially with that reference implementation. I mean, it's a long way off, right? It's a long way off to the architecture, but, but I'm trying to see the difference between cause, you know, it would be like the almost depressed a button terraforming. It builds the whole lot for you. That's what I think. John, John, for something like that, if we just go back, I think to what I think was an earlier comment as well. We would need to make sure that the artifacts are clearly defined and any translation between the artifacts across the supply chain and stuff, but bang on, if we end up with a soccer factory on this, it's golden. Yeah. I'll pass. I had problem hearing what you were saying. You sound very far away from the microphone. Oh, sorry about that. Is that any better at all? Check, check. Slightly. So we've got about. Yes. Much better. Okay. Sorry about that. It looks like zoom just reset something from here, but no, I was just going to say that. I think that the conversation is spot on. If we just tie in what was stated earlier, if we can work on the artifacts themselves and then look at the integration of these artifacts and possibly translations. And then the sort of click button, software factory model, which starts to talk about a software supply chain that we can instantiate becomes a starting point for people to go in and they can kind of configure it for their environments. But so there's some really interesting work that's being discussed here. If we systematically take it from the, the, the concept of, first of all, just the highlight sort of the areas that we're looking at in this document, then let's get down to the artifacts. Let's look at the integration of these artifacts. And so we've got a common nomenclature and the metadata surrounding it. And now we can get into a rough, rough implementations in a factory. Yeah. So we've got about eight minutes left and we have one more section that needs assignment. Validation of signatures at deployment and runtime. Who's excited about this. I think this relates a lot to the, the previous two sections, because however we create the signatures, I think it's a huge piece of how we deploy them. So yeah. Thank you. Congratulations. Yeah, there's, there's a point that that's, that's pretty tight and sort of like, it will be largely informed by the previous sections, but I'll tell us you were the last one on the microphone. I don't know that you've yet been assigned to anything. If you could jump in there, that would be great. Yeah, so I'm fairly new to this. So what I'm planning to do is just go through and do like a review of the doc itself, but happy more than happy to contribute. Amazing. Gary, what about you? I'm happy to contribute. I'm just trying to get my bearings on where things are at with the paper. I know a few of us at VMware are thinking about a widespread of different parts in this paper. So I'm happy to work with folks on where we're sitting. Fantastic. Would it would be cool with you if we pencil you to start off in the section or you want to take more of like fine tooth comp, start to finish bottom to top. Form more ideas. Get a feel for how folks are working or. Yeah. I'm like seeing some questions and content here, possibly. I was thinking the image artifacts, I think that might be a good job. Yeah. I think that's an exciting portion mostly because. The team I'm mostly working with are kind of thinking about that space pretty closely. So I think that might be a good job. Fantastic. Is there anyone on the call that would like to work on something and hasn't yet been assigned. Okay. So I think we would like you to become a contributor to the paper. Please feel free to assign yourself a section or just start jotting down some of your notes or thoughts and opinions that you have on a particular area. Oftentimes once somebody sees something written down, it jogs their memory to add on to it and expand it. And then sooner or later you take a paper that's 20 pages and turn it into 41. So please remember to self assign using the instructions that are found at the top of the document. I do have a question associated with timelines. So originally we were targeting this for a cube con. Club native security. Release for Europe, which is may. Beginning of May. And it usually takes about a month to get through the. Community review and adjudication portion of that. So that brings us to the beginning of April. So we really need to have draft content with our initial passive review sometime in mid March. Does that seem achievable? Based off of everybody's existing priorities, schedules and other commitments. I think that's achievable. We've still got like four weeks or so to really crack on. Right. I think we've got a lot of tech content in here already. There's some of the areas we've picked out there that we can add on to it. Four weeks at a thought would be in decent shape. But it would mean, you know, we'd spend a week doing that review. Maybe two. So we really do have to, I guess, start implementing some of these content. Areas. I feel positive. Good. Do we want to shoot for next Friday to have some level of content in every one of the sections? That sounds good to me. Yeah, I can certainly make that commitment for my section. Yeah. Yep. Even the sections we were still a bit light on, right? If people can just cry for help in the, in the, the. In the Slack channel, we can dive in and assist, right? Yeah, that's a great point. If you feel you've had a wall, be it writer's block or you don't know something, just raise your hand in the Slack channel, if you feel you're not making progress. If you feel you're not making progress to jump in and. And discuss that with you to see if you can progress. Or if you're ready to tap out and move into something else. We can, we can discuss that as well. But if you feel you're not making progress, like, do let us know because we, we want to. We want, we do want to try to get. Content for all the sections. So if you know you're not making any progress, then you can just go around and get someone else there and try to make progress. I think it's good. Good stuff. Well, I think we've covered a lot today. Let's see how people. Contribute into it and. Schedules and everything, and. Let's get to it, right? I think a lot of people, certainly a couple of people I know on the call, they're going to be doing quite a bit of work over the weekend. So. People want to catch up independently and maybe jump on the call to discuss stuff. I think that's also fair game. And if you have thoughts that are better illustrated, then put in words. Draw it on the paper, take a picture. Both myself and Emily, like drawing, like illustrating things. So if you give us a sketch, we'll turn it into a diagram for you and include it in there. The question I have is, do we have any maximum number of pages? Like how much details we have to put in each section, right? Like we can be, you know, we can explain it in very detail, but if each and every section is going to explain everything in detail, the overall paper size will be, yeah, it will be too much. So do we have any thoughts on that? How much depth we have to go in each section? I think some of that, if you do get really detailed or into the weeds, I think we can do a review and determine whether or not it's too intense for that particular section or needs to be pulled out into a reference implementation for further explanation. We can do that as part of the review. Oftentimes what will end up happening is when we do that first draft content pass, it's not going to be consistent at the level of depth. And we might find some areas that need to go a little bit deeper and other areas that need to be raised up, but it's always better to have some of that information so that we can make more informed decisions when we're doing those reviews. Thanks. Cool. Makes sense. All right. Thank you very much, everyone. I think that's cool. Thank you. Thanks. Bye.