12. Cloud-Native, Container, Mobile and IoT Testing

Introduction and Context

Modern information systems are no longer confined to a data centre, a web server, or a desktop application. Business services are assembled from cloud infrastructure, managed identities, object storage, serverless functions, containers, orchestration platforms, mobile clients, application programming interfaces (APIs), and connected physical devices. This architectural shift has expanded the attack surface and changed the nature of ethical hacking and penetration testing.

A conventional network assessment may examine hosts, ports, operating systems, and perimeter controls. A cloud-native assessment must also examine who can assume an identity, which service can access an object, whether a deployment pipeline can alter production, whether a container is running with excessive privileges, and whether a mobile application exposes secrets or trusts an unvalidated certificate. An IoT assessment may extend further, into firmware, radio protocols, hardware interfaces, cloud back ends, and the safety consequences of manipulating a physical process.

The central challenge is not simply technical complexity. It is the distribution of responsibility. Cloud providers secure the underlying facilities and managed infrastructure, while customers remain responsible for configuration, identities, data, workloads, and access decisions. The precise boundary varies by service model and provider. Consequently, penetration testing must begin with authorization, architectural understanding, and a clear statement of what is in scope.

This chapter presents a platform-appropriate approach to testing cloud-native, containerized, mobile, and IoT systems. It emphasizes evidence-based assessment, controlled exploitation, least privilege, secure development, and professional ethics.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain shared responsibility and its implications for cloud penetration testing.

2. Assess cloud IAM, storage, APIs, serverless functions, and logging controls.

3. Identify container and orchestration risks across images, runtime configuration, and cluster management.

4. Evaluate CI/CD pipelines as part of the software supply chain.

5. Apply suitable methods to mobile application testing, including static, dynamic, and API analysis.

6. Describe the architecture and attack surface of IoT systems.

7. Design a legally authorized, risk-based test plan for these environments.

8. Interpret findings in terms of business impact, safety, governance, and remediation.

A Risk-Based View of Modern Attack Surfaces

The attack surface of a distributed system is the collection of interfaces through which an attacker could influence confidentiality, integrity, availability, or safety. These interfaces include human identities, machine identities, APIs, configuration files, deployment tools, message queues, storage buckets, container registries, mobile binaries, wireless protocols, and device management services.

A useful assessment begins with an asset and trust-boundary model. The tester identifies data flows, administrative paths, external dependencies, and control points. A mobile application may communicate with several APIs rather than a single server. A container workload may obtain credentials through a workload identity mechanism. An IoT device may communicate with a local gateway, a cloud broker, and a mobile application. Each connection represents a trust assumption that must be tested.

Testing should be threat-informed rather than tool-driven. The question is not whether a scanner reports a vulnerability, but whether a realistic misuse path exists and what consequence follows. For example, a publicly readable object is serious when it contains credentials or regulated data, but less severe when it contains deliberately public marketing material. Conversely, a low-privilege cloud role may become critical if it can modify a deployment pipeline.

Cloud Responsibility and Authorization Boundaries

Cloud security is commonly described through a shared-responsibility model. The provider normally protects physical facilities, hardware, and foundational services. The customer normally manages data, identities, permissions, configurations, applications, and guest operating systems where applicable. Responsibility changes with infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).

This model is not a transfer of accountability. A provider may make a storage service resilient, but it does not decide whether a customer should allow anonymous access. A managed database may be patched by the provider, while the customer remains responsible for authentication, network exposure, and sensitive data. Testing therefore requires a responsibility matrix that states which party controls each layer.

Before testing, obtain written authorization defining accounts, regions, domains, APIs, test windows, permitted techniques, data-handling procedures, emergency contacts, and prohibited actions. Cloud environments are shared, and uncontrolled load testing, exploitation of provider infrastructure, or testing another tenant is unacceptable. The tester must distinguish customer-owned resources from provider-managed components and use provider-approved testing procedures where required.

Identity, Access and Storage Testing

Identity and access management (IAM) is often the most important cloud testing domain. Assessment should cover human users, service accounts, roles, federated identities, temporary credentials, workload identities, and emergency accounts. The tester examines whether privileges are narrowly scoped, whether administrative actions require strong authentication, whether unused identities remain active, and whether role assumption is restricted by context such as account, network, device, or workload.

A practical method is privilege-path analysis. Starting with a low-privileged identity, the tester maps actions that can be performed directly and roles that can be assumed indirectly. Particular attention is given to permissions that allow policy modification, creation of access keys, alteration of functions, modification of compute instances, or access to secrets. A permission that appears harmless in isolation may become dangerous when combined with another permission.

Cloud storage testing includes object stores, file shares, snapshots, backups, databases, and data lakes. The tester checks public exposure, cross-account access, insecure sharing links, weak encryption configuration, excessive retention, inadequate logging, and predictable object names. Listing permission and read permission should be distinguished: an attacker may be unable to read an object but still learn sensitive metadata. Write access is often especially consequential because it may enable content substitution, malware distribution, or server-side code execution in a consuming application.

Testing must avoid indiscriminate downloading of personal or confidential information. Where possible, use canary files, synthetic records, metadata-only validation, and limited samples. Evidence should demonstrate the issue without creating a new data breach.

APIs, Serverless Services and Event-Driven Systems

Cloud-native applications are frequently API-centred. API testing should address authentication, authorization, object-level access, rate limits, input validation, error handling, versioning, and business logic. A key distinction is between authentication—establishing who the caller is—and authorization—determining what that caller may do. Testing should attempt access to another user’s resource using a valid but different identity, while remaining within the authorized environment.

Serverless functions introduce a different execution model. A function may be short-lived, automatically scaled, and triggered by an HTTP request, message, file upload, schedule, or database event. The assessment should examine trigger authorization, function roles, environment variables, dependency vulnerabilities, event validation, secret handling, outbound access, logging, and injection paths. A function with broad permissions can turn a minor input flaw into a cloud-wide compromise.

Event-driven systems also create asynchronous trust problems. A message may be accepted from an untrusted producer, replayed, modified, or processed more than once. Tests should consider message authentication, replay protection, schema validation, dead-letter queues, idempotency, and authorization between producers and consumers. Excessive error detail can disclose internal resource names or credentials, while poorly controlled retries can create denial-of-service conditions or duplicate financial operations.

Containers and Orchestration Platforms

Containers package an application and its dependencies, but they do not automatically provide strong isolation. Container testing begins with image provenance and construction. The tester reviews base images, operating-system packages, embedded credentials, unnecessary utilities, exposed ports, hard-coded configuration, user privileges, and software-bill-of-materials (SBOM) information. Vulnerability scanners are useful, but findings require contextual analysis: a vulnerable package may be unreachable, while an overlooked secret may be immediately exploitable.

Runtime controls are equally important. A secure workload should generally avoid privileged mode, host filesystem mounts, host networking, unnecessary Linux capabilities, and root execution. The tester checks whether the container can access the metadata service, whether secrets are exposed through environment variables or mounted files, whether writable paths permit tampering, and whether resource limits reduce denial-of-service risk.

In orchestration platforms such as Kubernetes, the assessment expands to the control plane and cluster configuration. Important areas include the API server, role-based access control (RBAC), service accounts, admission controls, network policies, secrets, ingress controllers, namespaces, workload identities, and the container registry. A service account should have only the permissions required by its workload. Namespace separation is useful, but it is not a substitute for authorization controls.

A common attack path is a vulnerable application leading to command execution in a pod, followed by credential discovery, access to the orchestration API, and deployment of a new workload. The tester should validate each step safely, using benign proof files or controlled commands rather than destructive payloads. Cluster findings should be reported as attack paths, not isolated configuration warnings.

CI/CD and Software Supply-Chain Testing

Continuous integration and continuous delivery pipelines are privileged production systems. They compile code, retrieve dependencies, build images, sign artifacts, and deploy workloads. A compromise of the pipeline may be more damaging than a compromise of a single application.

Assessment should examine source-control permissions, branch protection, build-runner isolation, secret storage, dependency retrieval, artifact integrity, approval gates, environment separation, deployment identities, and logging. The tester asks whether a contributor can alter a workflow, whether pull requests execute untrusted code with privileged credentials, whether build artifacts are mutable, and whether production deployment can occur without independent approval.

Supply-chain controls include pinned dependencies, trusted registries, provenance records, image signing, SBOMs, vulnerability gates, reproducible builds, and separation of build and release privileges. Automated security tools should be integrated into the pipeline, but a failed scan must not be treated as the entire security strategy. False positives, vulnerable transitive dependencies, and malicious but technically valid packages require human review.

Mobile Application Assessment

Mobile testing combines application review, device analysis, network observation, API testing, and business-logic assessment. It should cover both Android and iOS where relevant, because platform controls and packaging differ.

Static analysis examines the application package, manifest, permissions, embedded endpoints, cryptographic usage, exported components, debugging settings, third-party libraries, and hard-coded secrets. It may reveal API keys, test credentials, insecure deep links, or excessive permissions. Static results must be verified dynamically because a string in a binary is not necessarily an active secret.

Dynamic analysis observes the application during execution. In an authorized laboratory environment, the tester examines local storage, logs, screenshots, inter-process communication, certificate validation, backup behavior, authentication state, and response to tampered input. Sensitive tokens should not be stored unprotected, and logout should invalidate sessions appropriately. Certificate pinning can reduce interception risk, but it must be implemented carefully so that legitimate certificate rotation and recovery remain possible.

The mobile client must be treated as untrusted. Controls such as code obfuscation, root or jailbreak detection, and device attestation can raise the cost of abuse, but they cannot replace server-side authorization. The most significant findings often occur in APIs: insecure direct object references, weak authorization, excessive data exposure, replayable tokens, missing rate limits, and business-logic flaws.

IoT and Cyber-Physical Testing

IoT systems combine constrained devices, firmware, sensors, actuators, gateways, cloud services, mobile applications, and operational processes. Their risks include conventional cybersecurity failures and physical consequences. An unauthorized command to a light may be inconvenient; an unauthorized command to an industrial actuator, medical device, vehicle component, or building-control system may create safety hazards.

An IoT assessment begins with asset discovery and architecture mapping. The tester identifies device models, firmware versions, communication protocols, management interfaces, update mechanisms, cloud endpoints, radio technologies, and data flows. Testing may include network service review, firmware analysis, web and mobile API assessment, hardware-interface inspection, wireless protocol analysis, and update-process testing.

Important questions include whether devices use unique credentials, whether default accounts are disabled, whether firmware is signed and verified, whether updates can be rolled back safely, whether sensitive communications are encrypted and authenticated, and whether a compromised device can pivot into a corporate network. Debug interfaces should be disabled or protected in production. Device identity must be bound to secure keys rather than easily copied identifiers.

Testing should be coordinated with safety and operations teams. Commands to actuators may require simulation, a test bench, or a maintenance window. Availability testing must account for devices that cannot be safely rebooted or flooded with traffic. The goal is to prove risk without causing unsafe physical outcomes.

An Integrated Testing Method

A suitable engagement can be organized into six connected stages.

First, define scope and authority. Record assets, accounts, environments, permitted techniques, data constraints, provider requirements, and stopping conditions. Second, model architecture and threats. Identify trust boundaries, privileged identities, sensitive data, physical effects, and likely attack paths. Third, perform discovery and configuration review using cloud inventories, manifests, image metadata, mobile packages, firmware, API specifications, and network observations.

Fourth, validate vulnerabilities through controlled exploitation. Use the least invasive technique that demonstrates impact. Fifth, analyze attack paths and business consequences. A finding should explain preconditions, affected assets, evidence, exploitability, impact, and recommended control. Sixth, support remediation and retesting. A successful retest verifies not only that a configuration changed, but also that the original attack path is no longer viable and that monitoring can detect recurrence.

Risk ratings should consider likelihood, privilege required, exposure, data sensitivity, safety impact, blast radius, detectability, and compensating controls. Cloud-native environments particularly benefit from graph-based analysis that represents identities, resources, permissions, and relationships. Such analysis can reveal privilege escalation paths that ordinary vulnerability lists miss.

Illustrative Case Study: Meridian Care Platform

Background

Meridian Care, a fictional health-services provider, operates a cloud-native patient-monitoring platform. Patients use a mobile application; home devices transmit readings through an IoT gateway; cloud functions process events; clinicians access a web portal. Containers run in a managed Kubernetes cluster, and a CI/CD pipeline deploys application updates.

Situation

An authorized assessment identified a low-privilege support role, a mobile API, a device-update service, and a deployment pipeline as in scope. The organization believed that encryption and managed cloud services substantially reduced risk.

Analysis

The support role could invoke a function that generated diagnostic exports. The function’s role allowed read access to a broad storage location. The export API checked that the requester was authenticated but did not consistently verify ownership of the requested patient identifier. In addition, the mobile application stored a long-lived refresh token in an inadequately protected local store.

The container review found that a processing workload ran with an unnecessarily broad service account. The CI/CD pipeline accepted pull requests from external contributors and executed build steps with access to a package repository credential. The device-update mechanism used encrypted transport but did not robustly verify firmware provenance.

These were not independent weaknesses. A stolen mobile token could expose patient records through the API. A compromised function could access the storage location. A malicious pipeline change could deploy a container capable of accessing cluster services. An unauthenticated or weakly verified firmware update could compromise devices and use them as a foothold into the organization.

Approach and Solution

The testing team used synthetic patient records and a laboratory device. It demonstrated cross-record access without extracting real data, proved the function’s excessive storage permission using a canary object, and showed that the pipeline credential could be used only against a test repository. Device-update testing used signed test firmware and confirmed that unsigned firmware was rejected after remediation.

Meridian introduced object-level authorization checks, narrowed function and service-account permissions, rotated and shortened token lifetimes, protected mobile storage, isolated build runners, separated pull-request and production credentials, required signed artifacts, and implemented firmware signature verification. Monitoring was added for unusual role assumption, bulk export requests, pipeline changes, and device-update failures.

Outcome and Learning Points

The organization reduced the reachable attack paths rather than merely closing individual scanner findings. The case demonstrates four principles: identity permissions determine cloud blast radius; mobile clients cannot enforce authorization alone; pipelines are production assets; and IoT security must include update integrity and safety controls.

Challenges, Limitations and Common Mistakes

Testing distributed systems is difficult because assets change rapidly, provider abstractions hide implementation details, and ownership may be divided among several teams. A snapshot assessment can become outdated when infrastructure is created automatically. Scanner output can also overwhelm teams with findings that are technically correct but operationally irrelevant.

Common mistakes include testing without provider authorization, treating cloud configuration as separate from application testing, assuming private network placement guarantees security, ignoring machine identities, downloading unnecessary sensitive data, using production devices as experiments, and reporting vulnerabilities without attack-path context. Another mistake is to focus on known vulnerabilities while missing business-logic flaws, excessive permissions, insecure defaults, and weak recovery procedures.

Limitations should be stated honestly. A penetration test cannot prove the absence of vulnerabilities, examine every code path, or replace continuous monitoring and secure engineering. Mobile reverse engineering may be constrained by obfuscation; firmware analysis may lack hardware documentation; and managed cloud services may limit visibility into underlying infrastructure.

Ethical, Governance and Regulatory Considerations

The tester must preserve confidentiality, integrity, availability, privacy, and safety. Authorization must be specific, current, and documented. Personal data should be minimized, masked, encrypted, retained only as necessary, and securely destroyed. Findings involving healthcare, finance, children, critical infrastructure, or physical safety require appropriate escalation.

Governance should assign owners for cloud accounts, registries, mobile applications, devices, pipelines, and third-party services. Evidence must support accountability without exposing secrets in reports. Coordinated disclosure, change control, separation of duties, and independent review are particularly important where a tester has administrative access.

Professional judgment also requires refusing unsafe instructions. A client’s request to “test everything” does not authorize attacks on a provider, another tenant, public infrastructure, or a safety-critical device without controls. Ethical practice is therefore both a legal requirement and a technical risk-control mechanism.

Automation, Analytics and Emerging Developments

Infrastructure as code enables security checks before deployment. Policy-as-code can detect public storage, excessive permissions, unapproved regions, or insecure Kubernetes settings. Software composition analysis, container scanning, secrets detection, SBOM generation, image signing, and continuous cloud posture management support continuous assurance.

Analytics can correlate identity events, API calls, deployment changes, container activity, mobile abuse patterns, and device telemetry. Machine learning may assist anomaly detection and prioritization, but it can produce false positives and should not replace evidence-based investigation. Generative tools may help summarize configurations or produce test cases, yet sensitive architecture and credentials must not be exposed to unapproved services.

Emerging practice is moving toward zero-trust architectures, confidential computing, stronger workload identity, software supply-chain provenance, passkeys, remote device attestation, edge computing, and continuous automated validation. These technologies improve assurance only when their trust assumptions are understood and operationally maintained.

Best Practices for Practitioners

Effective practice can be summarized as follows:

• Establish written scope, provider approval, safety constraints, and data-handling rules.
• Map identities, resources, trust boundaries, dependencies, and attack paths before exploitation.
• Test machine identities and deployment permissions as carefully as human accounts.
• Prefer least privilege, short-lived credentials, strong authentication, and explicit authorization.
• Validate storage, APIs, functions, containers, registries, pipelines, mobile clients, and devices as one ecosystem.
• Use synthetic data and laboratory devices whenever possible.
• Combine automated discovery with manual business-logic and configuration analysis.
• Report exploitability, impact, evidence, owner, remediation, and residual risk.
• Retest fixes and confirm that monitoring, recovery, and governance controls work.

Chapter Summary

Cloud-native, container, mobile, and IoT testing requires an integrated understanding of architecture, identity, software supply chains, APIs, workloads, devices, and physical consequences. The shared-responsibility model defines boundaries but does not remove customer accountability. IAM and workload identity often determine the blast radius of compromise. Storage, serverless functions, containers, orchestration platforms, and CI/CD pipelines must be tested as connected components. Mobile assessments require static, dynamic, and API analysis, while IoT assessments must include firmware, communications, update integrity, and safety. Ethical authorization, data minimization, controlled exploitation, continuous validation, and attack-path reporting are essential to professional practice.

Key Terms

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

IAM: Controls governing identities, authentication, authorization, and permissions.

Workload identity: A machine identity assigned to an application, function, container, or service.

Least privilege: Granting only the permissions necessary for an approved task.

Object storage: Cloud storage in which data is managed as objects within logical containers.

Serverless function: Event-triggered code executed by a provider-managed runtime.

Container: A packaged application process with its dependencies and isolated execution context.

Orchestration: Automated scheduling, networking, scaling, and management of containers.

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

CI/CD pipeline: Automated process for integrating, building, testing, and deploying software.

SBOM: A structured inventory of software components and dependencies.

API: A defined interface through which software systems exchange requests and data.

Object-level authorization: Verification that a user may access the specific requested object.

Certificate pinning: Restriction of accepted certificates or keys to trusted values.

IoT: Networked physical devices that sense, process, communicate, or act.

Firmware: Software embedded in a device that controls its hardware functions.

Attack surface: The set of interfaces and conditions through which a system may be attacked.

Threat model: A structured representation of assets, adversaries, trust boundaries, and attack paths.

Zero trust: A security approach that continuously verifies access rather than trusting network location.

Review Questions

Short Answer Questions

1. What does the cloud shared-responsibility model mean for a customer’s storage configuration?

2. Why are workload identities important in container and serverless security?

3. Distinguish authentication from authorization in API testing.

4. What is the purpose of an SBOM in a CI/CD environment?

5. Why must IoT testing consider physical safety?

Long Answer Questions

1. Explain a risk-based method for assessing IAM, storage, APIs, and serverless functions in a cloud environment.

2. Discuss the relationship between container security, Kubernetes RBAC, network policy, and workload identity.

3. Describe a comprehensive mobile application testing process and its limitations.

4. Explain how a CI/CD pipeline can become a high-impact software supply-chain target.

5. Compare the ethical and operational requirements of cloud testing with those of IoT testing.

Analytical / Application Questions

1. A function can read an entire object-storage bucket although it only generates one type of report. Analyze the risk and propose a remediation and validation plan.

2. A mobile application protects its local token with obfuscation but its API accepts any authenticated user’s account identifier. Identify the principal flaw and design an appropriate test.

3. An IoT vendor encrypts device traffic but accepts firmware updates without signature verification. Evaluate the attack path, likely consequences, and required controls.

22. Multiple Choice Questions with Answers

Question 1

Which activity best reflects the customer’s responsibility in a cloud shared-responsibility model?

A. Repairing the provider’s physical servers

B. Configuring access permissions for customer data

C. Replacing the provider’s network hardware

D. Maintaining the provider’s data-centre power systems

Correct Answer: B. Configuring access permissions for customer data

Question 2

Why can a seemingly low-risk cloud permission become high impact?

A. All cloud permissions automatically grant administrator access

B. Permissions can combine into an indirect privilege-escalation path

C. Cloud services do not record permission use

D. Low-risk permissions cannot be revoked

Correct Answer: B. Permissions can combine into an indirect privilege-escalation path

Question 3

Which control most directly reduces the blast radius of a compromised serverless function?

A. Giving the function a broad administrative role

B. Disabling all application logging

C. Assigning a narrowly scoped execution role

D. Storing credentials in source code

Correct Answer: C. Assigning a narrowly scoped execution role

Question 4

What is the principal concern with running a container in privileged mode?

A. It prevents the container from using networks

B. It may weaken isolation from the host and other workloads

C. It automatically encrypts all container data

D. It prevents image vulnerabilities from being detected

Correct Answer: B. It may weaken isolation from the host and other workloads

Question 5

Which CI/CD weakness presents the clearest software supply-chain risk?

A. A build log uses timestamps

B. A pull request executes with production deployment credentials

C. A pipeline stores test results

D. A developer uses a branch for experimental code

Correct Answer: B. A pull request executes with production deployment credentials

Question 6

A mobile API verifies that a user is authenticated but not that the requested record belongs to that user. What type of issue is most directly indicated?

A. Object-level authorization failure

B. Weak device battery management

C. Container image poisoning

D. Firmware rollback protection

Correct Answer: A. Object-level authorization failure

Question 7

Which statement about mobile security is most accurate?

A. Client-side authorization eliminates the need for server-side checks

B. Obfuscation guarantees that secrets cannot be recovered

C. The mobile client should be treated as untrusted

D. Certificate pinning replaces API authorization

Correct Answer: C. The mobile client should be treated as untrusted

Question 8

Why is firmware signature verification important in IoT systems?

A. It guarantees unlimited device availability

B. It helps ensure that only authentic approved firmware is installed

C. It eliminates the need for encrypted communication

D. It prevents every physical attack on a device

Correct Answer: B. It helps ensure that only authentic approved firmware is installed

Question 9

Which approach is most appropriate when testing a safety-critical IoT actuator?

A. Flooding the production device with arbitrary commands

B. Using a laboratory device or simulator with safety controls

C. Disabling all operational monitoring

D. Testing without notifying the operations team

Correct Answer: B. Using a laboratory device or simulator with safety controls

Question 10

What is the strongest reason for reporting cloud findings as attack paths rather than isolated warnings?

A. Attack paths show how individually limited weaknesses can combine into material impact

B. Attack paths eliminate the need for remediation advice

C. Attack paths are required only for mobile applications

D. Attack paths prevent the use of automated tools

Correct Answer: A. Attack paths show how individually limited weaknesses can combine into material impact