DO_BYTE 2026 - Unpack you a Docker for a great good

to Unpack you a Docker for a great good. I'll explain in a moment why the title is funny. Perhaps I should tell you something first today. I'll give you a brief introduction to Docker, where we'll do a bit of ecosystem analysis and then look at what we can really take away from it as a tangible take-home message, as one might say in the corporate world. Who am I? I am Jan Faurin. I am a master's student and in my free time and professionally I work on the infrastructure and operation of various IoT solutions and various IoT adjacent solutions. Modernize the infrastructure of companies, mainly in the manufacturing sector. That means I already have quite a bit of experience with it, and Docker is something I work with on a daily basis. You can reach me at corgian.def or jan. I only included that because I own the domain and thought it was really funny that I got it, and it costs me €7 a year, and I enjoy it every time I can write that somewhere . Uh, here's the explanation for why it's funny when I move slightly to the side. There is a book called Learn You a Haskle for Great Good. Accordingly, Unpack Your Docker for Great Good. And I hope we take something away with us. What are you doing here, or rather, what are we doing here ? We're going to take a look at how Docker's software supply chain works, what the whole thing looks like, because in many conversations with developers I've noticed that many are relatively insensitive to it. They often know the supply chain, as far as programming language ecosystems are concerned, and they know the tooling and everything that goes with it. But then they just take this super well-packaged software and throw it onto a Docker container somewhere, and nobody ever takes care of it again. That's something I want to prevent here. I hope we learn a little something about Docker. Uh, and maybe we'll also learn a few things about best practices. Oh, and you might also see some pictures of my corgs. Uh, I just sprinkled those in a bit, simply to have something to look at on the slides. Introduction. What exactly is Docker ? I'm assuming that we're starting from scratch, more or less. That means if it 's a bit too much, you just have to get through it . Um, Docker is basically a kind of virtualization technology, the whole thing in quotation marks because it does something a little different. It behaves almost like a virtual machine, but Docker uses primitives in the Linux kernel to create this abstraction virtually, rather than emulating hardware. That means I essentially have my own kernel space in which I run, but then I have no underlying hardware that I can access. And the whole thing arose from the idea of ​​wanting to circumvent or work against this Works and My Machine problem . This means that Docker has some kind of abstracted view of the system, and the application is then run within that. That means if I want to start a JVM or an Engine X or something, I don't want it on my host system, but rather somewhat isolated, perhaps simply routing network traffic in and out . Docker then passed on this specification, how to write the whole thing down, to the Open Container Initiative at some point, and this is how the OCI Image Format came about, roughly 10, 12, 15 years ago. I have a small diagram here; I think you can see it quite well. We have a large Linux cel and it runs little whales. Docker's logo is a whale, which is why there are now whales on the foil. And the whole thing is described in a so- called Docker arrow. And here it is particularly important that one can say at the top, I want to inherit from an existing system. And this existing system will become important later in the talk. Um, but this is an Ubuntu 2204 system. That means I'm starting to package my application, starting with a standard Ubuntu system, and then I'll start installing a few things, like installing cron and messing with some files. Um, I just took this from my own productive environment. That means this is actually a Docker case that is in production. Um, one more important thing in order to follow the rest of the talk: tags are mutable. That means if I have a Docker image like that, then I also have an underlying image like that. This Ubuntu version here, this 2204, doesn't have to be set in stone. That means if I publish a new version now, if Ubuntu gets an update, then my vendor, who provides me with this image, may also republish the whole thing under the same name . So, where does this image come from ? Because all I have here is a " from Ubuntu" entry. I'm just going to ask this to everyone . Does anyone know? One arm goes up. Very good. Yes, from Docker Hub. Exactly, that's exactly right. This means that we are not actually downloading Ubuntu here, but rather we are downloading a pre-built image from docker.io/library/ubuntu24. This will only be completed by car. You can configure where it comes from. Most, I would say virtually all, installations do not. And uh, you then have a Docker Hub image. So, let 's get to the topic. Very good. Docker Hub. Uh, Dockerhub is the ecosystem behind it. This provides exactly these images. It contains, I checked again this morning , 13 million images. The previous slide had 12 million displayed because my previous level of knowledge was 12 million. We're just barely over. Um, anyone can publish images and, uh, there are so-called tiers. That means, um, there are practically small icons next to the name. That means there are these official images that you can install here with Ubuntu. They are then located in the Library namespace. They're called "official" when people talk about them. But it's actually the Library namespace and, uh, Community, which I think explains itself. These are all images that have somehow originated from the community. And then Docker also has a Verified feature here. This is also quite interesting because there is no real public information on how this Verified Tier actually came about, where it comes from, and what it is intended for. M on Docker's website says: "Yes, contact our sales team." Uh, that means it probably has something to do with money somehow, I don't know. It could be good. If anyone has more detailed information, I'm open to anything further. Docker is not the only provider. There are even bigger queues. I believe. Redhead expresses this opinion. However, there are thousands of private registries where anyone can publish their own images. Um, please just remember from this slide that there are official images, community images, and verified images. There are a few other animals, which I've left out here to keep things a bit short. There are now Docker Hardened Images, and there are also Open Source Sponsor Tiers. Um, they're not terribly important for us right now. Um, I hope you can still see it properly. These are simply the images I found on the first page. I hope I have a laser attached here. Yes, I have. Here on the left you can select a filter if I want to filter through the results in Docker . There I can just click through Docker Hardent Images, Docker Official, and so on and see what's crawling and crawling in the different tiers . Perhaps you can see it here; this is Amazon Linux, which is a Linux distribution from Amazon. This is Amazon Coreto, which is a Java distribution, if I'm not mistaken, from Amazon. And you can then use all of those as base images. That means if I wanted to package a Java application, I would probably do it on a JVM basis. That means I now have an abstracted operating system on which the JM runs, and I can run my application code on it . This is especially nice for web apps, if that's what you want to do. Theoretically, you can package almost anything with it. Theoretically, even a graphical application, if that's what you really want. Yes, now just one more very short slide. One could also consider, I would like to find vulnerabilities in there. That means I scan these images and look at what packages are installed, both on the operating system ( OS side) and application side. And then you can mix that together and then you can find, oh, there are a lot of critical vulnerabilities in this image. In fact, very few people do that. Um, and furthermore, modern tools can now also find malicious files in these images via hashing. I think that's a pretty cool thing too. That means I have a three-layer security scanning phase in there. Common tools include, for example, Trivy at the moment, which I have actually used a lot. But there are a few other Anchorage or Anchor names. Um, yes, a bit of a public sensation. What do you notice about this image? So, this is one of the images that led me to it . One could delve a little deeper into the Docker ecosystem, but relatively little literature has been found on the subject, or rather, I have found relatively little literature on it here. I hope you can see that a little bit. Below you can see that's a pulse rate of 300 per week. Up there you can see Google MySQL, a Verified Publisher. It's a MySQL server for Google Compute. If it's a latest tag, it 's a digest tag. It's about 100 MBs, so not particularly small, but not particularly large either. M Yes, how would you rate that? Would you trust this image? So I can guess. Lars is standing there. Yes, that's actually true. Please repeat. OK. Someone from the audience just said that you can just barely see it. Last updated 10 years ago. I was kind of hoping that nobody would see it, but yeah. Yes, the front rows really got me. Uh, the image is over 10 years old, now 12 and a half years old, and uh, you really shouldn't install it like that. It's full of vulnerabilities, but it has a certain, let's say, factor that makes the whole thing seem trustworthy when it has a Verified Publisher on it. The assumption is that the image is maintained, that it's somehow up to date and working. Um, would you have noticed that? Maybe raise your hand to everyone who would have noticed. Well, I mean, if you have it right in front of you, then of course it's okay. Some people would have noticed, some people wouldn't have noticed. Um, especially if you just put it in the Docker file. It doesn't say something like "last updated 10 years ago". Nobody cares. [clears throat] That means there are apparently quite a few dead cat members, or rather, there are dead cat members. Now we need to take a look at how many of them there actually are. Um, before that, I'd like to test a bit more about your Docker usage. Who actually uses Docker productively in their business? Yes, I'd say about a third. Maybe half. Yes, half. Who regularly rebuilds Docker images without creating a new release in the process ? One . [snorting] Counts double. If you have to ask follow-up questions , then you don't count. Who rebuilds Docker images because a base image has a new release? Wow, I didn't expect that. I would estimate around 40%. Who locks the image version like a hash? Well, several people raise their hands and shake them like that. I'll count that as half an answer then. I would estimate around 20 to 30%. Um, interesting. Yes, we'll come back to that later. So what can you do now if you've asked yourself these questions? Of course, I did that too, and I thought it would be a good idea to do a small meta-analysis and look at the top 5000 repositories on Dockerhub. I mean, did you just see what that looks like? Um, that means I just downloaded about 120,000 images and then scanned them again with Trivi . That means I only generated a little bit of traffic. um and then [ahem] I built a graph database on it, which had annotated data. That means I have metadata; I know what each image inherits from each other. That means if there are things like Ubuntu 2204, then I see that this image inherits from this image and I even see a little more. I can see exactly which digests are being inherited. That means if this image has been republished, then I can see that there are two different versions behind it. Uh, why a graph database? This makes writing queries significantly easier . Afterwards, I essentially pulled all the Vability data into the graph database as annotated data, and we'll see some queries and graphs from it shortly. Um, the main questions I asked myself were, what about the blast radius? Are there any images that are particularly important? Intuition would say probably Alpine, probably maybe Devian, but there was n't really any literature on it. Um, and can we somehow track the maintenance of these top 5000 repositories, and is it effective? No, just because things are well maintained does n't necessarily mean that there are fewer vulnerabilities as a consequence. This means that these questions now also include the question: can we somehow prevent vulnerabilities? Um, and another question I've been wondering about , for which there's currently no literature. How much better is Verified compared to Community? Yes, how do you get there? I ran 25 workers, which downloaded all the repositories I had, or rather, all the images in these top 5000 repositories. Um, this is a screenshot from a friend of mine who helped with the calculations. Not all workers consumed that much , but overall I probably still extracted 50 to 70 TB of data from Docker in the end. So, what does the Count look like then? This is just a very small excerpt. Of course, I have many, many more images, many, many more relationships in there. Here I have a large cluster of all images that are somehow based on Debian . The one in the middle is a Debian image. This is Ubuntu, and these are the images that are still based on Ubuntu , because they are of course also based on Debian somewhere. I didn't filter that out properly in the image. But I don't think it's really that important. To reiterate, this graph already contains annotated vulnerability data. That means I can ask questions like, "Do the vulnerabilities come from here and then also get into the images that Ubuntu uses?" They come from Debian, then Ubuntu, and then from there, right? Okay, that much is clear. There are people nodding in agreement, which means I'm already satisfied. Um, what kind of numbers did we get out of that? We have roughly analyzed 115,000 or I have roughly analyzed 115,000 images. Of these, 3.3% are base images and the rest have no outgoing images at all, which I later called derivatives. Uh, 34% of the images are derivatives of other images. Um, that's already a big discrepancy. That means I've already found the first indications of a large blast radius . Um, 2.2% of that is the latest figure. I took all the historical data , uh, and then made statements about historical data accordingly. This isn't perfect, the way I did it . Um, and 71% of the latest images have critical vulnerabilities. I found that shocking. Among the top 5000 repositories or top 115,000 images. So, what do the basic images look like? Sure, we all have some kind of intuition. Anyone who has ever worked with Docker knows that you can somehow get any image in the Alpine version as well. We knew we had so much here . This is all somehow a bit new, something that simply fell out of favor with the Top 5000 repositories, but you can see, here is a Debian, here is a Python, there is a Busy Box. Um, that all makes a bit of sense, I'd say, right? Just nod, please, then that's fine. Uh yeah, then I asked myself , are updates made for derivatives and should one do that? Yes, these are critical vulnerabilities. Uh, I basically have an image, a derivative image, and I've looked at what it looks like here, what it looks like there, and whether anything has improved. I did n't look closely at that. Perhaps a vulnerability is being fixed in the derivative and another one is being added here . Um, and then that makes the same number again. I simply did it numerically, because otherwise it would have been quite complicated . That's a relatively large amount of data. So, this vulnerability data alone amounts to around 200 GB of data, and querying it accordingly involves a certain amount of effort. Uh, you can see that 58% are worse, which is shocking, I think. 40% are unchanged and a few others, which I unfortunately ca n't read here right now, have been improved. What is the distribution of vulnerabilities? Um, yes, perhaps the critical vulnerabilities per image are shown here. It takes a little while to get used to these density functions. They're a bit awkward to read, but below are the critical vulnerabilities per image. That means if I look at 10 now, I see the percentages marked out here. Yes, that's about 80%. That means that around 80% here have at least ten and ten or less Vable [snorting] and it continues like that here as well . So, you can already see that the latest versions of Verified and Community are significantly better than the historical average. However, what you can also see is that Library latest is significantly better than all the others. Are the parents of "latest" also "latest"? This is one such query. So I thought, yeah, come on, take a look. Um, we can discuss how meaningful that is in the questions section . Uh, but we see that in Library, uh, or rather, that in Library most parents are also latest, or rather, significantly more parents are latest than their children, and in Verified and Community it's about the same. I do n't want to say good or bad right now . However, I think it's possible to cross-reference Library, Verified, and Community a bit here. Um, there may of course be a certain influence here, that even stable versions are not necessarily the latest . That means if I somehow, uh, use a stable Debian version here, it's not necessarily the latest Debian version, but no, we're talking almost four times as much. Yes, so what do we take away from all this? A few bases or base images bear the responsibility. 34% of the images are derivatives, but only 3.3% are the base. That means we have a relatively high blast radius, right? This means that if there are disadvantages in the base images, the effects will spread quite far back. And since Docker has the peculiarity of performing updates not at runtime, but only at buildtime , uh, you have to actively rebuild the images. Um, only 0.9% of rebuilds improve the vulnerability situation. This means that we as a community have a relatively high degree of trust that the basic images are already rock solid. I mean, the Alpine is of course a good option, but sometimes you simply have applications where that might not be the case. Um, "latest" doesn't necessarily mean current. 71% of the latest images also have critical vulnerabilities in the end, or perhaps "current" is a bit of an overstatement here. Um, 80 to 94% of the latest images don't have a latest parent themselves; it depends on how you read it. Statistically, Verified is not significantly more secure than Community. I also assigned a few other queries and evaluated the results statistically. Um, that's practically equivalent, and I think you can see that quite clearly in the vulnerabilities , that the difference is relatively small . And that means one should perhaps consider whether to give the same attention to these Community versus Verified Tags . That means if you see a "Verified" status in Docker, you should pay attention to it in the same way as if you were reading Community posts. Yes, what are we taking with us? These are both ideas that have been dropped here and generally good ideas on how to deal with Docker. Rebuild your images , rebuild your images regularly. It also has the nice side effect of making releases a bit more frequent, which takes some of the pressure off the process. Uh, lure your images with hash in production mode. It's best to build away from official sources, because they have the fewest limitations if that's your focus, or even Distrolis if you have the option, but those will probably be the fewest. Um, if you're running derivatives, maybe you should rebuild your base images more often. I've encountered this quite often myself: people run their own Docker infrastructure and build from a base image, but the base image is already a year or two old and may also carry critical vulnerabilities . And uh, that's where the scan in the C comes from, maybe your images too. Manage your Docker ignore properly . This is just a general thing. I too often have to deal with Docker files that copy everything in, resulting in huge images. Uh, the people who will ultimately operate and build it will thank you. Perhaps use User in Images, if you have that option. So not root images, but actual user images, and ideally only build it once in the C: drive and then reuse the artifact more often. I've often seen that it wasn't done that way, but rather it was built once for testing and then again for the image, and so on and so forth. Yes, best regards from my Gorgi and questions. [applause] Thank you first of all. No question, but perhaps an addition. You already mentioned the pint version, maybe even the hash. It's best to do the same with the tools you install in the image. Um, so all the packages that come in there, if you have a fixed version pinned to them , you can run a Renovate or Dependerbot or whatever on them and you'll also get new images when a new version comes out. Thanks. I even have a fun fact for you here. In fact, the digests that are listed at the end, the hashes, reference individual architectures differently. This means that if I build different architectures, it doesn't necessarily mean that the same image is used as a basis; rather, I may have two images that carry the same digest if I have multi-architecture images. That's gotten me before. Any other questions? It does n't look like it. Then I thank you very much . [applause]