Cloud Native Computing Foundation Cloud Native SecurityCon EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: What’s Inside Your Container Image? How to Audit All the Dependencies... Steve Judd

Description

Lightning Talk: What’s Inside Your Container Image? How to Audit All the Dependencies in Your software Supply-Chain. - Steve Judd, Jetstack

This year has seen much focus on software supply chains and how organisations can move towards a zero trust approach, especially with regards to the 3rd-party artefacts they depend on. Yet a security gap still exists that is preventing organisations from knowing the provenance of their 3rd party software components. This is because the vast majority of build systems (both cloud-hosted and on-premise) do not directly provide the features necessary to achieve even the minimum SLSA Levels. This talk will describe how Jetstack worked with Improbable Defence to design and implement a framework to evaluate all the Images in use across all environments, and seamlessly map each one to known associated vulnerabilities and open-source licences. Assessing Images in this manner has allowed Improbable Defence to keep an accurate inventory and implement admission policies to prevent Images that don’t meet their risk posture from being used. The result is a fine-grained operational security framework which profiles the provenance of each 3rd party component and builds a comprehensive security posture across the supply chain.

A

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.

B

Good afternoon, everyone I'm chris clarkson security engineering, lead at improvable defence.

C

And I'm steve jurd, I'm the tech lead and I work for a company called jet stack.

B

So we to set the scene on how we start out on this work. We started 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 from inner source? How much is proprietary where those components come from? Do they come from gitlab, github, bitbucket or somewhere else?

B

Where are these components used so what environment are they used in? Is that development is it production? Is it test and in one in what context is it an observability context? Is it the actual application running and finally, who has control over those components?

B

Can they retract it republish it edit it and or add other other code to it, and what uh what risk does that open us up to as consumers of that component?

B

Why is this important well to start with responding to the landscape, as some have mentioned today, there's been quite a few uh open source, sorry supply chain vulnerabilities and issues appeared so you've logged for shell, and so the solar winds issues.

B

So we 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 led defensive model.

B

Also, it allows us to get a better in get get a better idea of what's in our product as we 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.

B

uh We deal with uh government agencies in various varying jurisdictions, so their legislative and compliance requirements often have an impact on how we deal with how we deal with these these kind of issues, our u.s colleagues, for example, they're they're, subject to president biden's executive order on cyber security, which means an improvement. 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.

B

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 the 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, more accessible to our broader response teams and that that means we've got to capture the information and make it available. So anyone can get notified and respond accordingly.

B

Finally, the uh the commercial engagement so both in our current markets and our emerging markets, we've got we're looking at how we deal with the increased number of uh requests for s-bomb and vulnerability management, and we do 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.

B

What do we want to achieve from this? So, first of all a component, a component inventory. We need to know what we've got. We need to know what we're selling and we need to know what is going downstream to our customers.

B

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.

B

We want, 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.

B

We need a single pane of glass to allow people to see the issues that we might have the 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 we're that currently currently deployed across our infrastructure.

C

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 in your organization.

C

So the first step is: you need to be investing in using only a trusted image 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.

C

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.

C

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, um 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 are con, that the the s-bomb tells us are contained within that image so to in order to generate that s-bomb we're using a tool from anchor called sift, and we use the cyclone dx format.

C

So once we've got this s-bomb generated, then we need to be evaluating the licenses that that images 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.

C

Dependency track also contains a policy engine and we are a pla. We are basically applying a security policy and we use dependency track to tell us whether a newly added image uh meets our policies or not.

C

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.

C

If the 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 sigstor called cosine.

C

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 kyverno or gatekeeper, to be able to ensure that only images that have this attestation can be uh deployed into our kubernetes clusters.

C

And then the final step, which I feel kind of me 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 the cve um what what dependencies are affected in my organization and where are those dependencies used in my environment?

C

So hopefully at the end, this is basically the end of my talk. So uh hopefully, you've now got enough information to be able to appreciate how you can apply a lot of the tooling and the uh specifications and the concepts that you've been uh talked about today in your own organizations.

C

So thank you very much and if you've got further questions about supply chain security either visit the jetstat.io website, because there's now a new toolkit that we've launched just today or myself and chris are at the jet stack booth for the rest of this conference. Thank you for your time. Thank you.