Cloud, Container and Software Supply-Chain Security

Introduction and Context

Modern applications are assembled from cloud services, open-source libraries, container images, infrastructure-as-code templates, build systems, and third-party application programming interfaces (APIs). This architecture improves delivery speed and scalability, but it also expands the security boundary. A compromise may occur in a cloud identity, a storage policy, a container image, a package registry, a CI/CD runner, or a vendor’s build process. Consequently, application security can no longer focus only on source code and deployed servers.

Cloud, container, and software supply-chain security address the integrity, confidentiality, availability, and traceability of systems across their entire lifecycle. The central professional challenge is to understand which party controls each security function, to enforce least privilege, to establish trustworthy provenance, and to detect malicious or vulnerable components before they reach production.

This chapter uses the term software supply chain broadly. It includes developers, source repositories, dependencies, build tools, artifact repositories, deployment platforms, infrastructure providers, service providers, and operational personnel.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the cloud shared-responsibility model and identify security ownership boundaries.
2. Assess risks involving cloud identity and access management, storage, networks, and managed services.
3. Apply security principles to containers, registries, Kubernetes, and serverless platforms.
4. Analyse software supply-chain threats, including dependency confusion, typosquatting, compromised maintainers, and poisoned build processes.
5. Explain software provenance, artifact signing, SBOMs, attestations, and the SLSA framework.
6. Design practical controls for source repositories, CI/CD pipelines, registries, and production deployment.
7. Evaluate governance, ethical, regulatory, and operational implications of cloud-native security.

1. The Cloud Shared-Responsibility Model

Cloud security is not a single activity delegated entirely to a cloud provider. Responsibility is divided between the provider and the customer, although the division changes according to the service model.

In an infrastructure-as-a-service (IaaS) environment, the provider generally secures physical facilities, hardware, and core virtualization. The customer remains responsible for operating systems, applications, identities, data, network configuration, and often host-level patching. In platform-as-a-service (PaaS), the provider manages more of the operating platform, while the customer remains responsible for application logic, identities, configuration, and data. In software-as-a-service (SaaS), the provider manages the application platform, but the customer still controls users, access rights, data classification, retention, and tenant configuration.

A frequent failure is responsibility ambiguity. An organisation may assume that encryption, logging, vulnerability management, or backup is automatic when the service only provides the capability. Security teams should create a responsibility matrix for each service, including control owner, evidence source, review frequency, and failure response.

The shared-responsibility model does not remove accountability. A provider may be responsible for infrastructure security, but the customer can still be accountable to regulators, clients, or affected individuals when customer data is exposed through a misconfigured storage bucket.

2. Cloud Identity and Access Management

Identity and access management (IAM) is the primary security control plane in cloud environments. A stolen credential can often reach databases, secrets, storage, virtual machines, and deployment systems without exploiting a traditional software vulnerability.

A sound IAM design contains five related decisions:

• Identity: Which human, workload, service account, or federated principal is requesting access?
• Authentication: How is that identity verified?
• Authorisation: Which actions and resources are permitted?
• Conditions: Under what context, such as device, network, time, or risk level, is access allowed?
• Accountability: How are actions logged, reviewed, and attributed?

Least privilege means granting only the permissions needed for an approved task, for the shortest practical period. It should be applied to both humans and workloads. A CI pipeline that only uploads a signed image should not have unrestricted administrative access to the entire cloud account.

Important controls include phishing-resistant multifactor authentication, federation with a central identity provider, separate administrative accounts, role-based or attribute-based access control, short-lived credentials, just-in-time elevation, service-account governance, and periodic access review. Long-lived access keys should be treated as exceptions requiring documented justification and monitoring.

IAM policies should be tested for unintended access paths. Effective access is often the result of identity policy, resource policy, group membership, inherited permissions, network conditions, and explicit deny rules. A permission that appears harmless in isolation may become dangerous when combined with the ability to modify a trusted function, assume another role, or read a deployment secret.

3. Storage, Secrets, and Data Protection

Cloud storage is commonly exposed through configuration error rather than a sophisticated exploit. Typical failures include public object access, unrestricted cross-account sharing, weak deletion protection, missing audit logs, and credentials embedded in application code.

A secure storage design should address:

1. Classification: Identify personal, confidential, regulated, and public data.
2. Access: Deny public access by default and use narrowly scoped roles.
3. Encryption: Protect data in transit and at rest; manage keys separately where appropriate.
4. Lifecycle: Define retention, archival, deletion, and legal-hold requirements.
5. Resilience: Use versioning, backups, replication, and tested restoration.
6. Monitoring: Record reads, writes, policy changes, and unusual downloads.
7. Integrity: Use checksums, object locking, immutable backups, or equivalent controls where tampering is a concern.

Encryption does not compensate for excessive authorisation. If an application role can read every object, encryption may not prevent that role from retrieving sensitive data. Key-management systems should therefore use separation of duties, rotation policies, access logging, and recovery procedures. Secrets should be stored in a dedicated secrets-management service rather than source repositories, container layers, images, or ordinary configuration files.

4. Containers and Image Security

A container packages an application and its user-space dependencies while sharing the host operating system kernel. Containers are not equivalent to virtual machines: a container escape, a kernel vulnerability, or an over-privileged runtime configuration may affect the host and neighbouring workloads.

Container security begins with the image build. Images should be minimal, reproducible where practical, based on maintained base images, and built from pinned dependencies. Unnecessary shells, compilers, package managers, set-user-ID binaries, and debugging tools increase attack surface. Applications should normally run as a non-root user, use a read-only root filesystem where feasible, drop Linux capabilities, and avoid privileged mode.

Image scanning is useful but incomplete. Vulnerability scanners compare package versions with known-vulnerability databases, yet they may miss malicious code, insecure application configuration, runtime behaviour, and vulnerabilities without a published identifier. A clean scan is not proof of safety.

A secure image lifecycle includes:

• authenticated retrieval of base images;
• dependency and operating-system package scanning;
• secret detection in layers and build context;
• image signing and verification;
• immutable or tightly controlled tags;
• registry access control and audit logging;
• admission policies before deployment; and
• rapid rebuilding when a base image or library becomes vulnerable.

Tags such as latest are mutable labels, not strong identity. Deployment systems should preferably refer to immutable digests. A digest identifies content by cryptographic hash, although it does not by itself prove that the content is trustworthy; provenance and signer identity are also required.

5. Kubernetes Security

Kubernetes introduces a distributed control plane consisting of an API server, authentication and authorisation mechanisms, controllers, schedulers, nodes, workloads, and persistent storage. The Kubernetes API is especially sensitive because control over it can become control over workloads and secrets.

Core controls include:

• strong authentication and multifactor protection for administrators;
• least-privilege Role-Based Access Control (RBAC);
• separation of namespaces and duties;
• network policies restricting pod-to-pod communication;
• admission controls enforcing approved images and security contexts;
• protection of the control-plane endpoint;
• encryption of secrets in the backing data store;
• restricted use of host namespaces, host networking, and host-mounted paths;
• resource limits to reduce denial-of-service risk;
• node and cluster patching; and
• centralised audit logging and runtime monitoring.

RBAC must be assessed by capability, not merely by role name. A role that can create pods may indirectly access node resources, mount sensitive paths, or use a service account with broader permissions. Kubernetes security therefore requires analysis of workload specifications and escalation paths, not only a review of static role definitions.

Secrets placed in Kubernetes objects require careful protection. Base64 encoding is not encryption. Secrets should be encrypted at rest, access-controlled, rotated, and preferably integrated with an external secrets manager. Workload identities should be bound to specific service accounts rather than relying on shared static credentials.

6. Serverless and Managed Functions

Serverless platforms execute functions in response to events such as HTTP requests, queue messages, file uploads, or schedules. The provider manages the execution infrastructure, but the customer still controls code, dependencies, event validation, IAM, secrets, and data handling.

Important serverless risks include over-privileged execution roles, injection through event data, insecure direct invocation, dependency vulnerabilities, accidental exposure of environment variables, uncontrolled concurrency, and inadequate logging. Functions should validate event structure and content, use narrowly scoped roles, restrict invocation sources, and avoid placing sensitive secrets in ordinary environment variables unless the platform provides appropriate protection.

Serverless applications can also suffer from event confusion: an attacker causes a function to process an event as if it originated from a trusted source. Event authenticity, replay protection, schema validation, and idempotent processing are therefore important. Functions should be designed so that repeated delivery does not corrupt data or cause repeated financial or administrative actions.

7. Software Supply-Chain Threats

The supply chain is attractive to attackers because one compromised component can affect many downstream organisations. Threats include:

• Dependency confusion: A public package with the same name as an internal package is selected by a package manager because of repository precedence or version rules.
• Typosquatting: A malicious package uses a name visually or phonetically similar to a popular package.
• Compromised maintainer: An attacker takes over a developer account or maintainer role.
• Malicious update: A legitimate package introduces harmful code in a new release.
• Build compromise: An attacker alters source, build scripts, credentials, runners, or release artefacts.
• Registry compromise: An attacker replaces, deletes, or serves malicious artefacts.
• Protestware or account abuse: A maintainer intentionally changes behaviour for political, personal, or disruptive reasons.
• Vulnerability inheritance: A component contains a known or newly discovered weakness that reaches many products.

Dependency confusion is reduced by explicitly configuring private registries, using package namespaces, locking dependency sources, validating package provenance, and preventing public fallback for internal names. Dependency lockfiles improve reproducibility but must themselves be reviewed and protected from unauthorised modification.

8. Provenance, SBOMs, Signing, and SLSA

Provenance is evidence describing how an artefact was produced: source revision, builder, dependencies, parameters, timestamps, and resulting digest. Provenance helps an organisation determine whether an artefact came from an authorised source and whether it was built through an approved process.

A Software Bill of Materials (SBOM) is an inventory of components in a software product. It may identify packages, versions, suppliers, relationships, and licenses. SBOMs support vulnerability response, license compliance, asset inventory, and impact analysis. However, an SBOM is not automatically accurate, complete, or evidence that a component is safe.

Digital signatures provide integrity and signer authentication. Verification answers questions such as: “Was this artefact signed by an accepted identity?” It does not answer whether the signer’s account was compromised, whether the build was secure, or whether the software is free of vulnerabilities. These questions require provenance, policy, independent review, and runtime controls.

SLSA, commonly pronounced “salsa,” is a framework for improving software supply-chain integrity. It describes increasing levels of assurance around source, build, provenance, and tamper resistance. Exact requirements evolve, so organisations should consult the current SLSA specification rather than treating levels as a permanent checklist. The general progression is from documented or automated build provenance toward isolated, authenticated, and verifiable builds that resist unauthorised modification.

A practical control chain is:

Source repository → reviewed change → controlled build → generated provenance → signed artefact → verified registry entry → admission policy → monitored deployment.

The chain is only as strong as its weakest trusted component. If a build runner can be modified by an unaudited administrator, a signature may merely prove that the compromised runner signed the artefact.

9. Securing CI/CD Pipelines

CI/CD systems often possess high-value credentials and write access to production. They should therefore be treated as privileged production systems, not as ordinary developer tools.

Pipeline security should include branch protection, mandatory review for sensitive changes, isolated and ephemeral runners, restricted token permissions, secret masking, protected environments, separation between build and deployment identities, dependency pinning, reproducible or hermetic builds where practical, and tamper-evident logs.

Build scripts and pipeline definitions are code and require review. A pull request that changes a workflow file may alter permissions, exfiltrate secrets, or publish a backdoored artefact. Workflows should use pinned action versions or verified references rather than mutable names. Third-party actions should be minimised and assessed.

A strong deployment gate can require all of the following:

• the artefact digest is present in an approved registry;
• the signature chains to an accepted identity;
• provenance identifies an authorised source and builder;
• the SBOM is available;
• vulnerability and license policies are satisfied; and
• the deployment target is authorised for the environment.

Risk acceptance remains necessary because vulnerability databases, false positives, emergency releases, and unavailable upstream fixes create operational trade-offs. Exceptions should have an owner, rationale, compensating controls, expiry date, and review record.

10. Applied Case: A Retail Platform Supply-Chain Incident

The following is an illustrative case, synthesised for educational purposes.

Background

A retail company operated a Kubernetes-based online store. Its CI pipeline built container images and deployed them automatically after a successful test suite. Developers used both an internal package repository and a public package repository.

Problem

An attacker registered a public package with the same name as an internal utility. A build runner, configured to search the public repository first, downloaded the malicious package. The package harvested an environment variable containing a cloud access token. The token permitted reading selected object-storage buckets and modifying a deployment configuration.

Analysis

The company had image scanning, but scanning did not identify the package as malicious. It also signed images, but the signing key was available to the same pipeline identity that had been compromised. Therefore, the signature established that the pipeline produced the image, not that the build process remained trustworthy. The incident involved dependency-source ambiguity, excessive token permissions, inadequate pipeline isolation, and incomplete provenance.

Approach and Solution

The company disabled the affected token, reviewed cloud audit logs, rotated secrets, and rebuilt images from known-good commits. It then configured explicit private-package namespaces and removed public fallback for internal names. Pipeline tokens were separated into build, registry, and deployment roles. Runners became ephemeral, and credentials were issued for one job with narrowly scoped permissions.

The company introduced signed provenance identifying source revision and builder identity, required digest-based deployment, and enforced admission policies in Kubernetes. SBOMs were retained with release records. A security review was added for changes to dependency configuration and workflow files.

Outcome

The immediate compromise was contained, and historical releases were assessed using repository logs, provenance records, and cloud access logs. The organisation could not prove that every historical build was reproducible, so it treated the affected release family as untrusted and rebuilt it. Subsequent releases had stronger traceability and reduced credential exposure.

Learning Points

1. A vulnerability scanner cannot reliably detect every malicious dependency.
2. A signature is meaningful only when signer identity and build controls are trustworthy.
3. Repository precedence must be explicit, especially where internal and public packages coexist.
4. Pipeline credentials require the same least-privilege discipline as production credentials.
5. Provenance and auditability improve incident response even when prevention fails.

11. Governance, Ethics, and Regulatory Considerations

Cloud and supply-chain security involve decisions about privacy, surveillance, resilience, and concentration of power. Organisations should collect security telemetry proportionately, restrict access to logs, define retention periods, and protect employee and customer information. Security monitoring must not become unjustified monitoring of individuals.

Contracts with cloud and software suppliers should address breach notification, data location, subcontractors, vulnerability disclosure, service availability, exit assistance, audit rights, retention, deletion, and evidence preservation. Regulations may require risk assessment, incident notification, secure development practices, or protection of personal data. The precise obligations depend on jurisdiction and sector; legal advice is necessary for formal compliance decisions.

Open-source maintainers often provide critical infrastructure without equivalent funding or security support. Organisations benefiting from open-source software should contribute responsibly through sponsorship, vulnerability reporting, testing, documentation, and coordinated disclosure. Automated dependency updates should not overwhelm maintainers or bypass appropriate review.

12. Contemporary Developments and Limitations

Software signing, SBOMs, confidential computing, workload identity, policy-as-code, and automated provenance are increasingly important. Artificial intelligence can assist with dependency triage, anomaly detection, code review, and attack-path analysis. However, AI-generated recommendations may contain false positives, overlook novel attacks, expose sensitive code, or create insecure code and configurations. Human review, controlled data handling, and evidence-based testing remain necessary.

No control eliminates supply-chain risk. Pinning dependencies can preserve a vulnerable version; automatic updates can introduce malicious or breaking changes. Reproducible builds may be difficult for systems using timestamps, network access, proprietary tools, or nondeterministic processes. SBOM formats may omit generated components or fail to represent runtime relationships. Cloud controls also vary between providers, and portability assumptions can create hidden gaps.

Effective security is therefore layered: preventive controls reduce likelihood, provenance and signing increase assurance, monitoring supports detection, segmentation limits impact, and tested recovery restores trustworthy service.

Best-Practice Checklist

• Map security ownership for every cloud service.
• Enforce phishing-resistant MFA for privileged identities.
• Use short-lived workload credentials and least-privilege roles.
• Deny public storage access by default.
• Protect, rotate, and audit encryption keys and secrets.
• Build minimal, non-root container images and deploy by digest.
• Enforce Kubernetes RBAC, network policies, admission controls, and audit logging.
• Validate serverless events and restrict invocation sources.
• Lock dependency sources and prevent dependency confusion.
• Review pipeline and workflow changes as privileged code.
• Isolate build runners and limit pipeline tokens.
• Generate SBOMs and verifiable provenance.
• Sign artefacts and verify signatures at deployment.
• Use policy exceptions with owners and expiry dates.
• Test incident response, rollback, restoration, and supplier failure scenarios.

Chapter Summary

Cloud-native security depends on understanding shared responsibility rather than assuming that a provider secures everything. IAM is the central control plane and must protect both human and workload identities through least privilege, federation, MFA, short-lived credentials, and continuous review. Storage requires careful control of exposure, encryption, lifecycle, integrity, and monitoring.

Containers reduce packaging friction but share host resources and therefore require secure images, non-root execution, minimal privileges, registry controls, and runtime enforcement. Kubernetes adds powerful control-plane and workload-authorisation risks. Serverless platforms reduce infrastructure management but do not remove responsibility for code, event validation, identity, dependencies, and secrets.

The software supply chain can be attacked through dependencies, maintainers, registries, source repositories, build runners, and deployment systems. Dependency pinning, private namespaces, SBOMs, provenance, signing, and SLSA-oriented controls improve trust and traceability. Nevertheless, no individual control proves that software is safe. Strong security combines prevention, verification, monitoring, governance, and recovery.

Key Terms

Shared responsibility model: Division of security duties between a cloud provider and its customer.

IAM: Identity and access management for authentication, authorisation, and accountability.

Least privilege: Granting only the minimum access required for an approved task.

Workload identity: A non-human identity used by an application, service, or automated process.

Object storage: Cloud storage that manages data as objects, commonly in buckets or containers.

Container image: A packaged filesystem and metadata used to create a container.

Container registry: A service that stores and distributes container images.

Kubernetes: An orchestration platform for deploying and managing containerised workloads.

RBAC: Role-Based Access Control, which assigns permissions through roles.

Admission control: Policy enforcement applied before a workload is accepted into a cluster.

Serverless: A cloud execution model in which the provider manages the underlying execution infrastructure.

Software supply chain: People, processes, tools, dependencies, and services involved in producing and operating software.

Dependency confusion: Substitution of a malicious public package for an intended internal package.

SBOM: Software Bill of Materials, an inventory of software components and relationships.

Provenance: Evidence describing the source, builder, process, and inputs used to produce an artefact.

Digital signature: Cryptographic evidence binding an artefact to a signing identity and protecting integrity.

SLSA: A framework for increasing assurance in software supply-chain integrity and provenance.

Immutable digest: A cryptographic identifier for specific content, unlike a mutable tag.

Policy as code: Machine-enforced security or compliance rules expressed in a formal, reviewable form.

Review Questions

Short Answer Questions

1. What does the cloud shared-responsibility model mean?
2. Why is Base64 encoding insufficient for protecting Kubernetes secrets?
3. Define dependency confusion and state one preventive control.
4. What information can software provenance provide?
5. Why should production deployments use image digests rather than only image tags?

Long Answer Questions

1. Compare customer responsibilities in IaaS, PaaS, and SaaS, using examples of IAM, patching, and data protection.
2. Explain a secure container and Kubernetes lifecycle from image construction through deployment and runtime monitoring.
3. Discuss the relationship between SBOMs, digital signatures, provenance, and SLSA.
4. Analyse why a vulnerability scanner cannot provide complete assurance that a software component is safe.
5. Design a security architecture for a CI/CD pipeline that deploys signed containers to Kubernetes.

Analytical / Application Questions

1. An organisation discovers that a public package has the same name as an internal package and was downloaded by several builds. Identify the immediate containment steps, evidence to collect, and long-term controls required.
2. A Kubernetes role permits users to create pods but not to read secrets. Explain how this permission might still create an escalation path and propose mitigations.
3. A cloud provider secures its physical infrastructure, but a customer exposes a storage bucket containing personal data. Analyse the technical, governance, contractual, and incident-response responsibilities involved.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the cloud shared-responsibility model?

A. The cloud provider is responsible for all security controls after migration.

B. The customer is responsible for physical data-centre security in every service model.

C. Security duties are divided between provider and customer according to the service and configuration.

D. Security responsibility is transferred entirely to an external auditor.

Correct Answer: C. Security duties are divided between provider and customer according to the service and configuration.

Question 2

Which control most directly reduces the risk of a stolen long-lived cloud access key?

A. Using mutable image tags

B. Using short-lived workload credentials

C. Disabling audit logging

D. Granting the key administrator privileges

Correct Answer: B. Using short-lived workload credentials

Question 3

Why are container image digests preferred over the tag latest for deployment?

A. A digest identifies specific content and is not merely a mutable label.

B. A digest automatically proves that the image contains no vulnerabilities.

C. A digest removes the need for access control.

D. A digest prevents all container escape vulnerabilities.

Correct Answer: A. A digest identifies specific content and is not merely a mutable label.

Question 4

What is the main purpose of Kubernetes admission control?

A. To compile application source code

B. To enforce policies before workloads are accepted

C. To replace all network controls

D. To generate cloud billing reports

Correct Answer: B. To enforce policies before workloads are accepted

Question 5

Which situation is an example of dependency confusion?

A. A package is encrypted before storage.

B. A public package with an internal package name is selected by a build.

C. A developer reviews a pull request.

D. A registry stores an image by digest.

Correct Answer: B. A public package with an internal package name is selected by a build.

Question 6

What does an SBOM primarily provide?

A. A guaranteed proof that software is secure

B. An inventory of software components and their relationships

C. A replacement for digital signatures

D. A network firewall rule set

Correct Answer: B. An inventory of software components and their relationships

Question 7

What does provenance describe in a software supply chain?

A. Only the software's user interface design

B. The source, builder, process, and inputs used to produce an artefact

C. The financial cost of cloud storage

D. The number of end users of an application

Correct Answer: B. The source, builder, process, and inputs used to produce an artefact

Question 8

Why is signing alone insufficient to establish software trust?

A. Signatures cannot detect any change to an artefact.

B. A compromised or unauthorised signing process may sign malicious artefacts.

C. Signatures work only for source code, never binaries.

D. Signed artefacts cannot be stored in registries.

Correct Answer: B. A compromised or unauthorised signing process may sign malicious artefacts.

Question 9

Which practice best reduces dependency confusion?

A. Allowing unrestricted public repository fallback

B. Using explicit private namespaces and controlled repository precedence

C. Removing all dependency version constraints

D. Using the newest package regardless of source

Correct Answer: B. Using explicit private namespaces and controlled repository precedence

Question 10

Why should CI/CD pipelines be treated as privileged systems?

A. They never handle credentials or production access.

B. They commonly control artefact publication and deployment credentials.

C. They operate independently of source repositories.

D. They cannot modify application behaviour.

Correct Answer: B. They commonly control artefact publication and deployment credentials.