Supply chain security in cloud-native environments: What is it, why it matters

We recently sponsored an ebook (download your copy today) in partnership with thenewstack.io on software supply chain security in cloud-native environments. Following is part one of a four-part blog series highlighting the key topics covered in the ebook. 

Over 9 months starting in 2020, in what is now considered one of the worst supply chain attacks against Solarwinds, hackers roamed freely through the networks of possibly hundreds of American organizations. Since then, supply chain security has taken center stage for many cloud-native security teams, who must balance the need to deliver innovative applications at speed with protecting those applications and their code at each phase of the software lifecycle.

What not to do

When developing software in cloud-native environments, securing the software supply chain starts at the beginning of the development phase and continues throughout the application's development lifecycle, spanning dev and prod environments. Leaving security tests for the end of the development and production processes, or applying fixes to running applications, does not suffice.

Improper security implementation can seriously impact business by delaying important releases in order to address issues found later in the software lifecycle or by losing security fixes that were only applied to running workloads.

What to consider

Just as automation is key to DevOps practices and Kubernetes, it’s critical for securing the cloud-native software supply chain. Effective security is continuous, with security gates implemented throughout the build, deploy, and runtime phases, also known as DevSecOps. Effective security allows developers to do their work with guidance from security policies implemented with automated tools that analyze, monitor, and intervene when things go awry. And yet, this is all so much easier said than done....

What to factor in

Most DevOps and SecOps teams face challenges when implementing current best practices to keep their software safe across all development phases. Organizations are hampered by a proliferation of development tools (open source and proprietary), a frequent lack of automated processes, and ever-present software vulnerabilities and emerging threats.

According to survey respondents from Red Hat’s “2022 Global Tech Outlook” report, IT security funding is the top funding priority (46%), underscoring security's importance. At the same time, security is not a static state, especially in microservices-based environments running Kubernetes workloads. Emerging technologies like cloud-native development will require added security investment, especially given their importance in achieving desired business outcomes and driving innovation through digital transformation.

This is because the attack surface is unfamiliar and changes rapidly. Vulnerabilities are numerous and can emerge across repositories with poor or no governance controls where code is sourced and extends across the development and deployment cycle. Compliance challenges are evolving. And developers are often expected to carry security responsibility in order to shift security left.

What this means

Security teams are responsible for understanding cloud-native risks and attack vectors while creating security policies to help harden applications and minimize the attack surface. They must help developers become security users and secure code across the supply chain, including when and how source code, packages, and binaries are sourced and stored throughout the CI/CD process.

Security teams are also responsible for what’s considered day-2 security use cases, including monitoring running applications to ensure adherence with security and compliance requirements. A shifting attack surface means security teams must ensure their security tools and processes can meet evolving threats. Locking down the supply chain as much as possible, therefore, is a mandate of security teams, but not of developers or operations engineers.

While developers consider security a requirement in theory, in practice such staff are often incentivized for adhering to the fastest code deployment schedules and for creating quantifiable business value through innovative customer experiences. Security, in effect, can be seen as a hindrance, especially when security checks happen late in the development stage (or post development), which can lead to deployment delays and missed milestones.

When automated tools and best practices are properly implemented following DevSecOps principles, these competing agendas can coalesce to one goal. Artifacts are vetted, scanned, and signed continuously, without slowing the delivery of software created to improve the customer experience. Issues caught earlier in the development cycle are more easily fixed without impacting business metrics.

Therefore, when implemented properly, DevSecOps becomes a closed-loop system. Proper implementation requires a “shift left” approach to security. This gives developers more responsibility for securing the applications they build by identifying issues and correcting them in their workflows and automatically providing feedback on issues discovered in production back to the developer team to address.

What's the bottom line

Software supply chain security includes all the tools, processes, and people required to build, deploy, and run software. It includes all components and code libraries used to build or update an application, the individuals and machine users who need access to the environment and application, and the workflows and associated tools use to build and ship cloud-native applications. Those tools include security functions that are largely used for scanning, remediating or alerting, and logging. They also include tools not necessarily focused on security, such as image repositories and development platforms.

While the software supply chain security is often focused on the build process and what happens in the CI/CD, it must go beyond that and ensure running applications are monitored for malicious activity or attacks. While it is possible to patch a running container to address newly discovered vulnerabilities, doing so in a Kubernetes environment is not best practice. Kubernetes continuously monitors the actual state of running applications against the declared state. If you only patched the running instance of the app, the patch is then lost when it’s replaced by the new instance. Instead, the security issue must be fixed at the build stage. When the container image is rebuilt, then the new, patched image can be deployed. This is one example of how the runtime environment is critical to the supply chain security.

In the next post of this series, we’ll discuss the cloud-native threat landscape for software supply chains and some of the common attack vectors and targets.