Cloud Native Computing Foundation KubeCon + CloudNativeCon China 2018 (Shanghai), 9 Sep 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: The State of Your Supply Chain - Andrew Martin, ControlPlane & Maya Kaczorowski, Google

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

The State of Your Supply Chain - Andrew Martin, ControlPlane & Maya Kaczorowski, Google

Container security often focuses on runtime best-practices whilst neglecting the software shipped in the supply chain. Application or library vulnerabilities are a likely route to data exfiltration, and containers offer a new opportunity to mitigate this risk. Treating containers as immutable artefacts allows us to "upgrade" images by rebuilding and shipping whole images, avoiding configuration drift and state inconsistencies. This makes it possible to constantly patch software, and to easily enforce what is deployed into our environments. In this talk we detail an ideal software supply chain, describe the current state of the ecosystem, and dig into specific tools. Grafeas, Kritis, in-toto, Clair, Micro Scanner, TUF, and Notary are covered, and we demo how to identify a vulnerable image then automatically rebuild and redeploy it.

To learn more click here: https://sched.co/FuKL
Join us for KubeCon + CloudNativeCon in Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Great, let's get started so welcome to our talk today. We're talking about supply chain and supply chain security and I'm Micah Trotsky I'm, a product manager at Google and I work in security and.

B

I'm Andrew Martin I'm, a founder control plane, which is continuous infrastructure and engineering security practices, with a focus on containerized deployments between us. We've done a little bit of everything from product security to development, pen, testing, database administration, and we want to talk about the code that we run in production, how it gets there and how we know the code we thought we were. Shipping is the same code as we are running. So what is this nebulous supply chain? It's anything that we depend upon in a military scenario.

B

The origins and transit of all hardware and software has to be attested to both where it's from and who builds it. This protects us against adversarial or the nation-state, attacks and pharmaceutical companies. They need to know the provenance of all their ingredients, because people are ingesting these things and, of course, kittens well. They need their next treats the supply chain, for these kittens isn't just the hands that feeds them, but also the distributors of The Frisky bits, the warehouses that they were in for home delivery.

B

The manufacturers, farmers that stewarded the chickens, the food that those chickens were fed, so supply chains can be long and difficult to track and when there are no guarantees that the upstream supply chain is competent tracking, where these things came from becomes even more important, especially if we're feeding the Emperors cats. So how does this relate to software? Well, this is a grossly oversimplified software supply chain. But ultimately, a software supply chain is any code that ends up running in production and the trusted mechanisms to build package, and this meet back code.

B

Software supply chains can be exploited so bugs and libraries that are depended upon by an application or deliberate vulnerabilities snuck into popular dependencies, either in the source code or by compromising the hosting service or the infrastructure provider, or perhaps through a compromised download through a man-in-the-middle type attack or typos squatting, which is becoming increasingly popular.

B

For example, a library with a in its name is cloned and re-uploaded without the hyphen. So there are two parallel versions controlled by different people. The attackers are dead, so people can happily resolve and download that dependency because it has the same source code. Their applications continue to run correctly. Then, once the new malicious version has maybe a hundred thousand weekly downloads malicious code is added by the attacker, which, for example, dumped the environment variables and posts them to a remote endpoint.

B

That means if the code is run on a build server, which is deploying directly to production production deployment keys are exfiltrated. So when we talk about supply chain security, we're talking about protecting against all of these threats, the equifax hack was an example of a supply chain, attack, exploiting a vulnerable struts library and compounded by a parameter focused network policy that allowed database access and subsequent exfiltration, detecting the vulnerable struts library through scanning would easily have prevented this.

B

These were well known and published CVS, so other attacks of malicious but legitimately signed version of CC cleaner or when those cleanup tool was delivered to users via their official download servers in 2017. The signing key could have been compromised at multiple points in that deployment pipeline and a similar attack happened with Kingslayer and malicious, but signed binary was distributed so.

A

What in your supply chain will change if you use containers? First, let's look at what your development pipeline looks like more traditionally with virtual machines. Historically, you might have a monolithic application running on a VM and to make a change or your developers would have to SSH into that machine or push code changes without necessarily understanding the impact that it has on the rest of your environment. You had to do a lot of manual adjustments, including for maintenance operations.

A

Like we're starts, you might not even know exactly what's running in your environment, which is kind of terrifying right, you're, changing things on the fly, this isn't only hard to debug, but there's very little formal process. You'll do the same thing again. Next time, you'll just SSH again into your VM to debug, debug patch update, we start or otherwise adjust your application. It's not a great security story and your ops team is probably not gonna love it either either because it's they really don't know.

A

What's going on in your environment anymore, now with containers, this changes slightly, things are a little bit different. You can have a pipeline of things that end up in your environment. You can write code and ensure that it meets your desired requirements for build test, scan, etcetera and then deploy. Micro services are redeployed as individual container images, rather than changing specific lines of code, it's easier to debug and it's also easier to change. This doesn't solve everything.

A

Of course, you still have hard problems to solve, like dependency, management and you'll need good integration testing to get that right, but so you know going back to the supply chain in general. We're gonna break it down into five main components that we'll cover in this talk the base image code, build application, image and deploy. These are the pieces of a secure software supply chain or, in our case, a container delivery lifecycle or a software development lifecycle, whatever you want to call it so your base image.

A

This is your from line that you build your container. On top of you choose a base image on which to build application, which then runs in your container. It's packaged as part of the container itself code. It's your application code, it's what comes out of your software development process build. This is how you do the build of your container image from your code and various packages, application image, how your final packaged up container image, containing your application and deploy.

A

So now that you have your your image all together, it's time to deploy when you're deploying your image, you can use something like an admission controller to determine what should I we be deployed in your environment, for example, if the image hasn't gone through all of the steps that we've laid out so far, you can verify any or you can't verify its provenance, which means where it came from. Then you might not want to deploy it at all so altogether.

A

These make up the components that you would need, and this talk will go through for each of these. What best practices are and then what open-source tools you can use to help get those best practices. So, let's dive in.

B

So, in order to stay, secure, testing needs to be baked in security testing as early in the development lifecycle as possible. So let's have a look. What we can do at each stage of the pipeline controlled base images and any external images should be pulled, re tagged and then copied into the organization's local image registry. They can then be subjected to your organization's internal compliance requirements and be rescanned for CVS or policy on a regular basis.

B

This insulates us from upstream changes or compromise and hash-based addressing in the same way that git tags reference and immutable hash and the tags themselves can be changed and are vulnerable to replay attacks and attacks on the usage of cryptography docker image tags are the same. They are just a mutable pointer to an immutable. Content-Addressable hash and latest is just a tag that is transitory and so a possible risk in.

A

Terms of code, you can scan your code for common misconfigurations or analyze dependencies, so first static. Analysis of your code will help you find more common security issues such as cross-site scripting in a web application or miss configurations like leaving secrets encode this scans, your code without actually executing it. In addition to good old manual reviews, there are more sophisticated things you can do here, such as abstract, syntax tree analysis. To get a good overview of a program like like a compiler. Would a couple of things to keep in mind with static analysis.

A

You're gonna need to plug that in to directly to your CI CD pipeline, for example, as part of your IDE I often have users ask why they can't do this type of analysis later on when you have your full image built, but at that point it's already all bundled up, so you actually have to do it here.

A

Also, scanners tend to be language specific, so you might be restricted and you're in terms of your choice of scanners, if you're picking a particularly bespoke language or environment. The second item here dependency analysis, helps you figure out both immediate dependencies and transitive dependencies, that is dependencies of dependencies, so say you're, pulling an open source packages. You'll want to better understand what you're using and that you're using the latest to patch version, or if your organization has a requirement to use one particular library over another one. You want to check that.

A

That's actually what's happening in reality.

B

We also want hermetic builds that this means no inter build data leakage. For example, a build server, sharing, single docker server and socket could be giving access to all the other builds intermediate layers that they reuse during their the development and build of those other images, of course again with caching build dependencies for speed and fast feedback loops, and, ideally all those build dependencies are cached within an organization's estate.

B

Pinning versions for deterministic builds depends upon the size of your team and organization. Pinning versions removes the risk of silent, semver upgrades that introduce bugs or of the upstream being compromised. However, most operating system repository, maintainer x' will remove the previous version of an application when upgrading it. This means that when the version of a dependency is updated in the remote roger registry repository, our builds will just break.

B

Arguably, the manual advancement of cember is better, but we can also trusts ember and maintainer x'. To some extent, this is dependent upon your organization's risk posture and to the future. Rootless builds. Docker has been heavily criticised over the years for running a root daemon, which means that a break outs or a code execution in the daemons context is executing on the host as roots rootless builds. Our way of mitigating this privilege and just means the docker bailed operation does not require a root user.

B

This has historically been hampered by the fact that usernames basis version one is not widely deployed tools such as you machi image builder and kanuk, oh, and moving towards a safer rootless, build environment. Although this class of build clan attacks that they're mitigating against our best practices best practices, defensive security rather than protecting from in the wild attacks right now,.

A

Now that you've built your image, you're gonna want to verify that it means security, best practices. So first you can scan for vulnerabilities. This is about decoupling, your image into a base image and many layers and verifying those for vulnerabilities. You end up scanning OS components, binaries jars, tarballs everything. What happens if you do find a vulnerability? Well, your remediation options fall into three common categories. First is just a patch it if there's a patch available and if it's a severe vulnerability, this is recommended.

A

That's the best option, something you should be doing on a regular basis. Anyways through your docker, build files. The second option to help improve your vulnerability scan results is to just remove packages that you don't need. So a stock system will come with many packages on it and then in most cases you won't need to actually run your application having those on your system creates a larger surface of attack unnecessarily, and the third option is just taking that to the extreme, which is just moving to a smaller distribution, something like Alpine, deviance, limb or distro.

A

Less images going back to the discussion on base images using a smaller base image, helps you limit your surface of attack and reduces the potential vulnerabilities in your environment. Next, you can scan for configurations. This is to help ensure that your dev team is actually following best practices.

A

Here again, you scan for things like secrets and code, but also container specific configurations like images running with root privileges running as privileged or other privileged escalation concerns by scanning for these things and warning developers early on you can make it easy for them to do the right thing. You can also scan for policies which are using user-defined things like the images must not have any high severity vulnerabilities or have no exposed ports or specifics like extended file attributes it's kind of an aggregate of the other types of scanning.

A

We talk about these kinds of policy checks will either happen here as part of your image scans or in the next step as part of deployment. We.

B

Have followed all of these best practices and now have a container image that were ready to deploy to production, because we have the guaranteed immutability of the images hash. We can capture the metadata generated in the pipeline and associate it with that version of the image, and we can get an admission to production based upon policy compliance and any other metadata that we have gathered from the previous build stages.

B

This can validate that all previous build steps have not only passed but have not been circumvented and that a malicious user with right access to the cube, NASA's API, is enabled to deploy arbitrary attack code. The simplest thing to do here is to ensure that every image that is deployed comes from a registry that is defined in metadata inside the cluster and block. Any image name could not match our policy and finally, runtime configuration.

B

It's all very well to configure these images correctly, but a major difference between a virtual machine and the container is that it is so easy to undo all of the security on a container. Simply adding the privilege flag runs the image and confined without seccomp, without our Parma, and also mounts the host devices into the container. It's probably one of the most dangerous flags in the history of computing, so running, staff analysis on the amyl pod specifications and pod security policies inside the cluster prevents some of these possible configuration.

B

Foot guns, cube Seck io, quantifies risk based on runtime configuration of the images that comprise a pod and can be used during development and as an admission controller, to apply more granular levels of policy than pod security policies.

A

So altogether, as we seen running, a container on micro services leads to a fundamentally different security model than for VMs. So to recap: what's actually different? First containers are meant to be short-lived and frequently redeployed, rather than pushing a single line of code change, your rebuilding and redeploying the entire image. Each time, if you've other processes that can take place passively like patching your OS, for example, you can be constantly doing these. You don't have to have a Sunday 2 a.m. 2 a.m. maintenance window.

A

Constantly patching containers are also meant to be immutable, so they don't change once once they've been deployed, you have content address ability which means that you actually know what's in the environment. This means that, even when you scan your image, when it's still in your repository and it's fine and then after you've deployed it, you discover vulnerability. You don't have to scan your live environment. You can just look at your registry to figure out if you're affected note that I'm talking about image scanning here and not vulnerability standing, you should still be scanning your lives.

A

Your live app to check that it doesn't have common bones since you're, not changing single lines of code, but whole containers. You have a single choke point for everything that gets deployed into your infrastructure. That single choke point is critical and what makes containers fundamentally different and I'd argue a better security model than VNC. It's how you enforce this governance? It's named defer you know: dev, psych, ops or dev sec oops, or a continuous security, whatever you like to call it.

A

So to summarize what the good practices look like before we get into tools here across the whole supply chain or a container delivery lifecycle, you control your base images and choose minimal images that let you limit your service of attack. You write your code, scan it for potential security issues and dependencies. Ideally, you can perform more formal security reviews.

A

If you have time you build the image yourself, and ideally this is a hermetic reproducible, build you scan the image for vulnerabilities misconfigurations and also verify that they meet your up your policies and then you enforce specific requirements such that your images, in fact it did come out of your pipeline. When something changes you can, then you can just go back to whatever step. That was what like, when a new walnut is covered, and you rebuild and redeploy the whole image to fix the issue. Now. This is a lot to get done and you're po.

A

Looking this and going. Oh, my god, I only do 10% of what's on the slide right now, I, don't think anyone is doing all of these things, but Charlie's help you focus your efforts and figure out how to best mitigate the risks in your pipeline, and since there is so much to take on in practice, what should we do to implement these and what tool should we use.

B

Let's have a look at what's available to us today and what's coming tomorrow now this should be caveated. Much of this tooling is still under active development, but we'll go through and have a look at them all in some detail. So, of course, a registry is required to hold base and application images. Docker hub is the biggest of these. However, it no longer runs vulnerability scanning, but other private registries do now there's always some discussion over Alpine vs. Debian based images.

B

However, whatever you use make its consistence as base images, share, storage at rest and copy-on-write memory at runtime ensure that you have proper access, control and key rotation for auth to your registry. Next.

A

Up code updates, there are two main projects in the code: update space and no tightly related. Both tough and notary are CN CF projects. Tough, which stands for the update framework, is a secure distribution mechanism for signing software package updates. For example, when you update an app on your phone, your OS will tell you hey. We have an update time to download a new version.

A

You know please update before performs the update, though it verifies that that update came from a valid source and that works in a closed OS in a closed system like your phone os, where everything goes through a central store, however, for your application code you're pulling from it for many different github repos, and you can't necessarily do that same kind of check.

A

So that's what tough is trying to address notary is just a specific implementation of tough for container images, since more and more applications are being containerized, organizations will more freely receive containers to run rather than arbitrary, binaries to run notary helps verify that updates to these container images are legitimate before you apply them in your infrastructure, and this isn't the only reference implementation, for example, there's also an implication of tough for over-the-air automobile updates called obtain.

A

So, let's look at tough a little bit more tough helps developers maintain the security of a software system, update even against attackers that compromise the repository or signing keys. It's just a framework, so it's a spec plus a few reference implementations. Now what kinds of potential you know, threats and texts? We actually see two software updates, while an attacker might try to install arbitrary software in your system by tricking you into downloading the wrong file.

A

That's what people are the most worried about I think, but they can also create a malicious mirror to prevent a real update or forced you to download an older unpatched version of the software. A software update can then be considered more secure if, according to the tough spec, it knows about the latest available updates in a timely manner. Any files that it downloads are the correct files and, moreover, no harm results from checking or downloading files.

A

So tuff works by providing package signing and creates a signed metadata file using a key fine there's, nothing particularly innovative in the security space plus a secure key distribution mechanism. The main concept to understand about tuff is that it uses a key hierarchy, so it has a root key which is trusted, and then you then derive from that root. Key other keys and delegate trust to those if you know how certificate authorities work for the public web, it's kind of like that.

A

You have a root C of the internet that signs intermediate CAS and those CAS end sign search for individual individual websites, instead of digging more into tough. Let's, instead look at the specifics for notaries, since it's easier to understand for containers specifically.

B

Notary is an implementation of tough for containers that signs and validates images when clients upload new metadata files, the notary server checks them against any previous versions for conflicts and verifies the signatures. Checksums and validity of the uploaded metadata notary implements various recommendations from the tough framework, including survivable key compromise and signing delegation, which essentially just means key delegation, so best practices store the most crucial key, which is the GPT master key offline. This makes it very difficult for bursaries to compromise the trust chain and trust delegation allows for very prompt key rotation.

B

One could, for example, rotate CI keys every month for every week on to pipeline master data. There is a lot of metadata about artifacts and deployments generated in a pipeline we generally discard, but if we keep this information, we can use it to make decisions and report on policy, as well as the efficiency and efficacy of the pipeline. Should we allow builds that depend upon vulnerable components, untested code that come from untested sources, trusted sources, excuse me or are of unknown provenance.

A

So one project must face is graph a which is an open source project to audit and governs software supply chain, and you can use it to track information like versioning and vulnerabilities as part of your container registry. It's just a structured metadata API. It's a key value store, plus the verification of the the data in that store, Griffis stores, metadata about artifacts, like images and information about those artifacts, likelike vulnerabilities, you don't need to only use one source of metadata either you can have multiple providers, so vulnerability.

A

Scanners, for example, can each write their own results? Some metadata providers include J frog, Red, Hat, core OS IBM block Duck, twist lock and aqua as your software supply chain grows or evolves. You can just add additional providers. So then the real benefit occur for us is that all of your metadata sits in one place. You can query across all of this metadata in real time. This lets you answer interesting information about your images like if they're currently affected by any recently discovered vulnerabilities.

A

If you see I always come back to the same point, like am I affect it? That's always the question that people have so the group phase API has a few key concepts. Let's just go through these quickly. A note is the definition of something that can be found or detected through analysis. It's like a note that you'd scribble in the margin of a book, think of them as the dictionary of things that Griffis knows about there are schemas for various predefined types of notes, and these include package so which packages are installed vulnerabilities.

A

Where are there known, vulnerabilities discovery? What type of analysis has happened? For example, a scan builds what source was built from and who built it in which builder was used, image bases which base image was used, deployment history when was it deployed by whom and where and at a station, which is how policy requirements been met all together. This gives you a pretty good idea of the security properties of your image. An occurrence is the instance of a note. It's when you write new data to a note, it might be the building of an artifact.

A

The discovery will evolve. The discovery of a vulnerability or the running of a scan a provider is a source of metadata. It's something like a scanning tool or maybe a teammate organization that wrote the note a project is the namespace for metadata notes, belong to provider projects, so they belong to the scanner, whereas occurrences belong to user projects. Think of this kind of like an index in a book, so the user project is the index and the provider project is the book or books.

A

Each book contains a lot of details about a particular topic and might get updated over time as new editions are published, the index job is to say: oh there's, a new there's, some more information on that. Let me update that reference for you and record that information. Note that I only briefly mentioned out of stations. They aren't really parallel to notes or occurrences, but are actually part of these items. An attestation is a cryptographic signature that allows for verification of these pieces.

A

The goal of signing the data is that you can then verify it to ensure that it hasn't been tempered with. This is just a GPG signed piece of information stored as metadata interface and a verification time. You use a public key to verify that the signature is the correct one.

B

In toto is a framework to provide whole software supply chain security, it provides tooling and metadata and the metadata format to ensure that all steps are performed by the right party follow the expected policy use the right, artifacts and report the artifacts that were produced its core configuration. Primitive is a layout, layouts define what can be done by whom, what to use what to produce and what policy to follow in total layouts are cryptographically signed by a manager to prevent tampering or circumvention in addition to that manager or project owner.

B

There are additional in toto parties functionary to enact a step or build stage and produce cryptographic, evidence and a verified to ensure the functionaries output matches the specification in the layout.

B

Finally, links are used to record information about the execution environment, and these links are cryptographically signed by the party who performed the action, the verification step, checks for compliance using link and layout method data, and this verification can be done in many steps, as you see continuously upon installation when a package is installed or before deployment in the kubernetes admission control flow.

B

Compare these projects Gracias has a strict API schema, which means you can't store freeform metadata, but it covers many types of notes, including the attestation notes, which can be used to attest to arbitrary events or notes. On the other hand, in toto is more adaptable and supports unstructured or freeform data. It can use various storage, backends or metadata transports and importantly can chain, together after stations to assert the sequence of a whole supply chain. Work has been done to integrate these two projects together and they may end up converging around some elements of their specifications.

B

A

Now, let's talk about, let's look at vulnerability scanning, so image is vulnerability. Scanning is meant to detect potential issues with your container image what's actually possible to detect. It depends on how deep you go in that scanning. So what depth the tool you use to gets to more in depth tools will scan OS distribution packages, application library packages note that for these sometimes there's a paid at feed for that from the building, but from the application.

A

So if your scanner that hasn't purchased it, you might not be covered compressed formats like jars bars and tars, potentially malicious code like malware root, kits and back doors and miss configurations, like secrets and code, expose ports and file system properties, recall that your container image is actually made up of layers right. So when you build your image, you're, essentially just generating files by running successive commands, Union mount is a way of combining a bunch of file directories into a single directory that shows all of the content so for containers.

A

You would actually see all the files until you're, together rather than layer by layer. There are two main approaches to image scanning: you either scan each layer individually, layer by layer, or you look only at the top layer of the unit FS filesystem, which takes all the files together using the latest version.

A

In both cases, though, phone scanning generally works by comparing the hash of a particular package to an own package and seeing if it has any known vulnerabilities, most of the vulnerability information comes from the same cbss database, but a particular vendor might override some of the scoring, based on additional information that they have. The best scanners will analyze multiple sources and will work heavily on refining, false positives. This is a really critical step like if I was gonna start somewhere from today's talk.

A

I would probably start here because most of the attacks that occur in the wild or just drive-by attacks right. There are people who are looking for deployments with known foreign abilities and I'm, not talking about zero-day attacks, I'm talking about things that have been around for years, left unpatched, so patching, no matter how unsexy the idea is it's. What really helps protects you against some of these potential attacks.

A

So if you're gonna do this, what are some of the options you have? There are three widely used: open source phone scanners, a core West Clare, aqua, micros canner and encore open source engine as you'll notice. None of these are standalone projects but owned by companies with other offerings in the space like a paid scanner. First off Clare lets you create an index of container images and the features in them and then query a central vulnerability database for any information with those features. It's the same hash and compare I.

A

You know, I was describing before images are only scanned at ingest time, which means that when new vulnerabilities are updated in the database, you don't have to rescan the image you can compare it to existing image. Dance project Harbert that was announces in the CNC F project yesterday uses Clair for vulnerability. Scanning microscope looks a little bit differently. It runs as part of a container image build as an executable in your docker file. If your image has any known high severity issue, Microscan err can actually fail.

A

The image built, which makes it easy to include as a step in your CI CD pipeline. Lastly, encore open source engine is closer and designed to Claire it's a platform that includes a database of vulnerability information for images. It runs as a separate container in your environment, your infrastructure and creates a searchable list of all the packages files and software artifacts, such as ruby, gems and nodejs modules in your environment and.

B

Finally, admission control an admission controller in cuba. Nettie's is a piece of code that intercepts requests the cuban SS api server. After the request is authenticated and authorized.

B

There are two types of admission: controller and kubernetes, mutating and validating, or both and you taking controllers, modify object content, whereas validating controllers verify their output, so you might run multiple mission controllers together. If any controller rejects the request, an error is returned to the end-user and there are a whole bunch of these admission controllers, not necessarily related to security. In general, admission controllers decide whether you shall or shall not pass kritis is cuba Nettie's admission controller that can block, builds based on policy?

B

It has a policy engine to test assertions before deploying containers into cuban s's, and this ensures build vulnerability scanning before deployment or can continuously verify deployed. Images at vulnerabilities are updated and verified, build provenance before deployment cluster administrators manually attest. This image is okay to use or it has been verified and quitters will then only allow pods that have been verified to access the cluster. At present, krisis is not usable outside of GCP, but work is underway to make this application more. Generic here is an image security policy example.

B

We see whitelist images that are latest or certain digests will block admission here. If the max vulnerability severity is too high in the attestation we've have in Chris's, and we can ignore certain whitelisted CVEs that may not be applicable to our runtime environment.

B

Porty eros is another admission controller this time for notary, and this enforces content trust again at deployment time into the cluster. We can apply different levels of trusts for different images and mutating admission. Webhook ensures that kubernetes pulls the signed version of the image. This enforces trust, pinning and blocks. The creation of resources are using untrusted images right now. This supports the IBM Cloud container registry, key dot, IO and docker hub. Although again, work is being done to make this more generic and other integrations are on the horizon.

A

So to bring it all together and to get those photos you missed earlier. An ideal software supply chain has security across five elements that we described today, base image code, build application image and deploy minimal base images to let you limit the surface of attack, scan your code for potential security issues, complete formal security reviews and understand your dependencies, build your image in a hermetic reproducible way.

A

Once it's built, scan your application images for vulnerabilities in misconfigurations and at deployment time enforce any specific requirements you have using the choke point provided by containers when something changes like a new vulnerability is discovered in a package that you're using you can go back to earlier in the supply chain, rebuild and redeploy the image to fix the issue.

B

So the state of ecosystem docker hub provides official base images that we can trust. Tuff protects automatic software deployments for attack and makes them more resilient to compromised notary users, tough to secure docker image, distribution from registries, guaranteeing correctness and freshness the face, holds information about your systems. Compliance and risk state in toto secures build steps with cryptographic, metadata, enhancing accountability of the individuals involved in the chain and the ordering of their actions.

B

Claire micro scanner and core and friends are essential to prevent known, CVS being pushed to production, and you can protect your clusters at deployment time with admission control, quizzes in toto porty, Eris and cube Seck and live a happy fulfilled life ahead of your vulnerabilities and secure forever. Thank you very much.