Cloud, Container, and DevSecOps Testing

Introduction

Cloud computing, containers, orchestration platforms, and DevSecOps have changed how organisations design, deploy, and operate information systems. Instead of protecting a small number of fixed servers, security teams must assess dynamic resources, programmable infrastructure, distributed identities, automated pipelines, third-party dependencies, and rapidly changing workloads.

Penetration testing in these environments requires more than scanning public IP addresses. An assessor must understand cloud identity and access management (IAM), storage permissions, network segmentation, serverless execution, container images, Kubernetes control planes, infrastructure as code (IaC), continuous integration and continuous delivery (CI/CD), and software supply chains. Testing must also respect the shared-responsibility model: a cloud provider secures some layers, while the customer remains responsible for others.

This chapter presents a structured approach to assessing these technologies legally and safely. It emphasises authorised testing, evidence-based conclusions, least privilege, secure automation, and risk reduction rather than destructive exploitation.

Learning Objectives

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

1. Explain the shared-responsibility model and its effect on penetration-test scope.
2. Assess cloud identities, storage, network controls, and serverless services.
3. Identify security risks in container images, registries, runtimes, and orchestration platforms.
4. Evaluate CI/CD pipelines, IaC, secrets management, and software supply chains.
5. Design a safe and repeatable cloud-native testing methodology.
6. Analyse digital-transformation risks and recommend governance and technical controls.

1. Cloud Security and the Shared-Responsibility Model

Cloud services are commonly delivered as infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS). In IaaS, the customer generally manages operating systems, applications, identities, and network configuration. In PaaS, the provider manages more of the platform, while the customer remains responsible for data, identities, application configuration, and access policies. In SaaS, the provider manages most technical infrastructure, but the customer still controls users, permissions, data classification, and secure configuration.

The shared-responsibility model is not a universal legal formula. Exact responsibilities depend on the provider, service, contract, deployment model, and configuration. A penetration tester should therefore obtain:

• written authorisation and rules of engagement;
• the list of accounts, subscriptions, regions, projects, and services in scope;
• provider restrictions on scanning and exploitation;
• test windows and emergency contacts;
• data-handling and evidence-retention requirements;
• exclusions such as provider-managed infrastructure or other tenants.

A cloud vulnerability may result from provider failure, customer misconfiguration, insecure application design, or an interaction between these factors. The report should identify the responsible control owner rather than simply labelling every finding a “cloud vulnerability.”

2. Cloud Identity and Access Assessment

Identity is the principal security boundary in cloud environments. A compromised credential can provide access without bypassing a traditional network firewall. Important identity objects include human users, groups, roles, service accounts, workload identities, API keys, temporary tokens, and federated identities.

2.1 Assessment principles

An authorised assessment should examine:

• multi-factor authentication for privileged and external access;
• federation with an enterprise identity provider;
• dormant users, unused keys, and excessive privileges;
• separation of administrative, development, and production roles;
• conditions based on device, network, time, or authentication strength;
• role-assumption paths and privilege-escalation opportunities;
• permissions granted to services and automation accounts;
• logging of authentication, authorisation, and administrative activity;
• break-glass accounts and their monitoring.

The effective permission of an identity is determined by the interaction of policies, group membership, resource policies, organisational controls, explicit denials, and session conditions. Therefore, reviewing one policy document is insufficient. Testers should construct an access graph showing which principal can assume, delegate, modify, or use another identity.

2.2 Safe testing approach

Testing should begin with read-only enumeration. The tester should identify the authorised principal, enumerate its effective permissions, and attempt only controlled validation actions. For example, instead of downloading an entire database, the tester may access a designated non-sensitive record or prove that a policy permits a specific read operation. Privilege escalation should be demonstrated with the least harmful action that confirms impact.

A useful finding includes the principal, permission, affected resource, precondition, business impact, evidence, and remediation. “Over-permissioned role” is less useful than “the deployment role can modify the production identity policy, allowing it to grant administrative access.”

3. Cloud Storage and Data Exposure

Object stores, block volumes, file shares, snapshots, backups, and databases may expose sensitive information through incorrect permissions or weak lifecycle controls. Common risks include public read or write access, cross-account sharing, predictable object names, exposed backups, missing encryption, insecure pre-signed URLs, and logs containing secrets.

A storage assessment should examine both identity-based and resource-based policies. It should also consider:

• public access prevention controls;
• encryption at rest and customer-managed key permissions;
• encryption in transit;
• versioning, retention, and deletion protection;
• backup and snapshot access;
• data-loss prevention and classification;
• object ownership and upload controls;
• access logging and anomaly detection;
• geographic location and regulatory requirements.

A technically private bucket can still be exposed if an application proxy, signed URL, service role, or synchronisation process makes its contents accessible. Testing must follow data-minimisation principles: validate exposure using synthetic data or a small approved sample, avoid copying unnecessary records, and securely destroy collected evidence.

4. Cloud Network Configuration

Cloud networks are software-defined. Virtual networks, subnets, route tables, security groups, network access control lists, firewalls, private endpoints, gateways, and load balancers jointly determine reachability.

A sound assessment maps data flows rather than merely listing open ports. Questions include:

• Can public workloads reach management interfaces?
• Can a compromised web application reach databases or metadata services?
• Are production and development networks separated?
• Are security groups restricted to required sources and ports?
• Do routes create unintended paths around inspection controls?
• Are private services accessible through incorrectly exposed endpoints?
• Is egress controlled and monitored?
• Are administrative interfaces reachable only through approved channels?

Network exposure is contextual. A port open to an internal application subnet is not equivalent to a port open to the internet, but internal compromise and identity abuse may make lateral movement possible. Testing should therefore combine external reconnaissance, authenticated configuration review, and controlled internal validation.

5. Serverless Services

Serverless functions, event buses, queues, API gateways, and managed databases reduce infrastructure management but introduce event-driven attack surfaces. Relevant risks include overly broad execution roles, injection through event data, unauthenticated endpoints, insecure dependency packages, exposed environment variables, replayed events, excessive function timeouts, insecure temporary storage, and inadequate logging.

A serverless test should assess:

1. Invocation: who or what can invoke the function?
2. Input: are event fields validated and safely interpreted?
3. Authorisation: does the function enforce object- and action-level permissions?
4. Execution role: can the function access unrelated storage, secrets, or administration APIs?
5. Dependencies: are packages current, trusted, and reproducibly built?
6. Secrets: are credentials stored in a managed secret service rather than source code or plain configuration?
7. Observability: are invocation identity, errors, and sensitive operations logged without leaking sensitive data?

Because serverless platforms are highly elastic, denial-of-service testing requires explicit approval and provider coordination. Load testing without limits can generate cost, exhaust quotas, or affect other customers.

6. Containers and Images

A container packages an application and its dependencies while sharing the host kernel. It is not automatically a virtual machine and should not be treated as a complete security boundary. Container security involves the image, registry, runtime, host, network, secrets, and orchestration layer.

6.1 Image and registry assessment

Assessors should examine:

• outdated operating-system packages and vulnerable libraries;
• images built from untrusted or mutable base tags;
• embedded credentials, private keys, and tokens;
• excessive packages and unnecessary utilities;
• root users and unsafe file permissions;
• shell history or secrets retained in image layers;
• unsigned images or missing provenance evidence;
• public registries and weak registry permissions;
• mutable tags and lack of digest pinning;
• malware or unexpected binaries.

A vulnerability scanner produces useful evidence but does not replace analysis. A vulnerable package may be unreachable or mitigated, while a seemingly moderate flaw may be critical if the container is internet-facing and runs with powerful host access.

6.2 Runtime controls

Important runtime controls include non-root execution, read-only filesystems where feasible, dropped Linux capabilities, seccomp and mandatory access-control profiles, resource limits, restricted host mounts, disabled privileged mode, and controlled network connectivity. Testers should verify effective runtime settings rather than relying only on deployment templates.

Container escape testing is specialised and potentially disruptive. It should be performed only in an isolated, explicitly authorised environment. A safe engagement may demonstrate dangerous configuration—such as privileged execution or access to the host socket—without attempting a real escape on production infrastructure.

7. Kubernetes and Orchestration Platforms

Kubernetes consists of an API server, control-plane services, worker nodes, workloads, controllers, admission mechanisms, and an authentication and authorisation model. Its complexity creates risks at several layers.

Assessment areas include:

• API-server exposure and authentication configuration;
• role-based access control (RBAC), including wildcard permissions;
• service accounts and token projection;
• namespace isolation and network policies;
• admission controls and policy enforcement;
• secrets storage and encryption;
• pod security settings;
• host networking, host paths, and privileged containers;
• image provenance and registry controls;
• node patching and cloud-instance permissions;
• audit logs and control-plane monitoring.

RBAC should be evaluated as an access graph. A permission to create a pod may become highly powerful if the pod can mount a host path, use a privileged security context, or obtain a node identity. A permission to read secrets in one namespace may be acceptable for a narrowly scoped service but dangerous when combined with cross-namespace access.

Network policies are often misunderstood. They control selected pod traffic, but they do not automatically secure external load balancers, cloud routes, DNS, identity permissions, or every control-plane path. Defence in depth is required.

8. CI/CD and DevSecOps Testing

DevSecOps integrates security into software delivery rather than treating security as a final gate. A pipeline commonly includes source control, dependency resolution, compilation, testing, image building, signing, artifact storage, deployment, and monitoring.

8.1 Pipeline attack surface

A tester should review:

• branch protection and pull-request approval rules;
• workflow permissions and token scope;
• untrusted input in pull requests and build scripts;
• self-hosted runner isolation and persistence;
• secret injection and masking;
• dependency and plugin acquisition;
• artifact immutability and promotion controls;
• separation between development and production credentials;
• deployment approvals and rollback mechanisms;
• auditability of pipeline changes.

A build pipeline is a privileged production system. If an attacker can modify a workflow, compromise a runner, or replace an artifact, the attacker may obtain a trusted route into production. Security testing must therefore include both source-code controls and the execution environment.

8.2 Security testing in the lifecycle

Controls may include secret scanning, software composition analysis, static application security testing, dynamic testing, infrastructure scanning, container scanning, policy-as-code, and signed-artifact verification. These tools have limitations: false positives, false negatives, incomplete vulnerability databases, and insecure exceptions. They should support professional judgement, not replace it.

A mature pipeline uses risk-based gates. Critical exposed secrets or unsigned production artifacts may block deployment immediately, while a low-severity library issue may create a tracked exception with an owner and expiry date. Every exception should be documented, time-limited, and reviewed.

9. Infrastructure as Code

IaC expresses infrastructure in declarative or procedural files. It improves repeatability and reviewability, but insecure code can reproduce weaknesses at scale.

Review should cover:

• public addresses and unrestricted firewall rules;
• overly permissive IAM policies;
• unencrypted storage and backups;
• hard-coded secrets;
• insecure state files and state locking;
• untrusted modules and provider plugins;
• missing resource tags and ownership metadata;
• inadequate logging and monitoring;
• drift between declared and deployed state;
• unsafe destruction or replacement behaviour.

State files may contain resource identifiers, configuration, and sometimes sensitive values. They require access control, encryption, versioning, and carefully designed storage. IaC scanning should be combined with plan review and deployed-state validation because variables, modules, defaults, and manual changes can alter the final configuration.

10. Software Supply Chains

The software supply chain includes source code, developers, dependencies, build tools, registries, signing keys, artifacts, deployment systems, and vendors. Supply-chain attacks may involve dependency confusion, typosquatting, compromised maintainers, malicious build steps, stolen signing credentials, or artifact substitution.

Key controls include:

• trusted and internally governed package sources;
• dependency lockfiles and integrity verification;
• version and digest pinning;
• vulnerability and licence review;
• reproducible or independently verifiable builds;
• signed commits and artifacts where appropriate;
• protected signing keys and short-lived credentials;
• software bills of materials (SBOMs);
• provenance records describing how artifacts were built;
• rapid revocation and incident-response procedures.

An SBOM improves visibility but is not itself proof that software is safe. It must be accurate, maintained, and connected to vulnerability-management and response processes.

11. A Practical Cloud-Native Testing Methodology

A professional engagement can follow these stages:

Stage 1: Authorisation and discovery

Define targets, accounts, regions, environments, test methods, data limits, rate limits, and provider notifications. Establish a stop condition for unexpected impact.

Stage 2: Architecture and threat modelling

Create an inventory of identities, data stores, workloads, pipelines, trust boundaries, external dependencies, and administrative paths. Consider threats such as credential theft, supply-chain compromise, exposed storage, lateral movement, data exfiltration, and denial of service.

Stage 3: Configuration and identity review

Use read-only tools and provider-native evidence to assess IAM, network controls, encryption, logging, storage, serverless permissions, cluster settings, and IaC.

Stage 4: Controlled validation

Validate high-value findings with the least intrusive action. Use synthetic data, test accounts, isolated namespaces, and non-destructive proof. Do not retrieve unnecessary personal or confidential data.

Stage 5: Correlation and attack-path analysis

Combine weaknesses. For example, a low-privilege CI role, a mutable image tag, and a production deployment permission may form a serious attack path even if each issue is moderate alone.

Stage 6: Reporting and remediation

Rank findings by likelihood, impact, exploitability, exposure, and control strength. Include affected resources, evidence, business consequences, remediation, compensating controls, and retest criteria.

Stage 7: Retesting and continuous assurance

Confirm that fixes are deployed, effective, and not merely applied to one resource. Cloud environments change continuously, so periodic assessment should be supplemented by monitoring and automated policy checks.

12. Risk Analysis and Prioritisation

A simple qualitative model classifies likelihood and impact as low, medium, or high. More formal models may use a multiplicative score such as:

Here, R is a prioritisation score, L is the likelihood rating, and I is the impact rating. The model assumes ratings are defined consistently on an ordinal or interval scale and should not be interpreted as a precise probability of loss. It is useful for ranking findings, not for claiming exact financial risk.

Cloud risk is often driven by attack paths. For example, an exposed build runner may enable credential theft; the stolen role may modify an image; the image may be deployed by a trusted pipeline; and the workload may access customer data. Reports should explain this chain clearly.

13. Illustrative Case Study: The Misconfigured Delivery Platform

Background

A fictional online retailer migrated its order-processing system to a public cloud. Developers used a Git-based CI/CD platform, container images, managed Kubernetes, object storage, and infrastructure as code. The organisation had completed a network penetration test but had not reviewed its delivery platform.

Problem

An authorised assessment discovered that a build runner used a broad cloud role. A pipeline workflow accepted contributions from external branches and executed build scripts on a self-hosted runner. The container registry permitted mutable tags, and the deployment role could update production workloads. Kubernetes workloads also ran with more permissions than required.

Analysis

No single weakness immediately exposed customer records. However, the combined path was serious:

1. A malicious contribution could influence a build job.
2. The self-hosted runner could expose its environment and temporary credentials.
3. The broad role could publish or alter an image.
4. The deployment process trusted the mutable image tag.
5. The production workload inherited access to an order-data store.

This demonstrated that pipeline integrity, image provenance, IAM, and workload permissions were interdependent.

Approach and solution

The organisation isolated external contributions, replaced the persistent runner with an ephemeral runner, reduced workflow token permissions, separated build and deployment roles, pinned image digests, required signed artifacts, and introduced approval for production promotion. Kubernetes service accounts were narrowed, workloads were prevented from running as root, and network policies restricted database access. Synthetic data was used for validation.

Outcome

A retest confirmed that an external contribution could not access production credentials, an unsigned image could not be promoted, and the application workload could access only its designated data path. Monitoring was added for unusual role assumptions and image changes.

Learning points

The case illustrates that cloud-native security is systemic. Strong perimeter controls cannot compensate for weak pipeline identity, mutable artifacts, or excessive workload permissions. Testing should examine trust relationships across the entire delivery chain.

14. Governance, Ethics, and Regulatory Considerations

Cloud assessments may process personal data, intellectual property, credentials, and regulated records. Testers must follow authorisation, necessity, proportionality, confidentiality, and secure disposal principles. Evidence should be minimised, encrypted, access-controlled, and retained only as long as required.

Relevant governance topics include data residency, breach notification, third-party contracts, audit rights, regulatory requirements, provider terms, and segregation of customer environments. A tester must not scan neighbouring tenants, bypass provider controls, conduct unapproved load tests, or retain secrets discovered during testing.

Artificial intelligence can assist with code review, log triage, policy analysis, and prioritisation, but generated results require verification. Sensitive configurations should not be submitted to unapproved external models. AI systems may also introduce supply-chain, privacy, prompt-injection, and hallucination risks into development pipelines.

15. Challenges and Limitations

Cloud-native testing has several limitations:

• provider restrictions may prohibit certain exploit techniques;
• ephemeral resources can disappear before evidence is collected;
• managed services hide implementation details;
• scanner findings may lack business context;
• rapid deployment can invalidate a point-in-time assessment;
• identity permissions are complex and environment-specific;
• third-party dependencies may be outside direct control;
• testing production systems can create cost or availability risks.

These limitations support a blended approach: configuration review, threat modelling, code and pipeline analysis, controlled penetration testing, monitoring validation, and continuous assurance.

16. Best-Practice Checklist

• Obtain explicit cloud-provider and asset-owner authorisation.
• Use least privilege for people, workloads, pipelines, and break-glass access.
• Enforce MFA and monitor privileged identity activity.
• Prevent public storage exposure and protect backups and snapshots.
• Segment workloads and restrict east-west and outbound traffic.
• Build minimal, patched, signed images and pin trusted digests.
• Prevent privileged containers and unsafe host mounts.
• Apply narrowly scoped Kubernetes RBAC, network policies, and admission controls.
• Isolate CI/CD runners and use short-lived credentials.
• Protect IaC state and review both plans and deployed resources.
• Maintain SBOMs, provenance, dependency controls, and artifact integrity.
• Use synthetic data and non-destructive validation wherever possible.
• Monitor drift, unusual identity use, pipeline changes, and image promotion.
• Retest remediation and continuously improve controls.

Chapter Summary

Cloud, container, and DevSecOps testing requires assessment of technology and trust relationships together. The shared-responsibility model defines which controls belong to the provider and which remain with the customer. Identity is a central boundary, while storage, network configuration, serverless permissions, containers, Kubernetes, CI/CD pipelines, IaC, and software supply chains create interconnected attack paths.

A professional assessment begins with authorisation and architecture discovery, proceeds through configuration and identity analysis, validates important findings safely, and reports business-relevant attack paths. Effective protection depends on least privilege, strong authentication, secure artifacts, isolated pipelines, controlled workloads, policy enforcement, monitoring, and continuous retesting. Ethical and regulatory duties require proportionality, data minimisation, confidentiality, and respect for provider and tenant boundaries.

Key Terms

Cloud computing: On-demand delivery of computing resources through networked services.

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

IAM: Identity and access management for users, services, roles, and permissions.

Federation: Linking an external identity provider to cloud authentication.

Object storage: Storage of data as objects addressed through a service interface.

Serverless computing: Event-driven execution in which the provider manages much of the underlying infrastructure.

Container: An isolated application process sharing the host operating-system kernel.

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

Registry: A repository for storing and distributing container images.

Kubernetes: A platform for orchestrating containerised workloads.

RBAC: Role-based access control that assigns permissions through roles.

CI/CD: Automated processes for integrating, testing, delivering, and deploying software.

Infrastructure as code: Declarative or procedural management of infrastructure through code.

Software supply chain: The people, code, tools, dependencies, artifacts, and services involved in producing software.

SBOM: A structured inventory of software components and dependencies.

Artifact provenance: Evidence describing where and how a software artifact was produced.

Policy as code: Machine-enforced rules expressed in a formal, reviewable format.

Attack path: A connected sequence of weaknesses that can produce a harmful outcome.

Ephemeral runner: A temporary CI/CD execution environment destroyed after a job.

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

Review Questions

Short Answer Questions

1. What does the shared-responsibility model mean in cloud security?
2. Why should container images be pinned by digest rather than relying only on mutable tags?
3. Name three important areas of Kubernetes security assessment.
4. What information does an SBOM provide?
5. Why should cloud penetration tests use synthetic data where possible?

Long Answer Questions

1. Explain how identity, storage, and network configuration can combine to create a cloud attack path.
2. Describe a secure methodology for testing a CI/CD pipeline without disrupting production.
3. Compare the security responsibilities associated with IaaS, PaaS, and SaaS.
4. Explain the major security controls required for container images and runtimes.
5. Discuss why IaC improves consistency while also allowing vulnerabilities to scale.

Analytical / Application Questions

1. A deployment role can publish images, a registry permits mutable tags, and production automatically deploys the latest tag. Analyse the attack path and propose controls.
2. A serverless function can read an entire customer database although it processes only order-status requests. Assess the risk and recommend a least-privilege redesign.
3. During an authorised Kubernetes review, a service account can create privileged pods and access a node identity. Explain the likely impact and describe a safe validation strategy.

Multiple Choice Questions with Answers

Question 1

Which principle most directly limits the damage caused by a compromised cloud role?

A. Least privilege

B. Mutable image tagging

C. Public network access

D. Disabling audit logs

Correct Answer: A. Least privilege

Question 2

What is the primary purpose of pinning a container image by digest?

A. To increase container CPU capacity

B. To ensure the referenced image content does not silently change

C. To permit anonymous registry access

D. To remove the need for vulnerability scanning

Correct Answer: B. To ensure the referenced image content does not silently change

Question 3

Which Kubernetes control determines what an authenticated principal is allowed to do?

A. RBAC

B. DNS

C. Image compression

D. Object versioning

Correct Answer: A. RBAC

Question 4

Why are self-hosted CI/CD runners a significant security concern?

A. They cannot execute build scripts

B. They may retain credentials or be compromised between jobs

C. They always prevent supply-chain attacks

D. They eliminate the need for access control

Correct Answer: B. They may retain credentials or be compromised between jobs

Question 5

Which item is an example of software-artifact provenance?

A. The screen resolution of a developer’s laptop

B. Evidence describing how and where an artifact was built

C. A list of public IP addresses only

D. A database backup schedule

Correct Answer: B. Evidence describing how and where an artifact was built

Question 6

What should a tester do before performing potentially disruptive cloud testing?

A. Begin immediately on every public address

B. Obtain explicit authorisation and define rules of engagement

C. Disable provider monitoring

D. Copy all accessible customer data

Correct Answer: B. Obtain explicit authorisation and define rules of engagement

Question 7

Which practice best protects IaC state files?

A. Store them in a publicly readable bucket

B. Embed administrator passwords in them

C. Apply access control, encryption, and secure state management

D. Delete all review history

Correct Answer: C. Apply access control, encryption, and secure state management

Question 8

A serverless function needs to update one queue but can administer all queues. What is the principal weakness?

A. Insufficient image compression

B. Excessive execution permissions

C. Lack of object versioning

D. Overly restrictive network segmentation

Correct Answer: B. Excessive execution permissions

Question 9

What is the main purpose of an SBOM?

A. To inventory software components and dependencies

B. To replace all authentication controls

C. To guarantee that software contains no vulnerabilities

D. To configure a cloud firewall automatically

Correct Answer: A. To inventory software components and dependencies

Question 10

Why must cloud penetration testing consider provider restrictions?

A. Cloud services have no security controls

B. Unauthorised testing may violate contracts, affect other tenants, or cause disruption

C. Provider restrictions apply only to physical offices

D. Restrictions make written authorisation unnecessary

Correct Answer: B. Unauthorised testing may violate contracts, affect other tenants, or cause disruption