Software Supply Chain Security: Tearing Down the Silos
It’s a good time to be a hacker. As the adoption of cloud native technologies continues at an unabated rate of growth, an exponential amount of vulnerabilities and potential attack vectors can easily be exploited by intruders.
The nature of Kubernetes — allowing applications to be scaled, distributed and shared — also creates many weak points in containerized environments. The highly interdependent nature of containers and microservices forming a cloud native environment also means that, in many cases, it just takes a single vulnerability or exposed network port to cause outages and disruptions across an entire network.
Among the attack vectors is open source code that developers have used to build applications, code that may contain hidden vulnerabilities. Once deployed, every Kubernetes cluster can contain multiple namespaces, improperly protected secrets, numerous interconnected containers with multiple dependencies and microservices and other infrastructure to monitor.
The version-control repository for GitOps (GitHub, GitLab, Bitbucket), the entire continuous integration/continuous delivery (CI/CD) pipeline, the cloud infrastructure and the Kubernetes clusters themselves are all on the security team’s watch as well.
In other words, both application and infrastructure security are required for proper cloud native security, both of which fall under the purview of supply chain security.
Numerous tools and platforms exist separately for application and infrastructure security. However, what is typically lacking is a single platform that can serve as a single source or console in order to monitor and manage the entire supply chain. Application and infrastructure security should not only be merged, but the silos separating their management should be removed.
“It’s become absolutely essential to apply a single solution to manage the security for the entire supply chain, covering CI/CD, Git and cloud deployments, in order to get all the visibility required for application and infrastructure and cloud security,” Barak Schoster Goihman, senior director, chief architect of Prisma Cloud at Palo Alto Networks, told The New Stack.
In merging application and infrastructure security, automation from the very beginning of the production cycle is essential, accounting for the so-called “shift left” trend. So, as DevOps teams are learning, is using policy as code, in which code defines and manages rules and conditions, so that apps follow security standards from the start.
In this article, we see not only why it is necessary to integrate all components of supply chain security into a single console but also offer an example of how such a platform would work.
Why Developers Can Be Security’s Weak Link
Security for the development cycle remains in many ways the weakest link in the software supply chain. Much of this has to do with vulnerable, improperly maintained open source code that is part of the software devs are building.
Out of 4,055 templates and 38,480 files from the popular infrastructure as code Terraform repositories, 63% of the templates contained one or more insecure configurations and 49% of the templates had at least one critical or highly insecure configuration, according to the results of a Palo Alto Networks’ Unit 42 analysis using Checkov (an open source static code analysis tool created by Bridgecrew, a company that Palo Alto Networks purchased last year).
“Anyone can publish a module on open-source Terraform repositories, and all the Terraform modules are open-sourced and available on GitHub,” the report read.
In the case of one unnamed “large SaaS provider” the report cites, a Unit 42 researcher found several critical software development flaws in three days “that could have exposed the customer to an attack similar to that of SolarWinds and Kaseya.”
“Overall, the findings indicate that many organizations may still be lulled into a false sense of supply chain security in the cloud,” according to the report.
A developer obviously does not want to introduce vulnerabilities into the stack, but without the proper tools such as policy-as-code processes in place to vet code, and with increasing pressures to create and commit code at faster cadences, some developers may seek to take risks.
“It’s not that developers don’t care about security, but they don’t want to become security experts, either,” Melinda Marks, an analyst for Enterprise Strategy Group, told The New Stack. “A lot of the stuff that developers will do ends up being really hard to manage for a security team later.”
Developers will typically look for the best code that meets their needs at the time, from commercial vendors or open source code repositories providers.
“Developers are going to pull code from anywhere where they need it and they may or may not be following security processes, or using security tools, like automated scanners and things to make sure that it’s secure,” Marks said.
“And then, if they push that code live, it’s hard to tell if it has flaws. So, a lot of it is configuration-based.”
Without the proper policy-as-code and security tools in place that vet whether code is secure or not, “it takes a long time if a developer has to file a ticket for a security person to run a check,” Marks said. “If the process takes a long time to run and it messes up their development process, it’s not going to happen.”
The developer often commits code that is only rejected at a later stage during the continuous integration process, such as when that code has already been configured as a YAML file.
Bad code that is rife with vulnerabilities can also be deployed. In both instances, without automated tools and processes, it is often up to the developer to fix and re-commit the code without the vulnerabilities once they are discovered — thus sapping productivity, since much of the developer’s work must be redone.
Merging Application and Infrastructure Security
The merging of application and infrastructure security under a single platform umbrella is the obvious fix to both maintain proper security and to avoid interruptions in the development process. To that end, Palo Alto Networks has released Prisma Cloud Supply Chain Security.
With it, the company says, a complete view of where potential vulnerabilities or misconfigurations exist in the software supply chain is available from the very beginning of the production cycle, while extending throughout the deployment and post-deployment stages. The platform provides this capability by integrating Palo Alto Networks’ Prisma Cloud security offerings with Bridgecrew’s comprehensive shift-left security capabilities.
“Everything ties together — we focus specifically on supply chain, which can be your application code and infrastructure code for security,” said Stephen Giguere, a developer advocate for Prisma Cloud at Palo Alto Networks.
For the security teams, fixes are automated with Supply Chain Security, whether vulnerabilities are revealed only after the deployment has been made or during the development process. Auto-discovery enables code assets to be extracted and modeled using built-in scanners and remediated with a pull request.
Additionally, from the outset code-repository scanning can identify and fix dreaded vulnerabilities in open source packages used in application code. The entire DevOps team can take advantage of a single-console graph visualization of the entire supply chain, covering application and infrastructure security.
Said Marks, “What this means for security across the entire supply chain is to gain visibility, find things and fix them quickly.”
Prisma Cloud at Palo Alto Networks and Bridgecrew are hosting Code to Cloud, a virtual summit for practitioners, March 23-24. The event will feature sessions on combining development and infrastructure security and other topics relevant to security the software supply chain. You can register for the event here.