Securing the software supply chain with Docker Scout and Amazon ECR

Welcome to this year test on the scott and amazon is here.

Just a quick agenda. I mean, i will just explain to you, i mean, what the code is and what we are trying to solve. And i was working with amazon this year and then a quick demo of everything that can work.

Um so yeah, just briefly, i mean, i'm e i'm senior software engineer at the curve. I'm working on the cr i and the action of the code and some back end piece.

Um so the first question is what is the casco and for that, we need to understand what we mean by supply chain. So imagine you want just to create a cup of coffee. Uh you need your cup, you need your coffee machine, you need water, you need uh coffee beans.

The thing is it, it should, i mean, it sounds ok, but it's not enough because maybe you want, i don't know some um trademark on your, on your coffee beans because you want to see how they are harvested, how they are packaged. I mean you need to ship them, et cetera. So you have your first ingredient but the supply chain is way more than that. It's a lot of different steps everywhere.

If you put that on, on us, i mean on softwares, uh you will have your different sources, you will have your build stuff. That is the coffee machine. In that case, you will have your package, this is your cup and if you apply that to, i mean like containers, your package, you will, you will be not your cup of coffee but the the container image you will have your build steps. You will have different part of the code, but you will also have likes like your own code and someone else code.

Uh and that's where it starts to be really interesting. But the problem with that version of the spectrum is you can have a lot of different issue, every different step, you can have something that goes wrong. And most of the time the prime is it's very noisy. You have a lot of issues everywhere. It's very, very difficult to have a clear understanding of the food supply chain because maybe your issue is not in your car, it's not in your dependency. It can be on the dependency of your dependency and someone else did something wrong.

So there's a lot of farm everywhere. Um and as the devil, the tuning right now is pretty bad. I mean, it's very difficult to understand what it means. So i can, i mean, even where are the real issue and the one i need to fix.

So on that, uh we try to, i mean, create a solution that will help on that. So uh the first part is trusted content, all the differences we have like the official images, the verified publisher. So we based on this trusted content stuff.

On the other side, we created a giant system of record where we will be able to store everything and that will help to have a clear understanding of what is the supply chain right now. And in the middle, we're introducing some policies that will help to understand exactly what is good, what is not what we need to change. I mean, and it's the combination of these three different blogs that will create a very nice developer experience for the spec with that, the first thing we can create is to have a very nice centralized view as we're storing everything at a single place we can create, i mean, a view of your supply chain, we can create a dashboard and all that interesting stuff.

But on that, we'll also be able to create uh to recommend workflow. So the the idea is not to point where the issue, the idea is to let you fix the issue and to let you know how you can fix them directly. And that part, i mean, is also a continuous improvement. There's a lot of different tools that just gives you an instant of what's what's i mean of the status and what's wrong? The idea is to have a continuous improvement all time to be plugged on some kind of event based system.

So i imagine we're pushing a new base image and as soon as it's pushed, we'll be able to say, ok, these are all your images that just become out of date just right now. So it's not just an instant, it's something that evolves all time. So that's provision of doctor scott right now.

And so poets worked with amazon this year because like we also have the for instance, but the thing is like if you're running on, i mean, whatever ekses or any other container solution on most of the time, you will dress up easier because you want to be close to your production because you want to manage your s with um with i and all that nice stuff.

But the thing is, it's never just that because sometimes you, i mean, like for instance, the image you will build and that will push on this year maybe needs a base image that is on doctor herb or um g registry or whatever. So it's not just this year, it's not just her, it's all the registries all together.

But and yeah, the the idea here is to keep your images where you want, you don't have to change anything. I mean, our goal is to secure you su supply chain. It's not to change something to then give you more advice or whatever. Every time we will create your images, push your images, do anything you want, it will just be transparent. I mean, we just connect to just what you have and we will connect that to which here.

And with this system of record, we can also track down everything. So you will be able to know that this image like you have in production with the vulnerability has been built at this time by, by, i mean, from this command by this person because we have all this uh system of regard and oh yeah, it was not the wrong one.

And um the idea is to start where you are is to not have anything to change on your side.

Mm um so just a bit more technical but just how it's working very specifically the integration between the casco and ic r. So the first thing you will do is you will create a very small uh cloud formation stack inside your system and this will be able to create the link between your own uh editors account and the scott.

So we'll be able to, i mean to have an event uh going to scott and we saw some credentials um in the secrets manager and when you will push an image as you do every time, so i mean, we have nothing to change there. We will get an event from there and we'll be able to sign in with the credential to get your image.

Like if there's already a ds bomb that exists, we'll just get that. If we need to, we will be able to pull your image. But uh and we'll be able to inject that. So we'll grab all the contact, i mean, not the content of your image but like the list of packages, the licenses, i mean, all this interesting information and we'll put that back to the cascade. But the point is your push never changed.

If you're pushing rhino images to sierra, it just works. And so with that, we can just see, i mean, oh it's worth for. Uh so the first step, i mean, is just to go to sadaka.com, you need ad account but you don't need to push anything to the hub that's different, but we need still one account.

So if you go to, to sc do.com, most of the time you will start with this kind of screen, it just say that we have nothing uh on you. I mean, we don't know what are your image is, we don't know your registry but we can integrate um with a lot of different components.

So we have a lot of different integrations. I mean, uh we have integration like but continuous integration, we have a good action for that. If you have genki, we can also work with that or you can integrate directly the cr i if you want uh we also have uh integration about runtime environments like uh you want to know exactly what you have in production or in, in staging or whatever. It's not just the images itself in the context where the images are running.

Uh you can have, i mean, a lot of different um integration. One thing also is uh you cannot vote for them. I mean, some of them already exist. Some of them are just what we think we will create. But if you have any other idea of integration, we should do just send a message but on the existing one, so we can know, i mean, and read exactly what, what will be useful for you.

But here, i mean, we are more for the the registry site. So we'll just go to the, i mean, the registry and see how we can integrate. I mean, the the easier one. So as as i said, the first thing is we want to create this stack on uh on aws.

So let's go just to. So i mean, it's the very best. You can just create a very quick start. You don't have uh like, i mean, you can change the name if you want and there's basically two parameters that you don't need to change. This is just to call back to know when it's ready and to be aware of any new pushes. But that's all, i mean, you just, i mean, you can just leave everything by default and you just hit the button to create and that's all. And it will take roughly two minutes. So that's pretty good.

And once it's done, we'll send a message to an snsq and we're just listening, i mean, to an sns topic and we're just listening to that. So if we go back to doctor scott and we just refresh the page, i mean, the integration is not ready. So by ready, it means we have a link between your account and your er and doctor scott. But it doesn't mean we have your images right now because the next step is to select the different repositories because you can have a lot of different repositories, a lot of images and maybe you don't want to enable everything.

So let's just enable, i mean the first one, this is just a demo one. And now we're listening for this repository. So every time you're pushing an image to this specific repository on this here, we'll be able to know it and to ingest the data.

So from there, let's just build a quick image. So uh we have just a quick do a file. I mean it's a very basic image. Uh it just based on alpine, no g si mean whatever it just it just to test the uh i mean how it's working and but on that we will build the image, i will push it.

There's just one thing i mean there's this dash dash test at the same time, i mean, we want to get the proven. So it's not just to build the image, it's also to know in which context we build the image. Like what exactly is the tag you use for the best image? If, if you have a digest that is p etcetera, we want all this context. It's not just what's inside the image, but we need all this information to give you the right advice. When something goes wrong or when you have something to update et cetera, so we'll just build that, push that.

So all that stuff, i mean, it's what you should have. I mean already right now, i mean, you have anything that works uh that build an image, puts an image uh in that case, we're using the cil. But if you're using any other tool that works the way it's built doesn't really matter here.

And now the second thing i will, i will just do is i'm just interesting the idea of environment. So the image itself is one thing but where we really want to, i mean, when we're thinking about supply chain, it's not enough but you want to like an image in staging. If there's a vulnerability, this is not the same thing like if you have the same vulnerability in production, so we'll be able to record more data than just images.

And we'll be able to say that for for instance, this one, this one is introduction. And later i will be able to reference this one by just production. So i'll be able to say like i want to know what's running in production, whatever the name, whatever the tag, whatever i mean, the digest of this image, i just want to know the one in production. I want to know the one in staging, etcetera.

So if you go back to the casco uh we, the first thing we can have is kind of dashboard. I mean that's you need to have a global overview of the of the the chain. So in this case, i mean we only have one image. So we don't have that fancy dashboard, but that's the first part and we can see the image. So the image has been ingested.

And the first thing we can say is we have vulnerabilities in this image. So something is already wrong. So let's explore the image. And this first part, i mean we'll just look at the image layers. Uh this view is also a view you can have in inside the desktop. If you just open the sorry the desktop and click on any image, you will be able to see the internal of the image.

So this is the different layers, this is the base image, but we can see all the details on the packages and the existing vulnerabilities. One thing that is pretty great is you can filter like if i just click on the the base image, i can see exactly the vulnerabilities that are coming from this base image.

So if i update my base image by a new one that is better, i will just reduce my vulnerabilities. And you can do that. I mean, you can start to explore the different packages. See all the different vulnerabilities, you can i don't know select, i mean the other layer that introduced a new one. Here is the rest of the transcript formatted for better readability:

But the problem with that is you have to do all the work yourself. You have to understand how it's made your image. You have to understand where are the different issues? Where are the different packages? Or i i mean, if you want to update a package that is inside of this image, i mean, it's not the same thing that if it's a package you install yourself inside your image.

So the question is how can we make that smarter than just let you do the job? And that's why we're introducing policies. So the policy is just a way to express something more smarter. Like maybe i don't care about all the vulnerabilities the same way. Like if i have a vulnerability that is critical and there's already a version that contained a fix for this one, that's what interests me is there's a lot of vulnerability that there's no fix available. Maybe it's one that i mean, i i can't do anything on this one.

But if i just see the list of rarities, i have to pick the right one myself. So let's check for instance, i mean, the, so in that case, i mean, we have three different uh policies that are not compliant, two of them are ok. So let's pick the one from the base image.

So the things we're introducing also uh remme advice on that and in that case, we'll just focus on the the change the change base image like in that case, i mean, the the best image is the 314 pushed two years ago. So that's quite old and we give you different advice.

Uh so in that case, i mean, we, we suggest three different versions of alpine that you can update depending on the different constraints. I mean, we we can't know everything but we can suggest uh which one for us is probably the best and in that case, it's creating.

And if you look on the right, we can see that this base image has no vulnerability. So if i replace in my image, just my best image i will reduce by uh like i will, i will remove two critical vulnerabilities, 16 high, et cetera.

So let's do that. So if i go back to uh my image, i will just uh update the base image, i mean remove this 314 and just put the 318 and i will just reveal it this time. It's not pushed. So it's more like i'm, i'm in the position of a developer, i want to update my best image. I just build it locally.

Another question is, did i uh i mean, if what i did is good or not, should i push that on a request? Should i push that on staging on my production? And that's where we started to be able to compare different images.

So we have a command that is do that compare, i will say ok, i want to compare my local image. This is the version i just built to the one that is running currently in production. If someone else between already push a new image in production, it will use this one even if i don't know there's a new one. But i want to compare this one because what i want to improve is my production system. At the end, it's not just on my machine.

So it will grab all the details about the image locally, it will grab all the details we have uh on the on the production one and i will be able to compare them. And for instance, i can know that open ssl has been upgraded in that case from 11 to 31. And this is the list of all the vulgarities that has been removed just by this change on the base image.

Uh i can see that i have uh 20 yeah, 26 v that has been removed by this change. But the most important part, i mean this part is interesting if you want to really dig into the details and understand what's going on. But what's better is the comparison of the policies because what we saw here is we still have some critical issues. We didn't remove everything.

Oh no, on the, on the critical we removed everything but on the hyper naab, we still have two hyper with fixes in the the build image. But at the end, we improve the situation of this image. So it's not just black and white, it's not 0 100. I mean it's i want every time i'm doing a small step, i want it better and sometimes it feels like i'm introducing a new dependency or i'm getting a package. Maybe we will, i will remove three vulnerabilities but introduce one critical at the same time. And i want to know what is really the impact if my image is ok.

Ok. Maybe i can just push this one to production because that's good. That's what i wanted at the end.

Mm yeah. So yeah. Um it was just a quick demo of, i mean, what we can do with doctor scott. So um here is just a list of links and documentation. If there's only one you shouldn't care really. I mean that's the docs do do.com/dot.

I mean we have, you know, some docs team that is doing a very good job on the documentation. We are getting started. We have a lot of documentation to get you. I mean, we understand like all the um supply chain material sbo et cetera, everything is documented there. So just go there or just try cut the docker.com.

I mean, this is also a very good step. We have a do cr i we um yeah, we have a do cr i for that. We also have a gab action. Uh and if you have any question, we have a booth that is just beyond you. So we can just be there. I mean, i will be there in the afternoon and tomorrow. So any question or demos or whatever, i mean, just come by the booth and thank you.