Continuous Delivery Foundation Interoperability Special Interest Group, 18 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG Interoperability Meeting - Nov 18, 2021

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

A

I all sorry for being late fighting with my computer. I hope you can hear me. Yes, I can hear you hello, cool, hi, hi, santiago, thanks a lot for joining we've been looking for.

B

A

Months like we were talking about in total in our past meetings, and I was like how can I access santiago? How can I reach to him and then finally, I asked then like can you, you know, introduce me to you and then he helped.

C

Yeah, no he's uh he's very well connected. I think he knows everybody yeah.

A

I actually watched your talk. I think that that was the first cdf event like cd continues, delivery day, 2019 yeah.

A

I think you presented in total that if I am not mistaken.

C

Yeah yeah, it feels like forever ago.

A

B

C

22 years but yeah yeah, so many.

B

Things have changed since, um but yeah happy to be here. um I hope uh some of it it's going to feel a little repetitive if you watch that talk, but I wanted to cover the essentially the.

B

Yeah all the background around each other and then uh then elaborate a little bit on what I think is relevant for the signature verbally uh group.

A

Yeah, it's, as you said, like lots of things happened last two years. I probably have forgotten your talk so.

C

B

uh Yeah and a lot of things have happened since the title, so uh a little bit is, uh I feel, exciting.

A

Sending message to our slack channel.

A

Thanks for joining.

C

Hey, how are you doing.

A

So we made noise about this presentation and like, and we normally have like- maybe up to 10 people regulars. Maybe they may join slowly. So let me try sharing my screen and we start with the uh earlier agenda topics and when we reached your presentation, san diego others will also have joined us.

A

So uh today's agenda- uh it was kept short to give more time to in total presentation from santiago, and then we can have an open conversation in total and how we can collaborate from cicd perspective.

A

So the agenda is, as usual, we started action items.

A

Then we, as I'm reminded again, we changed the meeting time recently, and this is the new time or the first meeting for new time after this summertime, like thingy happened and then, uh as you know, we started updating our sig into the road map because things have happened since we released the first version and.

B

A

We will move to into the presentation, so we can look at action items perhaps so. The first action item was on methi, who actually was one of the people who was talking about in total and shown interest, and I hope that he would be here with us because he was interested in toto.

A

I don't see him yet, but he may join on the way, and the next action item was on tracy miranda to find more about cisq software bill of materials.

A

uh I am not sure if you are engaged in that santiago already.

C

uh I am yeah, I think I remember yes, you are there as.

A

The third person, maybe yeah, ask your opinion about the cis q and then we close tracy's action item that.

B

A

And then I have an additional topic or question about cisq. I'm sure you all are aware of the formation of open ssh for launch of open ssf. Maybe you can share your opinion about open, ssf, the cisq and the broader collaboration in software supply chain, where we should be looking because things are a bit confusing.

A

C

Not perfectly understandable.

A

C

Want to take that topic.

A

No, we can just talk about it now, if you want.

C

B

So the cisq's autopilot materials project uh this actually started with uh with uh k uh king, I always confused kk uh k williams from nick yeah, uh so she- and this is almost a precursor of scam, which is, I think now the like. Microsoft uh endorsed approach to supply chain security.

B

Essentially, uh it started as a project on trying to identify tool-to-tools sort of build materials exchanges so how to have a say, a ci cd pipeline share software builder materials that can be passed forward to say a packaging infrastructure or a repository. That's going to be delivered software now. My understanding is that this was an effort that started probably around 2019 or so and since it has been essentially split and merged into other efforts.

B

So the a lot of the like s-bomb bits merged with the spds community.

B

So essentially how? How do we identify? uh What are we going to be sharing and passing forward assessment information, then? Well that essentially meant they merged the community with stdx and then how to write tooling, that can understand the small semantics and and like the tool to tool. Part of the csq was essentially moved over to what now is scam. It went a couple of hops between communities, but now it's a it's scam. uh It's that's a supply chain, integrity model. I think that's what it stands for.

B

uh I think it's on the github repo of the github organization for uh microsoft. That's the one.

A

This is the one yeah.

B

So that's uh that's, essentially the philosophical successor of what the siskiyou.

B

Yeah of what this disk you wanted to do with the tool tool. Part of it was because it's because spdx in a sense is starting to crystallize as the smoke standard, especially now that they have this uh iso.

B

I don't know the correct term is certification, but uh it's now encoded as an iso standard right, so everybody can look at it and um and have some confidence that uh people will know what you're talking about now part of what a part of the question around supply chain, integrity in general becomes well. How can you actually interpret this? How do you? How can you write policy?

B

How do you know that you're getting the right as well from the right party? That's that's something that I'll dive a little bit on the uh on my talk, um but that's that's essentially what happened to it? I wouldn't suggest looking too much there anymore. If you look actually look at the at the list of people that you had there just uh a second ago, uh for example, k williams, microsoft, uh bob martin are now like on skin.

B

My understanding is that bill. Curtis is also around all of this efforts. uh If you look at the rest of the people, most of them will be related to like ancillary projects that now essentially relate to either spdx or skin or somewhere around there.

A

Okay, that's good to know that. Let me yeah, I already captured.

A

Okay, because like when I like, like everybody, asks like when I put s-bomb to google, I get few hits, and this is one of those links and.

B

A

Is like no having some clarity about where to look? Is a good thing.

B

But yeah it is. It is a an interesting space to be in because there's a lot of movement, mostly because there's so much uh well, there's so much need for it. But at the same time, uh that makes it have a lot of energy. So two years- and I think, there's been five six different names and definitions to like the project. But it's a lot of the same people just identifying how to better leverage and grow a community.

A

So thanks out for that santiago we can tell tracy. She doesn't need to worry about rapey and I just to make sure we are recording this yeah, because I see red dots there. So.

B

A

Good yeah good info people can follow afterwards.

A

So any questions about cisq or other things, santiago, highlighted.

A

Okay, so moving on so matthew to richard kate, stewart and matthew is not with us today, so we keep it open. The next action item was on me and I considered this as done, but to speak with santiago, so that is kind of a good thing to close action items yeah the road map. So we started updating that and sent a notification to mail list and unfortunately, we haven't got uh too much input from commit, but we will continue pushing that.

A

So I keep it open for timing if it's okay with yukara, so we can work on it.

A

What was the last okay, so yeah us talking about what they are doing to end user console. If I understand correctly.

D

Yes and um we're more than welcome to do so, uh the the last end user council of the year is: is you fatty presenting so.

B

D

Is already booked, as you know, however, in the new year absolutely.

A

D

It's really just when we're ready to do so.

A

Okay, but I keep this open, so we don't forget about this afternoon here, because now we are coming to christmas. You know period and whatever so it's yeah. I keep that open cool, so we have two action items closed, which is good and then we can move to the next topic, which is the reminder on the new meeting time again like I don't know if one of the reasons why we have so few in this meeting.

A

I know this confusion, because this is the first meeting we are having after the summer time change, which always makes things kind of confusing, but yeah this way it is today, so we meet 16 utc until march or april, and then the next topic is interrupted road map.

A

So just opening that and thanks cara for going through the documentary, my comments there- and maybe we have mlm matthias here.

A

So if you could look at my proposal about what to do with events, because events was one of the items under our roadmap and now we have the sig events uh in place and see the events creation in the pipeline.

A

Maybe, as I uh recommended here, we drop that item from our roadmap as the thing we have done, and then we kind of refer to it as an item. We should keep close collaboration with sig events, so we don't completely, you know, drop it from our roadmap, but turn it to something that is driven by cig events and cb ones, and we need to keep that in mind when we work with these internal topics.

A

Yeah. That sounds.

C

Perfectly reasonable, of course, yeah cool.

A

Yes, so yeah, and obviously, since you are here that is not limited to like like please look at whatever commands, there are, and some updates and you know add other items that comes to your mind, for example, this supply chain. We have it there and then uh I mean wrote a policy driven cd as well as a candidate top item. So if you have other things in your mind, that would be good to include in the world my four discussion as well.

A

Any, I think, that's maybe santiago, since you are kind of uh looking at things from a with our site like when you think about this cicd tools like orchestration tools or the pipelines themselves, and interactions between the different phases within the pipe lines or the tools that are not traditionally seen as pipeline technologies like what is your thinking, because you mentioned few things when you are talking about cis ci sq, like uh total two exchange of s bombs among pipelines, build twos and so on.

A

Do you have anything that is obvious to you, but we might have missed when it comes to interoperability.

B

hmm Catches me a little bit of card. I wasn't trying to think for that. I actually uh well from the document that I saw something that I would like to to to hear about, or maybe see it uh describe, is um an apologies.

D

I come from a security background, so maybe.

B

I take security, like that's the zero thing to think about uh the there was a mention of policy driven, and then there was a mention of the security aspects of policy trading uh and part of a and I'll talk a little bit about it on the total talk but part of what it in total or generally, a lot of the security tools are trying to do is turning things of questions of security into questions of compliance.

B

So I am interested in hearing a little bit about uh what policy driven, ci or cde really would mean for like the compliance angle and like the security aspect or or whether they all start this exact same thing. It's just a matter of like you have a security policy that goes beyond certain aspects of security.

A

Yeah, I think that yeah, because, like okay, I think this is a topic. We start talking about around end of 2020 or something, and since we look at things from cicd, pipeline, orchestrators or tooling, perspective are how to say, maybe I shouldn't say are, but my focus or interest was more in how the interactions between different policy frameworks and orchestration tools could be achieved like open policy agent or something else coming from rancher or open rancher. I think there are different police frameworks.

A

You know, instead of talking too much about what kind of policies can be enforced, but how the interactions between policy frameworks and cicd pipelines and technologies could be simplified because, like if you think this big scheme of things like okay, you have developers doing certain things and those developers perhaps know secure coding practices, for example, or they are aware of the dependencies there, including, and they shouldn't include any outdate dependency with known vulnerabilities and how the policy frameworks or policy engines could block things from progressing further within the pipelines.

A

If an outdated dependency is identified during like gating stage in the pipeline. So that is kind of pretty like developers are familiar with those things and the other.

B

A

We were talking about was okay, the the security aspects. In some cases the developers may not be so familiar with those like this gdpr, for example.

A

Let's assume you have a feature in your product and that feature requires access to some user data, and that is actually not a lot to be done in eu, for example, because gdpr, but developers may not be aware of this, and then police framework should enable organization for such policies to be enforced depending on what region that product is rolled out and those policies could and should perhaps be entered by the people. Who knows these things, not developers per se, but the people who actually know legal aspects.

A

So that is another aspect we looked and the other aspect could perhaps be sales aspects like as a developer. I want my stuff to be in the production as fast as possible, but tomorrow is back black friday, which is fine for me, because I trust my thing works, but the sales organization may say we trust you, but don't break our stuff just before black friday, so we block any deployments to production and that could be enforced by you know, police frameworks and how those interactions would happen between the orchestration tools and the post framework.

A

So it's like not focused on security, but security is one of the things that we discussed when it comes to policy enforcement time we call or list under policy driven cd.

A

I see, but yeah security is like one of the obvious and critical aspects on policy enforcement because we all come from like cdf has members from fintech or web scale and they have different. You know uh things they consider as important like. If you look at calco, we have like yeah, we have overlapping concerns, but there are other concerns like type of industry might care, and we try to you know, collect these things together and see: okay, how this can be achieved.

C

So that doesn't make sense.

A

But yeah, then you showing interest to policy driven city means like we have some meaningful things in our uh roadmap, not focused on security itself, but actually enabling people to enforce security policies in a more simpler way. Perhaps.

B

Yeah and I I think those will become a little bit more clear of where I'm coming from once I talk.

B

Yeah is this document something I could like uh comment on? Yes,.

A

Definitely let me put the link to chat and uh I think yeah yeah.

C

Yeah I'd be happy to take a look at that.

A

Yeah, that would be great like something yeah commentary. This, like the document is like we haven't updated it really. We just we're looking what we should be updating, so this is pretty like almost same version as our current roadmap, and we are talking about what we should drop, what we should consider has done and what we should be focusing in next year and in future, so anything you can put what we value.

A

Okay, so anything from your car emil mathias about roadmap before we move to in total presentation.

D

No nothing for me.

A

Okay, okay, then stage stages of your santiago. I stopped sharing okay.

B

Let me give it a try.

B

Okay, so do you see your document? Yes, do you see my slides? Yes, okay! So now I know here. Do you see my flash take two? Yes great, fantastic, okay, so hello, I am going to be talking about in total. uh I hope I'm in the right room. This is the cdfc interpretability uh call uh I'll be talking a little bit of background first I'll, be uh sharing essentially how the problem came out to be maybe for us on the post, solarwinds era.

B

uh This is a little clearer, but I'll just try to build up into what essentially made in total exists, and then I wanted to talk a little bit about what I think it may be. The interesting bits of the whole total community for, like this interpreter really uh saying inside of the cdf, so.

B

So, let's just get started uh the way that I usually uh talk about software supply chains and then is first by starting with an actual supply chain and their compromises. How do they actually get packed? Now? A concept? That's very central- and this is probably familiar to you, because you're working the cdf, you understand that eventually leading up to a delivery is important.

B

uh Supply chains are characterized by their end product. This is what they're meant to be, for they are delivering a good or something to somebody now to just make it an easy. A quick metaphor: a product could be a tiny little bottle. It could be something that you're taking for a headache now to get this 10-0 bottle all the way to the hands of you or to a pharmacy or counter.

B

It actually went through a series of processing steps in which they uh acquired source materials, raw materials like a carcinoma or whatever, and then they started packing it and transforming it and eventually putting it into a bottle and then sealing that bottle and then shipping it over to god knows where. So you can actually go to your local pharmacy and consume your tylenol whenever you have a headache now supply chain. Compromises are something that we are very very naturally left to understand. Somebody can break into the physical supply chain and cause damage.

B

I actually picked a model of tylenol because there's a very, very gruesome, uh historical event that happened in 1980s, where somebody walked into a pharmacy opened a bunch of terminal bottles and then sneaked cyanide on them, then put them back into the counter, and I think more than a couple thousand people died, which is incredibly sad, but this is the precedent that we have to actually many of the security properties we see in a timeline model. We, for example, have lot numbers that can help us recall.

B

Whenever we see a quality product being shipped to users. We have an expiration date, so we know that we're getting. uh We are getting something fresh, so it's not stale and it still works. We also have a temper proof seal. This is an actual direct consequence of the titanal uh murderers that now we have a way of knowing that the delivery pipeline from the pharmacy all the way back into the manufacturing facility that made the titan all uh didn't, have any sort of tampering with the product we're about to consume.

B

Now, I'm going to step back and, let's think about what can happen in the very very similar way, with a with the chicago title of murders in the software and the software that we make every day. So this is a very cartoonish supply chain. uh Let's forget about the title: let's forget about all that this is essentially what we may be doing on a side project or even on a more mature pipeline in which we take some source code. We may be putting it on github or private source code hosting.

B

We may have a testing pipeline. That's branching out that essentially tells us whether they trust something. We may even include that into a build system or a more mature like a pipeline manager like techcom, so it's all abstracted out as a single step. It eventually may make it into a package repository. So that users can go and same way that they go to a pharmacy and they can consume, or can this case a dating package, so github techton debian package.

B

Now I want to be here telling you that all of this works very well and nothing bad happens. Actually, uh attackers can break into the software supply chains in many many various ways. uh This is an example that I really like bringing up. There was a hacker that broke into the version control system of the juniper firewalls and changed the random number generation uh routine in such a way that they could decrypt every single vpn traffic of this particular version of the juniper firewalls. uh This was.

D

B

In 2015. people even thought it was the nsa. It was that devastating that we were thinking about state agents causing this sort of damage, and, of course, this is not trying to uh say that uh only uh juniper gets hacked in the source code. There's been instances that date back all the way to 20 years back, causing a lot of different degrees of impact to everyday users.

B

Of course, this is not isolated. Source code. Build systems have been hacked an example that I like a lot is somebody made a malicious version of xcode that eventually infected uh angry birds and then angry birds was trying to steal people's credit cards all throughout the world. uh We didn't hear a lot about this because it was stealing chinese credit cards, so it was a bigger uh boss over there, but this is the impact right. Suddenly, a single build of angry birds makes it into every single user of embers.

B

Of course again, this is not trying to say anything about apple or anything about angry birds. It's just it happens over and over and over uh and well more programmers were good at interpolating. You wouldn't be surprised if I told you that uh that hackers also break into the packaging infrastructure. We just had this recent discovery of a npm flaw that allowed people to write packages into different registers.

D

B

The one that I like to bring up is the phpmyadmin package that was corrupted in only a mirror in the south korean era. uh The consequence of this is that the hackers were able to hack a particular population, in this case south korea. uh It doesn't take a lot of imagination to to think that this is probably the north korean government or any uh any of the like political enemies of south korea trying to hack into the machines of the south korean government.

B

This, for example, happened with operation aurora, where people were targeting high profile uh high profile companies by targeting other high profile companies, and, of course again, this is not trying to say uh this is uh exclusive to the south korean example. Rather, it just happens over and over again and part of the reason why I was asking about compliance and security is because sometimes these things are very very intertwined.

B

uh You may have things that are not on the modification pipeline say. In this case I drew the testing and essentially a compliance step as a fan out something that doesn't uh eventually make it into the product itself. But we start we, we introduce questions about compliance, uh an example that I like to bring up, and I don't know what my screen is doing, putting it all the way there, uh but back then, and when windows 7 was still a thing and the windows did any tpms.

B

It so happened that windows 7 uh pushed out an update that breaked everybody's computers, everybody that installed that update their computer was fully bricked. uh People thought that it was actually an attack, the consequence of malware. Then microsoft did a very thorough investigation internally trying to identify what exactly will happen, and it just happened that whoever was supposed to be testing the patch for windows.

B

7 did not test the patch for windows, 7., uh something about compliance, becomes a highly uh highly impactful, essentially, software supply chain uh effect, and again this is not to say that this only happens to windows. uh This has happened to uh and it happens widely in the open source world. I won't be surprised if it's happening to anybody out there in the industry. This is partly why we're trying to answer these questions now, so stopping for a bit uh something that seemed a little bit too simplistic.

B

I already showed you more than 30 different types of compromises on source code, build pipelines, packaging testing. I took delivery of drawing what is eight different devils in which essentially things can go wrong, and I would wager that in six out of those eight, the system becomes fully compromised. If anybody breaks into this so well, uh how do we fix this? uh Actually, let's yeah, I I jumped a little bit. uh This is, of course the stakes are high.

B

We have uh now now it's uh two years old, uh but uh back then they're on, like early 2020 before the election, people were starting to ask themselves what are the consequences of the software supply chain in the upcoming presidential election, and this is not something about where you get the capacitors from this is something about. Where do you get the software in where well, democracy is starting to be at stake and, of course, well not to say uh solarwinds, the largest and most sophisticated cyber attacking ever according to bradsmith.

B

And well, it's making a nature states in like uh essentially highly uh highly sensitive situations to reconsider the cyber security. That's the stakes of software supply chains. uh It's even got to the point that people are starting to think. Maybe we cannot build systems to solve the problem, but rather just turning to into the insurers to assume the damage and try to recover from a loss.

B

Now, let's, uh let's think as technologies, and let's try to fix this. Essentially what we need to protect any chain is to first make strong links and then link them together. It is really not much more complicated than that, so we know that there's ways to build strong links. This is probably something that you're familiar with. You can use many cryptographic uh techniques to protect the version control system. This is actual work that I did uh 15 to protect version control systems you can sign commits you can sign push certificates.

B

You can do any sorts of different elegant ways to protect version control systems from hackers.

B

You know that you can use uh different mechanisms, say a techno pipeline manager to authenticate the workers to do uh to make sure that everything is done correctly and that no hackers brought into the version into the build system and well, you can do the same in the packaging. You can do the same in the ci.

B

So looking back and the image with uh eight little devils, we, we can't remove the devils that are standing on the on the step itself in the in.

D

B

Themselves, but uh we still have a question about well: how do we know that things are passed to each other properly and that there's compliance so that there's a reasonable exchange of information between each other so that we know that things were followed through the letter and that everybody is behaving properly within the supply chain?

B

This again, it's nothing new! It's a it's a it's something! That's very evocative, but that's why we hear uh builds on materials right uh when you get pieces from, uh I don't know from a vendor to build a car, then you make sure that they give you the right pieces and that the vendor didn't do anything wrong, and this is exactly what this is all about.

B

So what we're going to be doing with in total, then is to leverage this existing strong links, mechanism and then building a chain building an actual change.

B

So, to do that, we are going to sorry for uh the academic uh diversion we're going to build a system that allows us to have compromised resilience, uh essentially assume that some steps will be compromised and then we're going to build a way to connect everything together by creating an all-encompassing system, an overlay that allows us to describe the whole supply chain, not only individual steps and to top the challenge we want to make it expressive enough, so that we can describe every single supply chain, and I think this is this- is going to be interesting, especially for sick interoperability in which well, we really want to make everything collaborate with each other in meaningful ways.

B

So how do we do this? To? The first thing that we need to do is to identify the workers in a supply chain. We know that bob will be doing the code, carl will be doing. The building, aaron will be doing the packaging and they will be doing the testing.

B

We want golf to be the only one that's doing, building or bob and his friends and carol to be the only one. That's doing the building. uh Sorry bob. The coding carl the building published for that.

B

So that say, if we know that data is compromised, we have assurance that well, the critical path doesn't compromise itself and that we can still trust the final product. We can also recover from a compromise. uh By doing this sort of role separation, we can say: hey, you know what they you're not doing things right: let's, uh let's bring ad on board, let's start trusting ada, and then we recover from a partially compromised scenario to a fully trusted supply chain. Again, we also want to build a system. That's too agnostic and again.

B

I think this is very important uh for uh for sig interoperability, because we know that while a lot of people like to use tekton, there's another cdf project, that's also very widely popular, that's jenkins, and we want to make sure that we can still describe these two supply chains between each other and that we can still use the same semantics to describe the operations done by both of them, so that the if we were able to ever to change a tool or just describe a different supply chain, we can use the same code.

B

Build package semantics or anything really that we want to do. This- allows us to build an all-encompassing system um to, and I'm going to use a very silly metaphor, but uh just to just drag the point home. uh We know that the supply chains of today are not supply chains of tomorrow. They may have different steps. Different operations done into that. So imagine that tomorrow the linux foundation came up with a new soft foundation.

B

That's the authenticated keystroke foundation and it's launched so that every single developer is authenticating every single keystroke on the source code that they're building. Well, we want to express ways to know that this is actually what's uh what's supposed to happen.

B

We want to be able to make sure that the authenticated, keystroke foundation can communicate information to the source code and eventually communicate information to a build system, and imagine that somebody finds a way to essentially run over the whole authenticated keystroke foundation and comes up with a hypno attack so that this comes out in a new vice article in 2022, so that people are tricked into writing malicious uh malicious code and that, in order to protect that, we came up with ways to measure people's awful ways and make sure that they're not hypnotized in the right code.

B

Now where we want to be able to communicate that information forward as well, so that we know that people's intentions were right, that our keystrokes were correctly authenticated and that they were passed into the source code properly to the building package and so on and so forth.

B

So by doing this, by having this sort of expressive dual diagnostic mechanism, we are able to represent all of the supply chains that uh that are out there. Not only the ones that are cloud native, not only the ones that are fully open source projects. But rather everything out there, uh this is part of a challenge that we face. That's in total team because we know that deviant packaging looks very different.

B

It actually looks like a funny diverging graph as compared to django or as compared to tails, which is an operating system image or the arch linux, iso, or projects that only deliver source code like gcc, but they still make testing on their source code or the data.pipeline.

D

That I'll talk a.

B

Little bit a little bit in a little bit uh in which they're using uh hardware tokens to authenticate uh every single line of code that the developers on the new york times, building where the data that our offices are uh and eventually make it to to say, I think twitter is still using datadog the twitter infrastructure.

B

So you know that uh there is a tamper-proof paper trail from the developers all the way to the infrastructure of all of these very, very solid for uh projects.

B

So I'm going to explain a little bit of the architecture um of how can we achieve this? This is going to perhaps not be very surprising to everybody. The idea is very simple. The what we want to do is to verifiably define the steps on software supply chain say this is what we expect to happen uh earlier in the in the meeting. We were talking about gdpr. Well, if somebody needs to check for gdpr compliance, we want to say hey. There needs to be a step on the supply chain for gdpr compliance checks.

B

Then we want to verifiably define the authorized factors. We know that certain actors are expected to perform certain operations and we want them to do that operation and nobody else, uh and then we want to provide a tight binding of the artifacts as they flow through the chain. This is the built-in chain, part of the software supply chain.

B

To do this, we first created uh a type of policy, and this this can actually be transpiled throughout the project, but the basic idea is that inside of this policy, you say exactly those things. These are the steps that need to happen. These are the people that need to carry those steps.

B

This is the things that they're consuming and producing, and this is how it all connects to each other. uh With this, then, you can start providing this artifact flow integrity property that that is what we're trying to achieve on the software supply chain security world.

B

We also allow project owners to authenticate this policy that so that you know that the policy comes from an authorized party say I don't know a bdfl on a project or a compliance manager inside of your company. They can create policies and then make sure that they're followed through the letter.

B

Now this policy describes what needs to happen, so the other bit that we need to use is a a way to track what happened so that we know that what happened is what needed to happen. uh This other bit is done with a type of metadata, complete link aptly named for the supply chain.

A

B

And there's many tools, but perhaps the one that's the most agnostic is called in total wrong, you're, essentially running total and tell it hey, do this thing and just make sure you track everything that happened and eventually create this little? uh I don't know my pointer is visible with this little attestation, so that you know well. Whoever was in charge of developing source code is able to attest in a in total link to what they did now at the end, then it becomes an easy question.

B

Do I have uh do I have the final product say my bottle of time law or my italian package? Do I have a policy that tells me how this should have been made. uh Imagine this like a again a description of all of the supply chain and eventually do I have enough evidence to to be sure that this was actually done, how it was meant to be done, and if I have all of those things, then I can actually trust the product.

B

uh If you are like into the academic bits of this, this becomes a question of graphics or morphism. Essentially, essentially, you treat the graph out of your policy and then you try to match uh that graph with uh with the graph that comes from uh from the app stations.

B

Now I'm going to just quickly close over the security analysis, the basic idea is well, you are able to say, I trust, whoever told me this policy was performed and then there's nothing. That's uh either knocked on or don't that shouldn't have been done. Then I know that the individuals that carry out their operations should be trusted or should be, uh should be the ones that should be carrying out these operations, and then I know that nothing has been tampered in the way.

B

Then I know that eventually, source code that went into my package is the one. That's that's right now, something that makes me very happy as an academic, because it's not something.

D

B

We see a lot is that we are actually very, very well adopted, widespread uh in different places. uh Most of it is through datadog datadoctor integration in which, uh essentially, they authenticate every single change or every single uh plugin that they include into their agent by using intel. This is what I was describing just a second ago. They have a very, very cool blog post about it, but essentially their ci cd system plus their developers.

B

They all create that stations of what they're doing and then the agent before installing any uh any integration, any plug-in they go back and actually walk back the deeper trail, all the way to the developers that wrote the code. So they know that every single thing that they got comes from the right source code was written by developers in the datadog office, building uh using hardware tokens to authenticate the reaction.

B

Now. This is all the background about zentoto essentially- and I wanted to contextualize this, because uh we want to also be able to provide this uh information in a way that's easier to write policy around.

B

So what we're trying to get at to in the in total community right now is to define what we call the lingua franca of in total operations. Essentially what you, what is done in the supply chain, and how is it usually done- and this is something we're trying to gather input from different communities- say like the computer, integration, uh community or the source code uh or like um or say the like, the service mesh community right. uh The way that it used to be is that in total links were essentially for main fields.

B

They were materials, things that were used products, things that were produced environment where the thing was made and by products things that you don't want people to use right things that you did that created, but you don't want them to be used or passed forward uh now. This is this is a little problematic. We found out after uh after a little bit of time, because sometimes there's a little bit of overlap between these things and also because it is not entirely clear to people what is a material sometimes and what is an environment, for example.

B

Sometimes an environment can be a tool that you're using or it can be thought of as a material or a product could be something. That's also changing the environment.

B

So even though this allowed us a very like agnostic, very uh opaque way of describing your operations and writing policy around it, the honors fell on the people that were verifying and driving agreement between the ones that were creating the stations. The internal links and the ones that were verifying them became became harder to do so. What we're trying to or what we're trying to do now is to provide a more like expressive granularity. I called it uh so. Suppliers, people that generate evidence can uh allow verifiers to know how to verify the evidence better.

B

So suppliers can know how to properly fill all fields. They know what a material actually is and verifiers can know what to expect in the materials field, and then suppliers can also extend say, say: they're using tecton and tecton has its own. Like specific semantics that are extending the the regular ci operations, then you may want to append that to the existing uh in total links, rather than just uh letting people figure it out.

B

uh This also allows verifiers to say, uh write common policies, for example we're talking about ddpr, then you could say: hey, I'm expecting a a link that represents a gdpr check over my infrastructure or verifiers can also know hey. This is a like a ci uh type. I maybe don't. I may not know all of techno specifics, but I can verify it as a ci as a like arc archetype to do this. This is something that actually was very inspired by jeff's taps and pets, and so on.

B

uh We defined this in total enhancements uh ips um in particular the one that I think is of interest for sigma interval. Reality is the i6 which is essentially describing this way of creating uh generalized link formats uh right now. What we have is the ci providence, slash, salsa, providence type. This is actually something that can be used today with tech time chains. This is something you can enable in tech on it starts creating a ci prominence type.

B

You can also uh you can also create internal app stations for speedpack documents to essentially sign them, or you can fall back into the classic intelli link.

B

Part of the goal of this is to allow again tools that are creating evidence of what they did being able to be consumed by tools further down the line or consumers to know how. How does this evidence look, and how can I actually write policy around it again?.

D

B

The focus of this is to, rather than dictate how this should look like is to drive it on a more community-based approach. You want to invite people from different communities to say hey. This is what my tool loss.

B

Does it follow into any of the buckets that exist, or can I create my own bucket for them and ideally, we'll then create these common archetypes for different types of things that you can do in the in the supply chain, but you can also transfer this information back into your community, so this is exactly what I think happened uh with a change proponents type in which they said hey. This is what change does that would discuss things around and they were like hey. This looks like what we want to do now.

B

We are encoding how this is done in the changed world to create any total provenance type as a as a tip, and while this is very useful because then verifiers say kyberno or cosine or other six or tools can go and say hey, I am expecting a a ci at the station from text and change and I'm going to verify it to make sure that that individual step was done to the letter and I can stitch it together with everything around its own supply chain elements.

B

I wanted to keep some time for discussion and I think running out of time. This is my information.

B

If you want to reach out to me and yeah, I hope this was useful and more than happy to feel some questions down.

A

Oh, I have few questions I actually. I think I followed examples in your repo. I think this ali spoke. If I remember correctly, you had some example code and some I don't exactly remember how was it, but I followed this, which is great, but then I started googling. How can I you know, try this out more easily, because you know we doing things.

A

Samsung is one thing to learn how it works and getting things working in our software flows or pipelines is something else, and then I found the since you talked about tecton now, but I was looking for some other projects which in total is like.

A

Jenkins plugging which you wrote few years ago, yeah uh it is do a.

B

Little bit of an update, I'll say that yeah. That was my question mike. Yes, uh that's actually uh something that we are looking at in the near term. uh Let me pull up on, so we actually rewrote the java uh implementation to include this. uh The same as a technical predicate. This was merged very very very recently. uh It was a lot of work by this engineer at google uh yeah. So this is.

B

This is the one so now this this is on the java library and the jenkins plugin itself is an integration of this java library. It essentially wraps it around. uh We uh now that this is merged, and again this was merged like yeah 15 days ago. uh We want to start uh updating the jenkins plugin uh to allow you to create this sort of provenance.

B

uh My hope is to again have this party between say, detect and change project and junkies plugins, so that both of them can create the same type of meta information.

B

They may enrich it with like their own semantics, but the overlay uh should be as common as possible so that you can write policy uh around it uh in an agnostic way.

A

Yeah, because exactly the keyword like, I think you mentioned this agnostic way in during your presentation, is that because, like I want to, you know, give it a try and compare how this intertw behaves or what you get when you run something on tecton and when you run something on jenkins and like find similarities, because like in that, we are talking about like how the you know. The pipeline technologies we use could interact with frameworks like in total and.

B

A

Could be you know uh how to say, let's say you want to change your orchestra from a to b and but you don't want to lose everything you have done with your right tool a when you move to tool b so as little disruptive as possible because, like in the end, you are orchestration some activities and what orchestrates? That is. Yes, it is important, but what is important is the activity itself like running in total.

B

Right yeah, no, I I that is my goal. I I will say it's uh sometimes a little hard when it comes to, and this is why we have this cape hatch, because you will see that sometimes tecton has its. uh I don't know its own semantic right like we have this thing that nobody else does.

B

This is like our differentiator well uh answer everything that, like that all tools need to answer and then add your own like special special stuff, but if, if it is common, it's almost like a like there's a super class for all of them, and if they all uh talk that language, then you can.

B

You should be uh not too troubled to change between them, and that is again my goal and that's what what we're trying to do in the community to have this uh accession? I should change the paint once uh there's a station, a repository in which essentially, people can define different types of statements or different types. For again, this provenance type would be very good for ci cd systems and all of them could could produce essentially the same type.

B

That is what I'm trying to to field to allow different projects to have uh yeah. Essentially this single source of truth. So they know how to communicate information to down streams about what they're doing uh another project that you may be interested into. Looking at, it's uh builder be it's. uh This is more on the open source community. But uh if you go to say this is rebuilder d rebuilding all of the oxygen x packages- uh oh wait! This is not updated. uh This is another instance of the same.

B

uh You can actually click on the little total link and you get this provenance predicate uh again. This is important because then you may want to have agreement not only with this uh ci cd pipeline managers, but with other projects that are like more on the open source, community, linux, distro, world style, uh stuff things, and this becomes particularly important when you're starting to see that say these things are built and then stick into a darker container that then used by a tecton chains.

B

Payload right, you want to be able to walk all the way down and say: hey uh are all of these dependencies built in a way that matches my policy.

B

I don't know if you saw uh that's why my backup's live is it's insecure troubles all the way down, because you need to continue going down.

A

I have one more question, but I want to give chance to others to ask as well if they have any.

A

Okay, so my question is about something we discussed when you were talking about the cisq like an spdx, you know spdx becoming an iso standard in september, or something made things interesting, and some communities already started, adopting spdx to generate s-bombs and in perfect world everybody generates spawns as part of their release process and they dump them next to the other artifacts they are producing like shazams or actual tables or whatever, and that's I think that will like more common. This will hopefully adopt that making life of all of us better.

A

So what is your opinion about something like in total attestation like how you do this on arch by the way? Thanks for ash, I am like I'm fan of arch linux, but what is your thoughts on like something like this becoming mainstream and all the communities doing this like built into their way of working like it's not like, adding it after the fact, but building that right from the very beginning.

B

Right, so that is, that is a big challenge and that that is also why I see in total and spdx to be complementary.

B

uh The way that I that I describe them is uh with general the generalism notion is you get an artifact and then you just start digging and see what you find about it, uh whereas with internal you just essentially carry forward information until somebody makes a determination about whether about what it is.

B

So it's almost like a disaggregated s-bond now in an ideal world, I think that the total information would be useful for producing an s-bomb at the point of release. You could say: hey. I have all of this evidence, I'm going to like start digging about it and eventually producing this one that somebody can easily determine things about.

B

uh My vision is that you will see a mix and match of both cases depending on your use, and my hope is that you will actually be able to also secure spdx documents within total as well, so that you can aggregate those pdx documents in the same way that you aggregate different pieces of evidence, uh because in reality- and I mean this happens in arts right- not everybody does everything and there is different, different sorts of sources of truth, but I, for example, maintain the docker image and the people that maintain the docker image.

B

They are a team of people that can attest for the state of the docker image, but we heavily depend on other packages for other parts of the distro right.

B

This is also why I want to to allow for people to represent different operations within a chain rather than having this sort of big stamp process, which you finally roll out in s bomb again. I think both of them have their value and I think they can help each other very well. uh I don't know if I went on a tangent.

A

Yeah, I I I think this I think you you respond my question pretty well, so I I I I really like.

A

I have lots of questions and I will probably have even more, but I don't want to take you more of your time, so would that be okay? We like reach out to you on slack or something like when we, you know continue our discussions with the music or we do our own. You know continue trying in total and see how this fits into our workflows. So I hope you don't mind us.

A

It's coming to your way, randomly no.

B

I I would love it, and actually I feel that uh particularly the projects in the cdf are perhaps the like. If we manage those we'll be in a way better position like supply, chain security, wise, then, if we manage anything else, uh perhaps the next big thing is a github or something like that adopting it. But uh but I I see this, and this is why I wrote the plot the james's plugin back then I was like well, people are using jet games and a way to generate evidence about this very very mission.

B

Critical step is, uh is so important.

A

B

Happy to help and happy to also uh figure out ways to make things happen in a more seamless way, also like point uh people in the total community uh to like sig interpretability here at the cef or or just find find strategies to make uh make all of this happen.

B

I think we're it's a good time to give this away.

A

So we are two minutes over time. So uh thanks us for this scented, we really appreciate it and yeah. We definitely continue talking and we'll definitely disturb you coming days, weeks months and happy happy to help with that again, thanks, cara, mathias and emil who left for joining and talk to you next time have a nice rest of day. Thank you very much. Thank.

D

A

A