 Hi, I'm Ali Gholshan, Senior Director of Software Engineering at Red Hat, previously CTO and co-founder at Stack Rocks. Today we're going to be talking a little bit about supply chain security and why recently it has become such a hot topic in cloud native technologies. One of the main things that we have seen is this change and shift in the attack landscape and attack surface from traditional exploitation and vulnerability exploitation at runtime towards the supply chain. And the reason for this is that very simple. It's the fact that on the supply chain side, there is a much more proliferated set of tools and solutions to use and there's truly no perimeter. Combined with the fact that there's less maturity around security tooling, dev teams need to continuously communicate with security teams, there's generally less controls around tools and products. And the main goal on the developing side, on the DevOps side, on the left side is really lowering friction, injecting velocity and as a result removing any blockers which has typically been associated with security has created this landscape where attacks are starting to grow substantially more. The other aspect of it is that traditional attribution is substantially more difficult to apply on the supply chain side. As a result, it reduces the risk of discovery and it can actually increase the attack surface as an attacker you can go after. This is also why it's very important and this is why at Red Hat, we believe it's very important for security to be built in versus bolted on for developer tools and as part of the supply chain. Now, what are some of the things that you have to consider and be able to make sure you take into consideration as part of your supply chain security? Well, one major question is where do my software components come from? Where am I getting my tools? Where am I getting all these particular images? Images in public registries can be potentially poisoned with unwanted application malware, backdoors or potentially components that are unuseful to you but could be very useful for attackers and for anybody trying to infiltrate your network. In some cases, these can be detected with static tool analysis and this is why it's very important to have static analysis as part of your system. However, introducing a lot of vanilla images and ensuring that there's a large touch point to your potentially infected images can also ensure that the deployment of these images increases and eventually they make them into the stream of the development. The other part of it is vulnerability management and configuration management as part of the supply chain in a declarative fashion is still a substantially unsolved problem. The volume of attacks is increasing dramatically suggesting that there's more and more organized infrastructure and some targeting of which companies introduce a higher level of tooling into other companies supply chains. Obviously this is an example that we recently saw with the SolarWinds attacks. Combined with the attribution we talked about and the problem that it presents on the supply chain poisoning the well can be a substantially more lucrative way to attack businesses versus actively engaging of exploitation of vulnerabilities at runtime. So when we talk about CVEs, even though this is an unsolved problem there is still a lot of gaps that we need to go and figure out. So we need to pay more attention to it. Understanding vulnerability packages and their dependencies. These typically create thousands of alerts and there's no good way to triage these. Understanding what are they actually relevant to? Which ones can be solved or upgraded? If they are upgraded, what can they break? Which ones are actually exposed to me in runtime? Are they allowing for permissive attack surface? Do I have proper configurations to be able to prevent them? And more importantly, which ones are actually being exploited into the wild so I can push that information back to my engineers, to my developers to reduce that time in resolving those particular problems. Now, typically one of the things that we have seen from supply chain attacks and general attacks on misconfigurations really the way we can solve these problems through a declarative fashion. The problems have centered around mostly for example, installing cryptocurrency miners or establishing a footprint for distributed denial of service attacks. But more recently, we have started to see a substantially more targeted approach for supply chain attacks. Again, being able to push yourself into a stream where because of all these layers and all these abstractions, you become embedded into images and tools and eventually become part of the existing stack which creates substantial problems. Now you combine this with additional problems like the fact that more and more we're using from a development and automation standpoint infrastructure as code templates. So whether we're using things like HashiCorp Terraform, AWS Cloud Formation Templates, Kubernetes App Manifest YAMLs, these are things developers use and DevOps teams use to be able to move faster. But at the same time, if we can essentially move more and more to the left and be able to do things as an example tools like for example, KubeLinter where we can actually fix misconfiguration and be able to identify some of these problems in configuration and supply chain issues before they're introduced into infrastructure at runtime, they present a much easier way to solve these things. The other reason why supply chain security is very important is understanding these deep dependencies several layers down and being able to understand what is good and what is bad. In a lot of the cases, the dependencies become a problem because sometimes you have maintainers that abandon them or sell them or you have in a case where bad actors take control of them and they somehow end up on a developer's machine. So to be able to understand and have good hygiene as part of your supply chain to be able to understand dependencies, these asset and then managing this inventory of assets and how they're getting introduced into your infrastructure is very critical. This is why we think it's very important not just to have security for build, deploy and run but it's very important to be able to tie all these stages together through a cohesive policy language where context can be shared and problems can be solved based on actual relevance and impact. One of the other types of more recent attacks we've seen on the supply chain is actually the notions of typosquadding which is we're starting to see a more rise towards. So as we talk more and more about infrastructure as code templates, it's very important to understand that if these misconfigurations are introduced into your infrastructure they substantially amplify the risk that goes into your runtime infrastructure. And in a lot of cases these become embedded in your infrastructure and very difficult to roll back. This is why you constantly now hear about this notion of shift left and why it's very important to do that. Now, we recognize at Red Hat that there is a very fine balance between velocity and flexibility for developers. Developers want to be able to choose their packages, want to be able to determine which containers they want to use and being able to essentially determine how they build together their tools that allow them to move faster and deliver business goals. But at the same time we want to have vetting and controls in place so we can apply compliance whether it starts from very basic aspects of CIS benchmarks or more custom or very specific useful custom tools and controls that are specific to your business and organization to be able to vet these out. The other reason as to why supply chain security becomes very important and dealing with these issues in a declarative fashion is not just the infrastructure itself but all the new layers of tooling that are highly automating and contributing to scale. For example, going from Kubernetes to Istio or general service meshes. These are all components that are highly contributing to the velocity of development. So if we do not take on this notion of shared responsibility and ensure that our supply chains are properly locked down, looking for bad indicators and eventually solving these through configurations and declarative fashions, we end up with a runtime environment that you really don't have to think about your highest risk environment being even a vulnerability that is going to be exploited. It could be simple misconfigurations in your RBAC or even exposed APIs. And this is again where it brings us back where at Red Hat what we are focused on is ensuring developer velocity, business moving as quickly as possible. But at the same time for us to integrate all of our security tooling and knowledge across the entire lifecycle and ensure that we are leveraging as many open source tools and as many tools that the developers can integrate into their existing workflows to solve for a lot of these particular supply chain securities. Thank you very much for your time. And if you have any questions, feel free to reach out to me.