Cloud-native supply chain security: What it is and why it matters?
In collaboration with thenewstack.io, we just sponsored an ebook on software supply chain security in cloud-native systems (get your copy right away). The first of a four-part blog series outlining the important subjects covered in the ebook can be found below.
In what is now regarded as one of the worst supply chains hacks against Solarwinds, hackers had free reign over the networks of perhaps hundreds of American businesses for nine months beginning in 2020. Since then, many cloud-native security teams have placed a high priority on supply chain security. These teams now must strike a compromise between the requirement to quickly deploy innovative apps and protect those applications and their code throughout the software lifecycle.
What not to do
Securing the software supply chain starts at the beginning of the development process and continues throughout the application’s development lifecycle, covering dev and prod environments, while developing software in cloud-native settings. It is insufficient to save security tests till the end of the development and production processes or to patch up-and-running programs.
By delaying significant releases to resolve problems discovered later in the software lifecycle or by losing security fixes that were only applied to running workloads, improper security implementation can have a significant negative impact on business.
What to Consider
Automation is essential for DevOps methods and Kubernetes, just as it is for protecting the supply chain for cloud-native software. DevSecOps, often known as continuous security, is the implementation of security gates during the development, deployment, and runtime phases. Developers can complete their job while being guided by security policies that are put in place by automated systems that analyze, monitor, and take action when something goes wrong. Nevertheless, it’s far easier said than done.
What to factor in
The majority of DevOps and SecOps teams have difficulties putting into effect the most recent best practices to protect their software during all stages of development. The abundance of development tools (both open source and proprietary), the frequent absence of automated processes, the constant presence of software vulnerabilities, and growing threats all pose challenges to organizations.
IT security funding is the top financial priority (46%), according to poll respondents from Red Hat’s “2022 Global Tech Outlook” study, highlighting the significance of security. However, security is rarely a static state, particularly in settings that use microservices and run Kubernetes workloads. Given their significance in attaining targeted business goals and fostering creativity through digital transformation, emerging technologies like cloud-native development will require more security expenditure.
This is due to the attack surface’s unfamiliarity and constant change. There are many vulnerabilities that might appear in repositories with low or no governance controls where code is sourced and used throughout the development and deployment cycle. The issues with compliance are changing. Additionally, in order to move security left, developers are frequently required to assume responsibility for security.
What this means
In order to harden applications and reduce the attack surface, security teams are responsible for comprehending cloud-native threats and attack vectors. They must support developers in becoming security users and secure code along the supply chain, including the timing and location of obtaining and storing source code, packages, and binaries during the CI/CD process.
Day-2 security use cases include monitoring operating applications to guarantee compliance with security and compliance regulations. These tasks fall within the purview of security teams. Security teams must make sure their tools and procedures can keep up with changing threats because of the shifting attack surface. Therefore, security teams have a responsibility to lock down the supply chain as much as feasible, but not developers or operations engineers.
Although in principle developers view security as a prerequisite, in reality, these employees are frequently rewarded for adhering to the quickest code deployment deadlines and for delivering novel client experiences that generate tangible economic value. When security checks are performed late in the development process (or beyond development), they might cause deployment delays and missed milestones, which can be regarded as a burden in practice.
These divergent objectives can unite to achieve one objective when automated technologies and best practices are correctly applied in accordance with DevSecOps principles. The constant vetting, scanning, and signing of artifacts does not hinder the supply of software designed to enhance the user experience. Early detection of problems allows for easier fixes that don’t affect business metrics.
As a result, DevSecOps becomes a closed-loop system when properly deployed. A “shift left” perspective on security is necessary for proper implementation. By recognizing problems and fixing them in their processes and automatically informing the developer team of problems found in production, increases developers’ accountability for securing the apps they create.
What’s the bottom line
All the equipment, procedures, and personnel needed to create, distribute, and run software are included in the software supply chain security. The entire set of parts and code libraries required to create or update an application, the people and machines who require access to the environment and the program, as well as the processes and tools used to create and distribute cloud-native applications, are all included. These products have security features that are mostly used for logging, alerting, and remediating security issues. They also comprise technologies like image repositories and development platforms that aren’t necessarily security-oriented.
While the build process and what happens in the CI/CD are frequently the focus of software supply chain security, it is essential to ensure that active applications are watched for suspicious activity or assaults. Even though it is possible to patch an active container to fix recently found vulnerabilities, doing so in a Kubernetes context is not recommended. Continuous monitoring by Kubernetes compares the actual status of active apps to the declared state. If you merely updated the app’s running instance, the update is discarded when the new instance replaces the old one. Instead, the security flaw has to be resolved during the construction process. The updated, patched image can be deployed when the container image has been rebuilt. This is only one example of how important the runtime environment is to supply chain security.