By Matt Chiodi, Chief Security Officer, Public Cloud, Palo Alto Networks\n\nSupply chain security has become top-of-mind for many leaders, as incident after incident has revealed supply chain vulnerabilities that expose significant organizational risk. Security challenges like Log4j and SolarStorm have battered organizations of all sizes with risks they likely didn\u2019t even know they had. With a supply chain attack, a vulnerability in one component of a software stack can expose an entire organization to potential exploitation.\n\nResearch from Palo Alto Networks Unit 42 has identified a particularly impactful type of risk in the cloud supply chain that should be a major cause of concern. Our research team found that 63% of third-party code used to build cloud infrastructure is insecure. The security risks include misconfigurations that expose organizations to risk, improperly assigned permissions and vulnerable code libraries.\n\nWhat is the cloud supply chain anyway?\n\nMost of the time, when individuals talk about the supply chain, they\u2019re thinking of things like physical widgets and goods that move from one place to another. What many organizations haven\u2019t wrapped their heads around yet is the fact that the movement of those physical goods is often enabled by applications that are running in the cloud. Going a step further, if your organization is building its own cloud native applications, then you\u2019ve got a supply chain within a supply chain.\n\nModern cloud native applications are built and composed in three high-level steps. At the first level is the provisioning of the cloud infrastructure. The second step is to have a Kubernetes\u00ae container orchestration service, the platform on which the applications are deployed. The third step is the deployment of application container images themselves. Any one of those three layers can have misconfigurations or vulnerable code elements.\n\nDropping the SBOM (Software Bill of Materials)\n\nWhile cloud supply chain security can be complex, it also offers opportunities to make it more straightforward. With cloud native applications, containers are almost always used, which provide an easier way for organizations to actually track what\u2019s in an application.\n\nThe concept of a Software Bill of Materials (SBOM) is simplified with containers as they are declarative. A user can look inside the container manifest and line-by-line, and understand what is inside of the container.\n\nSBOMs are set to increasingly be part of the software supply chain, thanks in part to Executive Order 14028, which mandates the use of SBOMs for US government suppliers.\n\nRecommendations for securing the Cloud Supply Chain\n\nThe cloud supply chain can be complex, considering all the different layers, components, and sources. While complex, cloud supply chain security can be managed with a four-step strategic approach:\n\nStep 1: Define the strategy\n\nA critical first step is to outline an overall strategy to the cloud supply chain that starts with having a shift-left approach. The concept of shifting left is all about moving security earlier in the process, sometimes also called DevSecOps. The strategy need not be outlined in a massive document either. All that\u2019s really needed initially is an outline of the vision, roles, and responsibilities. Iterate over time from here.\n\nStep 2: Understand where and how software is created\n\nThis is where you may have to do a little bit of digging to understand where and how software is created in the organization. This is really about going out and documenting how software makes it from a developer\u2019s laptop all the way until it gets to the production cloud environment.\n\nStep 3: Identify and implement security quality guardrails\n\nIn traditional manufacturing processes, quality controls have long been part of operations. That hasn\u2019t always been the case when it comes to cloud applications, however. What\u2019s needed is to identify where the organization can put proactive checks in place along the line as software is being created. Good security controls need to include as much automation as possible to help supplement manual code review efforts, which will not scale by themselves.\n\nStep 4: Consider certifications\n\nWhile the first three steps are about building security into applications that an organization is developing, there is also a need to validate the security of applications and cloud infrastructure it is consuming. That\u2019s an area where certifications can play a role. The big cloud providers typically have a litany of third-party attestations and certifications. Among the most common are SOC2 Type II and ISO 27001, which identify how a provider implements its own security controls and independently verifies them.\n\nIt\u2019s important to have those certifications to be able to understand how providers systemically go through and evaluate risk. This is important because as you begin scaling the use of cloud, the provider is now a direct extension of your company.\n\nUsing all the steps outlined here can help a security leader put their organization on a solid path towards not only shifting security left but making security synonymous with development. Given the increasing reliance of organizations on the cloud and cloud native applications, the time is now to implement a cloud supply chain security strategy\n\nTo learn more, visit us here.\n\nAbout Matt Chiodi:\n\nMatt has nearly two decades of security leadership experience and is currently the Chief Security Officer of Public Cloud at Palo Alto Networks. He works with organizations to develop and implement security strategy for public cloud adoption and maturity. He does this through advisory meetings with clients, frequent blogging and speaking at industry events such as RSA. He currently leads the Unit 42 Cloud Threat team which is an elite group of security researchers exclusively focused on public cloud concerns. Chiodi has served on the board of various non-profits including Board VP and Governor of Philadelphia\u2019s InfraGard. He is currently on faculty at IANS Research.