 Welcome. So last session of the day, I guess. And let us start that session with a shockingly high number. So apparently, 75% of container images that run in production have high or critical vulnerabilities. Furthermore, 85% of these container images have a vulnerability for which a patch or fix actually exists, or at least this is what the numbers from a system report show linked to the report on the slides. So the report is a bit of a year old, but I kind of assume the numbers haven't changed dramatically at the instant. And now you ask yourself, these numbers seem high. What can we do about it? Is there something we can do against this? It's certainly not the lack of great tools. There are a lot of great tools to scan container images for vulnerabilities and other things. So it's maybe also something that we just have to run them. Now, we think we actually have one idea where we can actually make it a little bit easier to run off those tools for you automatically so that you don't have to think about them too much. So today we would like to talk about how you can nicely integrate tools like security, vulnerability, compliance tools into your build process if you happen to have a ship right around. Now, this won't obviously fix the numbers that I just showed you in production, but at least our goal should be we shouldn't increase those numbers. Like, if you build something new, let's make sure that it doesn't have any vulnerabilities right from the start, right? So let's not make this number even bigger. So this is Karen. Hi, Matthias. We work at IBM. We work on a project that's called Code Engine. It's a serverless platform as a service, which has build capabilities. You give us the source code, we will build it. And in this capacity, we work on the CDF project ship right and in cluster source to container image build framework. Now, we are happy to share some of the latest changes we did in ship right that go around how we can integrate more tooling into the build process to help you with things like the scanning or other compliance requirements you might have. One example could be, for instance, software built from materials, S-bombs, how can you create them as part of your build flow automatically without having to do anything about it? Well, the idea is to make your life easier and that you don't have to think about those things, unless, of course, the tools find something in your image. And then, of course, you have to think about it and have to fix it. Now, for those of you who have not heard or used ship right before, like I said, it's an in cluster source to container image build framework. With other words, if you have to happen a Kubernetes cluster laying around and you use that for your project, ship right is one option you can use to put it into your Kubernetes cluster and do the builds for you in that cluster. For instance, application builds or container images for run to completion workloads. Now, ship right is an incubation project in CDF since 2021. So fairly new, but we've been around. We have community meetings every Monday. Everybody's happy, can join. We're happy to have new contributors. Details are on shipright.io. Links are also in the slides. So please join us. Let's talk about ideas. Now, we are currently on our slow but steady march towards better API status. It shouldn't scare you that we are from alpha to better. Actually, ship right runs in IBM Code Engine for three years now. So it's doing its job diligently and perfectly fine since three years with thousands of builds per day. It's just that the API, we still think we want to keep the door open for things to change the API. Because the API is, we really wanted to keep it simple, not too opinionated, but also powerful enough. And as you might guess, that's not that easy. So we wanted to keep the door open for iterations on the API. But in terms of its core capability, it actually really works wonderful for us, which actually brings us to today's talk. So we want to talk about one of the things we changed recently and what we think could be quite useful for everybody. And before we go into that, we actually want to speak about some of the inner workings because it makes it easier later in the demos to know the terms and what does what. So with that, let's head into some of the inner workings. The microphone. So in ship right, there are a few core concepts which we would like to explain first. So these are builds, build strategies, and build run. So build is what you want us to build for you. So here you can specify where we can get the source code from. Or you can also provide the source code from your local machine. The build strategy is how you want us to build it. So here you can build strategies somewhat comparable to GitHub action definitions or some other CI tool where you define the steps. And in our build strategies, there are steps to steps to which you can define how you want to build your image. And then there is a build run. So build run is the actual build that runs. Or you can say that it is the actual execution of those steps in the cluster. So with regards to the build strategy, with regards to the build strategies, with regards to the build strategy, these are usually maintained and rolled out in the cluster by the strategy creators. And we do provide some sample build strategies in the sample section in our shipwright repo. So for example, we have sample build strategy which shows you how you can integrate buildkit to build Dockerfile-based applications. And then there is we can also integrate buildpacks with shipwright where ship, if you don't know buildpacks, buildpacks is basically it detects the programming language from your source code. And it builds it and it pushes to the target registry. And there are other tools such as Kaniko, KO, Builder. So the point is you can integrate a variety of different tools with shipwright. So under the cover of shipwright, there is tacked on. So we use it to automatically create the execution plan of steps, both system-defined boilerplate steps and the steps defined by the strategy creator. You must know that some common elements are provided by the shipwright itself. For example, the strategy creator does not have to deal with how he will obtain the source code from Git or from other means. So shipwright does that for you. So yeah, our main goal is shipwright is convenience, abstraction of complexity, and usage of standards, and proven tools, and processes. So the problem is the way we use buildpack for now, what it does is it eventually pushes the image to the target registry. But it sounds very nice in the beginning, but the problem is it makes it very difficult or somewhat impossible to extend the build process. So for example, if we want to run the vulnerability scan on an image, and we eventually, it would be really nice if there is a possibility that we want to abort the build altogether and not to push the image to the container registry if it has critical vulnerabilities. So there are other use cases also where this default behavior for now is counter predictive. So these use cases might include image signing, vulnerability scanning, metadata post-processing, validation checks, et cetera. So this led to the initiative we mainly want to talk about today. We want to break the build strategy into two flavors. So the left one here, here you can see the orange boxes basically represents those steps which are introduced by the shipwright. So these kind of will be maintained and handled by the shipwright. And the blue boxes are those steps which are from the strategy itself. And these are usually created by the strategy creator. And on the left-hand side, this is our current behavior. So here, we can integrate different tools, as I told you. We can integrate buildkit, buildpacks, canico. So here you can integrate. And then your strategy will eventually push the image for you. So that is why we call it as strategy managed push, very creative. So on the other hand, so there is now. We are working on it, and we have done a few examples for this. So on the other hand side, there is a possibility to tell the strategy that shipwright is supposed to do the push. So on the left side, it was strategy creator. He has to define who will do the push. But here, shipwright will actually do the push for you. He will be able to do the push for you. So here, on the right side, we do inject the steps which will get the source code. And it will be managed by shipwright. And then these are the steps which we will get from the strategy itself. And then shipwright will do the push for you. So this enable us two features and two areas of features and functionality. So there is possibility for strategy writers to add more steps into the strategy definition. That happened prior to the push. So eventually, Tecton will take care. Everything happens in the due order. And at the end, shipwright will add the final step for the pushing. And there is also possibility for us in shipwright to put additional logic into this push step at the very end. And we have two examples. Like we will show you two examples today. So we'll talk about two things, software build-off materials, that is S-bombs, and vulnerability scanning. So yeah, Matthias will cover the demos for those two examples. All right, so we will do just two demos that kind of show what we think would make sense if we now have the capability kind of to break up what you just saw. Like coming back to the LEGO pieces, right? Like Buildkit is such a LEGO piece for us. Or Paquito Buildpacks or KO Builder, you name it. And sometimes it's easy to put them together. Sometimes it's missing. So we're kind of hoping to solve this one here or make it a little bit easier for some of the use cases. So the two demos are S-bombs and vulnerability scans. Now it's just two demos for the sake of having two demonstrations so that we don't mix too much. We kind of think that in the real life, people would just choose opt in and opt out what feature they want. So I guess most of the time it kind of makes sense to have the full package and actually do vulnerability scan and also the creation of the S-bombs. But you can use either of them or none of them depending on your use cases. With each of these demonstrations, we will create a build. So again, what you want to build. And then just trigger a build run so that we have one example. Now what you see here is just on the bottom, you're not supposed to read it. It's just the K9S output of the cluster just to give you an indication. Something is actually happening. Tecton is doing its magic, spinning up a pod, putting in everything. Images are being loaded. On the top left, we are using the shipwright CLI to create a build and a build run. And then on the top right, just peek look into the container registry to see there's actually nothing there yet. And if everything goes well, then we hopefully have an image in the container registry at the end. Now what we want here is, again, breaking up the build. We just don't want to, in this case, it's a sample go application with a Docker file. And up until now, how shipwright worked with the build kit, build strategy is you give it a source code and a Docker file. It will figure it out. It will build it. It will push it ready. But now we kind of modified the build strategy in a way to say, build kit, you do your magic with the Docker file and the build. But just don't push it. Create a nice OCI raw directory on the file system and store the raw data there, because we actually want to do some post-processing on it. Now this is happening as I speak. And eventually, you see on the top right that the image will show up. So what's happening is once the build step is done, we go into our post-processing and shipwright. We call just whatever tool makes sense in this demonstration, just an implementation detail here. We use SIFT to work on that directory, let it create an S-bomb in whatever form it you want. And this output is then captured, put into an OCI file attached to the registry to the image and then pushed into the OCI registry. And then eventually, just that you can see that it actually happened, I use Crane to just as is, pull it out of the registry to give an indication where the build run actually created here. Now, again, the idea is, and especially me coming from a bit of a Cloud Foundry background, you always have to be careful with opinionated systems. So we want to keep it flexible enough so that it makes sense for you. SIFT is just an example here. We know there are build tools that actually create the S-bombs as part of the build process anyway. KO is such a great example that creates the S-bomb automatically. So we also envision that depending on, again, what Lego pieces you put together, some will end up creating the S-bomb themselves and we will just post-process them. If you happen to have a build strategy that uses a tool that doesn't create an S-bomb, then at least you have the possibility to configure, please create one automatically for us so that we can use it more non-at-all if you just don't need that for your build. And again, the core idea we have here is since we do the build anyway and we have all the pieces of information in the pod anyway, best is to actually do the post-processing right there and then just push the image already around. So that would be basically to automatically rate S-bombs with whatever strategy you want. The second demonstration, again, very, very similar. We create a build and then later a build run. Again, just for the sake of the demonstration, shipwright has the capability to not have these two steps. You can also do it in one step, but I didn't want to overload the demonstration too much here. Now we fake the build a little bit because we actually need an image for the demo that has vulnerabilities. And it took us actually a bit of time to find an image that works all the time with vulnerabilities. But we found one in the Python namespace. So the build is just taking the image, again, kind of a build. The output is, again, not a container image that you can then push, but again, just raw OCI on the build.parts file system. So at some point, you will see that the build step is done and then gives back control to us in the POST processing. And in the POST processing, we use, in this case, Trevi, again, implementation-specific. You can, technically speaking, configure whatever tool that makes sense, or you use, or you're familiar with, to do vulnerability scanning. We said there are a lot of tools out there. So what happens here is Trevi has executed on the build.parts file system with the OCI. And what is important, or what we find important, is the image is not pushed. So it's still only in your build system. We find a couple of vulnerabilities. And what we now do is the build run, as we said, is the execution of a build. And the nice thing about the build run is once it's done, it will actually be enriched with information from the actual build. One example could be, for instance, the digest that was created, or sizes, and so on. And these status fields are now enriched with the vulnerabilities that were found in the respective image. Now, again, multiple use cases. Of course, there's the option that you just omit the whole vulnerability scan, like the behavior we had before, just run it through and push whatever you want. Another idea is you just leave it with the details you have of the build run. So the build run actually, at the end, contains the status. It's completed in three minutes. And by the way, these are the vulnerabilities I found in the image that I just created for you. And then it's about the rounding framework or tooling you have, whether you want to read those information and process them further. Or what we kind of think makes the most sense is that you configure your build in a way to say just the boarded. Like, if you find a vulnerability during the build, just a boarded right there. And the great thing is the image isn't pushed to the OCI registry already. Because, I mean, it doesn't make sense to push something if you actually know there's something in there that's not supposed to be in there. And that gives you feedback to see, OK, maybe I have to look into, actually, what's the problem? CVE number, you will find out the package and then can iterate on your source code and say, OK, let's do it again. Now, these are just two examples that we picked because we figured makes the most sense. And these are the ones that we are currently working on. There are other ideas we have. For instance, BuildKit has, no, Buildpacks. I always confuse them. Buildpacks has this feature for reproducible builds that it actually manipulates the creation timestamp of the image. The idea is the same input should produce the same output, independent of the time you build the image. A lot of container image tooling actually uses the current timestamp of the build for the container image. So another thing we now have the opportunity with separating the things is actually that we can do post-processing on whatever fields in the container image we want, especially the creation timestamps that we could just set a neutral timestamp like 0 or the commit timestamp. So whatever makes sense, we can do post-processing before we actually release the image into the container registry. Other use cases might be removing annotations labels that are actually in some base image. People actually sometimes get annoyed if they have some base image that already comes with labels and they just inherit that and they don't really make sense anymore. So we think there are more possibilities and we would like to hear feedback. So what are other tools that you know and love and use for container images where you think, OK, that kind of makes sense to integrate them into a build automatically so that you don't have to think about them. And of course, questions. So I would open the floor for questions. Exactly. So the question is whether you have to write Tecton Yama. So in ShipWrite, we use Tecton and this is our tool. But we kind of decided to say, OK, we abstract that away from the end user. So our interface is really what we just said, the build, which is just a very simple Yama file with this is the source. These are the credentials to obtain the source. This is the strategy we think makes sense. This is where we want to put it. This is the simplest contract you can have. You can actually extend it with more things, but to keep it simple, this is the simplest contract. And such a build definition is really just 10 lines of Yama. And the idea is that we provide a convenience layer and do basically all the Tecton stuff under the cover for you, including obtaining source code and setting up the task run that the steps are in the right order and everything. So the question is whether it makes sense to have ShipWrite as part of a Tecton pipeline. And I just noted to my colleague, yes, there are such ideas. We want such integration also to be possible. Andrika, do you want to? You have to think about our goal is with Code Engine, which is a serverless platform as a service. So we have compute resources for people to use to serve or have jobs. So the idea is, of course, would be great to use the same resources actually also to create the build. So whenever that makes sense, and there are a lot of use cases where we also have Tecton pipelines. And of course, it would kind of make sense to put that together. All right. So then thank you. So in the name of all ShipWrite contributors, thank you very much for your time and interest. Check us out on ShipWrite.io or GitHub.com slash ShipWrite.io. So we have a couple of projects there. It's not just the build that we just showed you. There's also the CLI, which is again like a convenience layer where you just call the CLI with, this is my Git repository, or also this is my local source code. So we also support that you kind of say, ShipWrite, please take this local source directory, push it up, create a container image for me. And we also have other projects. So take it out. It's all in this area. We have some actually great getting started guides. Like if you happen to have a kind cluster laying around, it's just like two commands you can copy, paste, and set up ShipWrite in less than five minutes. With the samples we have, just to get an idea. And with that, thank you very much and have an awesome day.