 Hi, I'm Luke, the security engineering lead in Red Hat's office at the CTO. I would like to start off with a thank you to the CD Foundation and the organisers of this event, and to all of you attending today, whether that be virtual or in person. It's been a challenging time for us all, but no more so than for the events industry. Many thanks and kudos to them for allowing me to perform a last minute switch to a pre-recorded keynote. In a parallel universe I would be in sunny LA, alas instead I'm in the rather rainy UK having just got back from the school run. Security at the supply chain has become one of the leading conversations at the heart of information technology. We've seen a flurry of media coverage and as you all know we have the attention of everybody from tech leaders to the US president himself. But before we get into this let's do a recap to look at how we arrived at our present juncture. The past decade has seen a tidal wave of innovation and disruption to information technology. Software as we know it is eating the world and a majority of it is open source. In parallel to the incredible adoption rate of open source software we've also seen automation accelerate and disrupt the core paradigms of how we develop, build and ship software. There is an old saying no individual is an island the same now holds true for software no open source software is an island. Your average code base both open source and proprietary now depends on a wide-reaching ecosystem of open source projects in the form of what we term dependencies. Let's take Kubernetes as an example where the dependency matrix is currently at a count of 513. In fact it's likely even more since I recorded this talk. React Native's yarn dependency file currently contains 7109 lines. Now let's get this straight there are no fingers being pointed here. I develop in precisely the same way and so we should. It's what makes open source software development tick and has enabled the incredible volume of innovation we have seen within software engineering. Dependencies as we all know well are managed on behalf of the application by often bespoke packaging systems. However there is a common paradigm where different levels of attention are granted to security. I think it's fair to say that when we look into the average open source packaging system security is all too often being shoehorned into the project as a later feature when maintainers and users have already settled on a familiar workflow lacking a basic security protection system such as software signing. A good number of packaging systems have no security at all. Let's take Rust for example a language I admire greatly that introduces security as a first class element with strict enforcement of memory safety yet with all of those great guarantees we get the packaging system cargo pulls in untrusted code as they do not have a basic cryptographic signing system. We also continue to struggle with the application of identity even more so in a world of abstraction from hardware where most workloads have an ephemeral state. Now I realize I'm sounding harsh and appear to be pointing fingers here but it's a serious topic folks. It is now common that critical infrastructure systems use open source software we are talking telecommunications health banking military or vital services that we rely on to be present when we awake each morning systems that we rely on to communicate and care for ourselves and our loved ones it really is that serious this goes above mere buzzwords it penetrates deep into the heart of our society. We have a duty which is arguably a moral one to do the right thing here. I would like to take the liberty to outline a vision for a destination which I believe is very much within our grasp. The building blocks are there and some smart people have rallied around various open source projects that are grappling with the problem and writing code to try and solve these issues. I believe with these component parts and further innovations we can begin a journey towards an end-to-end secure supply chain with total provenance integrity assurance transparency non-repudiation from commit to production. It's no surprise that I would start with six door just over a year ago I wrote a simple prototype for a software supply chain transparency log named RECOR. The idea was to essentially capture build system metadata within an immutable transparency log. I could see this could alleviate some of the key concerns around supply chain attacks by providing an open audible and a means to quickly establish the blast radius of an attack such as a key compromise. Six door is now a vibrant growing community with over 90 contributors producing on average 500 pull requests in a month. In under two years we've seen the project covered in mainstream media and large tech companies come forward to tell us how they plan to use six door and contribute. Six door's call to action is software signing for the masses so that anybody can sign a container image a software bill of materials or any other artifact whether that be a blob or a tarball. We are also in the final plans of launching a free to use non-profit public good service. Six door is a great example of individuals rising above competition to solve a problem for the common good of all. In six door we plan to beat a software sign-in what let's encrypt was to HTTPS. My next project is tecton cd chains. Tecton cd chains realize his supply chain security and tecton pipelines. Chains to use this moniker allows Kubernetes users to perform the cryptographic signing of tecton build pipelines. Over the past few years chains have seen many new features such as creation of attestations and integration with project six doors recall. I believe chains will be a central part of providing machined based non-repudiation integrity verification and s-bomb generation within a cloud native environment. The update framework needs no introduction to most security folks. At its core it addresses one of the most scary horror stories that can play out in the security world key compromise. There is of course a lot more to tough most of all its ability to play out role delegation. The update framework underpins the truss route at six door and it was very exciting to bootstrap the whole process alongside the tough community. I believe in Toto will be to s-bombs what wills were to cars. By leveraging in Toto we can record provenance as artifacts and machine operations interact with the various actors that constitute a supply chain. I see spiffy inspires an integral part of machine identity and hybrid cloud federation within a supply chain. It is of course much more than that as well with its position within the realm of zero truss computing. I think the only thing they may have got wrong was coming up with a name I could say more easily. Finally we have key lime. Some of you may not be aware of project key lime. With the previous technologies we can measure artifacts as they move through a supply chain and verify the provenance but what about when it's deployed into production do we consider it out of our hands? No of course not. Key lime is able to remotely measure the digest of an artifact at execution time within the kernel. This allows us to measure provenance at runtime. This means we can capture and measure and verify the entire software development life cycle. I'm very excited to see more innovation and more projects enter this space. We also have some great minds in some amazing communities looking to solve these challenges. We have the open ssf and the cncf security and the existing work they are carrying out with the supply chain security tag. We also have the efforts of spdx to drive adoption of the s-bombs standard. I believe all of these projects get us a good way towards an end-to-end secure supply chain where we have non-repudiation, integrity verification and provenance from commit to production. So I would like to end with the following message. I implore you to come and get involved in all of this exciting work. Let's do the right thing. Let's work together and collaborate to solve what is a critical issue of our time.