 Great. I'm going to kick start this five-minute trip journey talking about software transparency, dark files, and essentially the challenge of communicating trustworthy software supply chain information in the current state of the art. This is work that I do in my lab at Purdue University, the trustworthy software ecosystems lab, but also with my colleagues at ChainGuard, John Speedmayors, and Adolfo. So the background is very simple. If you're in cloud-native security con, you probably agree that S-bombs are great. By now, everybody's thinking about producing S-bombs, doing something with their S-bombs, maybe just keep somebody happy down the line to say, hey, I have an S-bomb, life is good. Now, the problem is that producing an S-bomb is not so easy. And I'm not talking about creating a file that has all of the schemas with SBDX fields where they go, but rather an S-bomb that's accurate, an S-bomb that communicates meaningful information to users. Now, if you have produced an S-bomb before, you probably could skip a couple of slides here, but I want to get everybody in the same picture. When you are creating an S-bomb, say, about a container that you're about to ship into the cloud, you'll probably use a tool like, say, Trivi. And you want to ask Trivi, hey, what's the S-bomb that corresponds to the container that I have here right now? So Trivi goes ahead and takes a magnifying glass. It takes a little look at your container, and it spits out an SBDX document. Do we agree with this? Yes. Okay. So you may be asking yourself, how does Trivi take a look at my container and concludes that, I don't know, Jilip sees inside of this container that GPG or HTTPD are running inside of this container, and they are of this particular version with his hashes, with his licenses, and so on and so forth. The way that Trivi does it is it actually takes a look at the files in your container. It takes a look at the package metadata from different package managers. Say, you're using apps to install some dependencies. You may be using NPM. You may be using Nougat. You may be using any tool that's helpful to essentially put the files where they're supposed to be going. And maybe if it's feeling good, it may even take a look at the container, take a look at the from, maybe trying to make connections between how the container was built and what does it actually contain. Now we know that parsing this information gives us very trustworthy software supply chain information because this is usually information that's curated by the people that are developing the container or the packages that are inside of your container. We also know that these files are often just very hard to understand. Files that are not being tracked by package managers, files that are not carrying provenance information often just don't tell us a lot about how that this thing came to be or how to trust this particular container. So we came up with this concept called dark files. Dark files is a metaphor alluding to the dark matter. Dark matter is this matter that exists in the universe that we cannot see. We know that it constitutes the universe, but we have never seen dark matter. The goal of this project is to understand how the dark files appear and what are the consequences for software supply chain security and transparency. The problem with dark files is that, well, they can hurt us. They can be binaries that we don't know if they are vulnerable or they have back doors or bad things in them. We can see them so we cannot produce an S bond that represents faithfully what's inside of a container and we can't see them so we cannot do anything about them. We don't have the tools to understand how these dark files affect the system and we cannot take the appropriate steps to fix them. We went ahead and we measured how these dark files appear in the Docker Hub ecosystem and we found that it's actually very widespread. It's a problem in the ecosystem and it affects software transparency. Now, you may be tempted to say, hey, this is a problem with software composition analysis tools. Trivy is not good enough. Our argument is that actually that's not the problem. The fundamental problem is that SCAs can only do so much. They can only guess so much. They can only mine so much information. What we need to be doing is thinking, how can we communicate better information inside of software artifacts? We must measure and reduce the dark files by seeing how they appear and taking steps to better communicate software supply chain information. And that is it. Thank you so much. Any questions? I think we have a minute.