 All right, so continuing on. So now we have Steve Judd and Chris Clarkson. They are going to be talking about what's inside of your container image and dependency auditing. Good afternoon, everyone. I'm Chris Clarkson, security engineer and lead at the improbable defense. And I'm Steve Judd. I'm the tech lead and I work for a company called JetStack. So to set the scene on how we start out on this work, we start looking at our supply chain, as many people have talked about today, asking ourselves these four questions. What makes up our products? How much that product is from open source, how much is for main source, how much is proprietary? Where do those components come from? Do they come from GitLab, GitHub, Bitbucket, or somewhere else? Where are these components used? So what environment are they used in? Is that development? Is it production? Is it test? And in what context? Is it an observability context? Is it the actual application running? And finally, who has control over those components? Can they retract it, republish it, edit it, or add other code to it? And what risk does that open us up to as consumers of that component? Why is this important? Well, to start with, we're responding to the landscape. As some have mentioned today, there's been quite a few open source supply chain vulnerabilities and issues appeared. Log4shell and the SolarWinds issues. So we decided to take advantage of not being affected as much so that we could start working on the maturity as a team in an organization and factoring open source security and supply chain security into our lead defensive model. Also, it allows us to get a better idea of what's in our product as we sell it and what kind of differences that are making the different use cases that our customers put it to. Next up, we need to better serve our customers. We deal with government agencies in varying jurisdictions. So their legislative and compliance requirements often have an impact on how we deal with these kind of issues. Our US colleagues, for example, they're subject to the President Biden's executive order on cybersecurity, which means everyone that deals with the federal government has to have a better answer when it comes to supply chain management, vulnerability management, and the like. We also want to give our heroes a rest. So whenever there's an issue, you've got a small group of people with a knowledge and experience and a skill who know what to do and when to do it if an issue arises. We'd rather have those people on more complex and more fulfilling pieces of work. So we need to make this easier and more accessible to our broader response teams. And that means we've got to capture the information and make it available so anyone can get notified and respond accordingly. Finally, the commercial engagement, so both in our current markets and our emerging markets, we're looking at how we deal with the increased number of requests for a spawn and vulnerability management. And we have to answer the fact that, as an industry, we realize this is we can't go on as we have been. We've got to have a better story for this. What do we want to achieve from this? So first of all, a component inventory. We need to know what we've got. We need to know what we're selling. We need to know what is going downstream to our customers. So we need to know who created it, where it came from, or what version it's running at. So that allows us then to model against that what vulnerabilities we might be carrying, what we might introduce, but also what might be introduced downstream. As I mentioned, we want to understand those vulnerabilities and track those and be proactive in how we notify people downstream. And in addition to that, the licenses that we're working with. So some of our customers have difficulty in complying with certain of the open source licenses. So we need to know which ones are those we carry with us so that we can work with the customers and mitigate those kind of risks. And finally, the discoverability of these issues. We need a single pane of glass to allow people to see the issues that we might have, the components that we've got, the licenses that we've got in a single pane of glass rather than these individual siloed applications that currently are deployed across our infrastructure. Brilliant. Thanks, Chris. So in the last half of this talk, I'm going to go through how do we deliver on these requirements for improbable. So basically, I've split it into five steps. And the aim is, by the end of this, you should be able to go away understanding how we can get to a way of auditing our dependencies so that you could potentially apply it in your organization. So the first step is you need to be investing in using only a trusted image registry in your own organization. So essentially, as you can see from the diagram, rather than getting your images direct from external sources, such as Docker Hub or Key, you're pulling them direct from your trusted registry. So that gives you a couple of benefits, first of which is that you've now got much more control and insight into the images which you're using in your organization. Though clearly, this means that all of your developers and CI pipelines and Kubernetes clusters do need to pull from your trusted registry only. And the second benefit is that you're much less impacted if there were some problems with an upstream registry. For example, if the registry was unavailable for a period of time, or if they deleted one of the images that you were dependent on. So step number two, once an image is added into your registry, you want to be generating a software bill of materials. So we've had quite a lot of really interesting talks today about what an S-bomb is. So the parts that are of interest to us specifically are the list of dependencies that the S-bomb tells us are contained within that image. So in order to generate that S-bomb, we're using a tool from Ancor called SIFT, and we use the Cyclone DX format. So once we've got this S-bomb generated, then we need to be evaluating the licenses that that image contains, and also the vulnerabilities that it contains. We use a tool from OWASP called Dependency Track, and that helps us perform, manage, and store these evaluations. Dependency Track also contains a policy engine. And we are basically applying a security policy, and we use Dependency Track to tell us whether a newly added image meets our policies or not. So armed with the information about whether the policy is compliant or not, if it's not, we can issue an alert to the security team so that they can do further evaluation and possibly investigate mitigations. If the image is compliant, then we do a couple of things. First of all, we sign both the image and the S-bomb using a tool from Sigstore called Cosine. The reason we do this is that, so in the future, if we want to verify that that image and S-bomb have not been tampered with since we did the evaluation, we can now do so. And then the second thing that we do is create a compliance attestation. And the reason for this is that in a future phase, we will be able to use an admission controller like Caverno or Gatekeeper to be able to ensure that only images that have this attestation can be deployed into our Kubernetes clusters. And then the final step, which I feel comes in very conveniently with the VEX talk earlier, is to maintain an inventory of all of the dependencies that you're using in your environment. And this is to answer those two questions when a new significant CVE comes along. Am I affected by this CVE? What dependencies are affected in my organization? And where are those dependencies used in my environments? So hopefully, at the end, this is basically the end of my talk. So hopefully, you've now got enough information to be able to appreciate how you can apply a lot of the tooling and the specifications and the concepts that you've been talked about today in your own organizations. So thank you very much. And if you've got further questions about supply chain security, either visit the JetStack.io website, because there's now a new toolkit that we've launched just today. Or myself and Chris are at the JetStack booth for the rest of this conference. Thank you for your time. Thank you. Thank you.