6. Cloud Workload and Platform Security

Introduction and Context

Cloud computing has changed the security boundary of the enterprise. In a traditional data centre, security teams could often associate a workload with a physical server, a network segment, and a known administrative domain. In cloud environments, workloads are assembled dynamically from virtual machines, managed storage, application programming interfaces (APIs), containers, serverless functions, identity services, and software-defined networks. The same application may span several cloud regions, accounts, clusters, and service providers.

This flexibility creates substantial operational value but also introduces a distinctive security problem: the enterprise must secure not only applications and data, but also the platforms on which workloads are created, scheduled, exposed, and destroyed. A vulnerable image, an overly permissive identity, an exposed storage bucket, an unprotected API, or a misconfigured Kubernetes control plane can compromise an otherwise well-designed application.

Cloud workload and platform security therefore combines preventive hardening, isolation, secure configuration, identity governance, vulnerability management, runtime protection, monitoring, and incident response. It requires an understanding of shared responsibility. Cloud providers secure the underlying facilities, hardware, and many foundational services, while customers remain responsible for configuration, identities, data, applications, and workload security. The exact division varies according to whether the service is infrastructure, platform, or software as a service.

The central principle of this chapter is that workload security must be continuous. A secure deployment is not a one-time achievement. Images change, dependencies are updated, permissions evolve, containers are rescheduled, APIs are added, and infrastructure is modified through automation. Security controls must therefore be embedded in the entire lifecycle, from design and code creation to deployment, operation, recovery, and decommissioning.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the security characteristics and risks of cloud workloads and platforms.

2. Distinguish the security requirements of virtual machines, storage, APIs, containers, Kubernetes, microservices, serverless systems, and service meshes.

3. Apply hardening, isolation, configuration management, identity control, and runtime protection techniques.

4. Explain the role of cloud security posture management and policy-as-code.

5. Analyse a cloud workload incident and recommend a defensible security architecture.

6. Evaluate governance, compliance, operational, and ethical implications of cloud workload security.

The Cloud Workload as a Security Object

A workload is a computational unit that processes data or provides a service. It may be a virtual machine, container, function, database instance, or collection of cooperating services. A platform is the environment that provisions, schedules, connects, and monitors those workloads. Security analysis must consider both levels. Securing an individual container does not compensate for an exposed orchestration control plane; conversely, a secure Kubernetes cluster cannot protect an application containing a critical authentication flaw.

A useful model divides the workload into several protection layers:

• Identity layer: human and machine identities, authentication, authorization, credentials, and privileges.
• Control-plane layer: cloud management APIs, orchestration systems, deployment pipelines, and administrative consoles.
• Compute layer: virtual machines, containers, functions, operating systems, and runtime processes.
• Network layer: virtual networks, routing, firewalls, ingress, egress, service-to-service communication, and name resolution.
• Data layer: object, block, and file storage; databases; backups; encryption; and key management.
• Application layer: code, dependencies, APIs, business logic, and secrets.
• Monitoring and response layer: logs, telemetry, detection, investigation, containment, and recovery.

These layers are interdependent. A stolen service-account token may bypass network segmentation. A compromised build pipeline may create a malicious image that passes perimeter controls. A logging failure may allow an attack to remain undetected. Effective security consequently depends on defence in depth rather than a single protective product.

Security Foundations: Responsibility, Isolation, and Least Privilege

Shared responsibility and accountability

Shared responsibility does not mean shared ambiguity. The provider may secure the hypervisor, physical host, and managed-service infrastructure, but the customer must configure access, protect data, and manage workload software. Organisations should document responsibility matrices for each cloud service. They should identify who approves configuration changes, who rotates keys, who investigates alerts, and who can suspend a compromised workload.

Isolation

Isolation limits the impact of compromise. Virtual machines provide isolation through a hypervisor, although vulnerabilities in the guest operating system, hypervisor, or management layer remain relevant. Containers generally share the host kernel and are therefore not equivalent to virtual machines. Namespaces, control groups, seccomp profiles, Linux capabilities, and mandatory access controls reduce container privileges, but a container breakout can threaten the host and neighbouring workloads.

Isolation can also be logical and organisational. Separate cloud accounts or subscriptions, virtual networks, projects, clusters, and namespaces help limit blast radius. High-risk workloads should not share administrative boundaries with low-risk development workloads. Network segmentation should be based on trust and data flow rather than merely on organisational labels.

Least privilege and identity-centric security

Least privilege grants only the permissions required for a task, for only as long as they are required. It applies to administrators, developers, service accounts, CI/CD pipelines, functions, and Kubernetes workloads. Static credentials should be avoided where short-lived tokens, workload identity, or role-based access can be used. Privileges should be reviewed using actual access patterns, but infrequent use alone is not sufficient evidence that a permission is unnecessary; emergency and recovery functions must also be considered.

Zero-trust principles strengthen this approach by requiring explicit authentication and authorization for each relevant request. Network location is not treated as proof of trust. In a microservices environment, service identity, request context, policy, and telemetry become more important than a broad internal network boundary.

Virtual Machine Security

Virtual machines remain common for legacy applications, specialized operating systems, databases, and workloads that require stronger kernel separation than ordinary containers. Their security begins with a hardened image. Unnecessary packages, services, accounts, compilers, and network listeners should be removed or disabled. The operating system should be patched through a tested, traceable process, and host-based firewalls should restrict inbound and outbound traffic.

Administrative access should use centralized identity, multifactor authentication, controlled bastion or management channels, and session logging. Direct exposure of secure shell or remote desktop services to the public internet should be avoided. Where possible, access should be mediated by private connectivity, just-in-time authorization, or a managed session service. Disk volumes and snapshots require encryption and access control, while temporary disks and crash dumps should be considered potential sources of sensitive information.

Golden images improve consistency when they are built through a controlled pipeline, scanned for vulnerabilities, signed or otherwise attested, and assigned a clear version. Image baking alone is insufficient: running instances need vulnerability assessment, configuration validation, endpoint telemetry, and a plan for replacement. Immutable or replace-and-redeploy patterns often reduce configuration drift, but stateful systems still require carefully designed patching and migration procedures.

Storage and Data Protection

Cloud storage commonly uses object, block, or file interfaces. Each has different security characteristics. Object storage is frequently exposed through APIs and is vulnerable to incorrect public-access settings, weak bucket policies, leaked pre-signed URLs, and insufficient logging. Block storage is attached to compute instances and requires control over attachment, snapshots, encryption, and disposal. File storage introduces network access controls, identity mapping, and permissions inherited from file protocols.

A sound storage strategy includes data classification, least-privilege access, encryption in transit and at rest, managed key controls, retention policies, versioning where appropriate, and tested backups. Encryption does not correct an excessive access policy: an authorized but compromised identity may still decrypt and retrieve data. Key management should separate key administration from data administration when the risk warrants it, and key rotation should be operationally tested rather than treated as a purely theoretical requirement.

Backups must be protected from the same incident that affects production. Separate accounts, immutable retention, restricted deletion rights, and recovery testing help defend against ransomware and destructive administrative activity. Logging should record access, policy changes, key use, and deletion events, while privacy requirements should limit unnecessary collection and retention of sensitive data.

APIs and Microservices

APIs are the control surface through which users, services, and automation interact. Security must address authentication, authorization, input validation, rate limiting, error handling, schema enforcement, and observability. Authentication proves who is making a request; authorization determines whether that identity may perform the requested action on the specific object. Confusing these concepts produces insecure direct object references and horizontal privilege escalation.

API gateways can centralize TLS termination, authentication integration, quotas, threat filtering, and routing, but they are not substitutes for authorization within the application. Each service should validate relevant claims and business rules. Tokens should be short-lived and scoped. Secrets should be stored in a secrets-management service rather than source code, container images, environment files committed to repositories, or unprotected pipeline logs.

Microservices increase deployment independence but also multiply trust relationships. A service may be secure in isolation yet vulnerable through an untrusted downstream response, excessive east-west access, or inconsistent authorization. Service inventories, dependency maps, contract testing, authenticated service-to-service communication, and centralized policy enforcement are important. Observability must connect traces, logs, identities, and request identifiers so that an abnormal transaction can be investigated across services.

Containers and Kubernetes Security

Container security begins before deployment. Base images should be minimal, maintained, scanned, and obtained from trusted registries. Builds should be reproducible, dependencies pinned where practical, and images scanned for operating-system and application vulnerabilities. Images should not contain private keys, cloud credentials, debugging utilities, or unnecessary shells. Image signing and admission verification can prevent deployment of unapproved artifacts.

At runtime, containers should run as non-root users, use read-only filesystems where possible, drop unnecessary Linux capabilities, apply seccomp and mandatory access-control profiles, and use resource limits. Privileged containers, host networking, host process access, and unrestricted host-path mounts require exceptional justification. Egress controls are important because a compromised container may otherwise retrieve tools or exfiltrate data.

Kubernetes adds a control plane, API server, scheduler, controllers, nodes, namespaces, admission mechanisms, and a role-based access-control model. The Kubernetes API is a high-value target. Access should use strong authentication, narrowly scoped roles, protected service-account tokens, audit logging, and network restrictions. Cluster-admin permissions should be rare. Namespace boundaries improve organisation but are not automatically complete security boundaries; sensitive workloads may require separate clusters or stronger isolation.

Admission policies can reject images without approved provenance, containers running as root, excessive capabilities, host mounts, or missing resource limits. Network policies should restrict pod-to-pod communication according to an explicit model. Secrets should be encrypted in the control-plane datastore and managed carefully, because Kubernetes Secret objects are not automatically equivalent to a dedicated secrets vault. Nodes must be patched, monitored, and protected from unauthorised access.

Serverless Systems and Event-Driven Workloads

Serverless functions reduce infrastructure administration but shift attention toward identity, event validation, dependencies, configuration, and execution permissions. Each function should have a narrowly scoped execution role. Functions should not share a broad role merely for convenience. Event sources must be authenticated or validated, and replay, duplication, ordering, and poisoning should be considered in the design.

Short execution lifetimes do not eliminate risk. A vulnerable dependency, malicious input, exposed function URL, or excessive permission can still produce data loss. Concurrency limits, timeouts, memory controls, private connectivity, output validation, and central logging reduce exposure. Sensitive values should not be embedded in function configuration without suitable protection. Because functions are ephemeral, investigators need durable logs, traces, deployment metadata, and correlation identifiers.

Service Meshes and Runtime Protection

A service mesh places a communication layer beside or around application services, often through proxies. It can provide mutual TLS, service identity, traffic policy, retries, circuit breaking, telemetry, and controlled deployment techniques such as canary releases. Mutual TLS protects communication and authenticates services, but it does not establish that an authenticated service is authorized to access every resource. Application-level authorization remains necessary.

Meshes introduce operational complexity, certificate lifecycle requirements, policy-debugging challenges, and additional components that may themselves be attacked. Organisations should define which controls belong in the mesh and which belong in application code or the API gateway. Runtime protection may also use host agents, container-aware detection, behaviour analytics, file-integrity monitoring, and runtime vulnerability signals. Controls should be tuned to reduce false positives without concealing meaningful deviations.

Configuration Management and Cloud Security Posture Management

Configuration drift occurs when deployed resources diverge from approved design. Manual changes, emergency fixes, copied templates, inherited permissions, and inconsistent regional settings are common causes. Infrastructure as code (IaC) addresses this by representing networks, identities, policies, and workloads in reviewable, version-controlled files. However, IaC can reproduce insecure configurations at scale; it must therefore be tested and governed.

Policy-as-code expresses requirements in machine-evaluable form. Examples include prohibiting public storage, requiring encryption, restricting geographic deployment, enforcing approved images, and preventing unrestricted administrative ports. Policies may be applied during code review, in CI/CD pipelines, at deployment admission, and continuously in production.

Cloud security posture management (CSPM) discovers assets, compares configurations with standards, prioritizes misconfigurations, and tracks remediation. Effective CSPM is not simply a dashboard of findings. It requires asset inventory, ownership, risk context, dependency analysis, exception management, automated remediation where safe, and measurement of remediation time. A public development bucket and a public database containing regulated information should not receive identical priority. CSPM should be integrated with ticketing, change management, security information and event management, and incident-response processes.

A mature control loop is: discover, assess, prioritize, remediate, verify, and learn. Exceptions should have an owner, justification, compensating controls, expiry date, and review. Security posture metrics may include percentage of assets inventoried, critical findings beyond service-level targets, privileged identities without strong authentication, image provenance coverage, and tested recovery success.

A Secure Workload Lifecycle

Security is most economical when introduced early. During design, teams should classify data, identify trust boundaries, model threats, define recovery objectives, and select suitable compute and isolation models. During development, secure coding, dependency analysis, secret detection, IaC scanning, and peer review should be integrated into normal workflows.

During build and release, the organisation should establish provenance for source, dependencies, build tools, and artifacts. Pipeline identities must be restricted, build environments protected, and approvals proportionate to risk. Deployment controls should verify signatures, configurations, permissions, and policy compliance. In operation, monitoring should cover control-plane events, workload behaviour, identity use, data access, and network flows.

When an incident occurs, response teams need authority and rehearsed procedures. Containment may involve disabling a role, revoking tokens, isolating a namespace, blocking an endpoint, quarantining an instance, or restoring from an immutable backup. Evidence must be preserved before destructive action when feasible. Post-incident analysis should address enabling conditions, not merely the final compromised resource.

Applied Case: Compromise of an Illustrative E-Commerce Platform

Background

Northstar Retail, a fictional online retailer, operates a Kubernetes-based platform across two cloud regions. Its architecture includes an API gateway, product and order microservices, object storage for invoices, a managed database, and serverless image-processing functions. Infrastructure is deployed through IaC, but development teams retain broad permissions for rapid releases.

Situation and problem

A developer accidentally commits a cloud access token to a public repository. An attacker uses it to enumerate storage and Kubernetes resources. The token belongs to a deployment role that can read customer invoices, update a container deployment, and create a service account. The attacker deploys a modified image containing a data-exfiltration process and uses an overly permissive network policy to reach the invoice bucket.

Analysis

The immediate cause is credential exposure, but the deeper causes are excessive role permissions, inadequate secret scanning, weak image admission controls, broad east-west connectivity, and insufficient monitoring of unusual deployment activity. Encryption at rest does not prevent access by a compromised authorized role. The incident also demonstrates that the control plane, supply chain, runtime, and data layer are connected.

Strategy and solution

Northstar first revokes the exposed token, rotates related credentials, freezes nonessential deployments, and isolates the affected namespace. It preserves audit logs, image digests, deployment history, and storage-access records. The malicious image is blocked by an admission policy, and affected workloads are redeployed from verified images.

The organisation then replaces long-lived deployment credentials with workload identity and separates build, deployment, and production roles. The deployment role receives only the permissions required for specified namespaces and resources. Secret scanning becomes mandatory at commit and pipeline stages. Images must originate from an approved registry, pass vulnerability and provenance checks, and be signed before admission.

Network policies are redesigned around service flows, and the invoice bucket accepts access only from the approved processing identity. Storage access logging is forwarded to a central monitoring platform. Alerts are created for unusual role use, new service-account creation, deployment outside approved pipelines, and abnormal invoice downloads. Recovery exercises test both data restoration and credential-compromise procedures.

Outcome

The incident is contained without relying on a single perimeter control. Northstar reduces the attacker’s available privileges, limits movement between services, improves artifact trust, and gains better evidence for future investigations. The organisation also discovers that its original CSPM process identified public-access risks but did not evaluate deployment-role privilege or workload identity relationships.

Learning points

1. Credential exposure is often an identity-governance problem as well as a developer error.

2. Admission control and artifact provenance can prevent a compromised build from becoming a running workload.

3. Network segmentation, least privilege, and storage policy must be designed together.

4. CSPM findings become valuable only when connected to ownership, risk, remediation, and verification.

5. Incident readiness depends on durable telemetry and rehearsed authority to revoke access and isolate workloads.

Challenges, Governance, and Professional Responsibility

Cloud environments create tension between delivery speed and control. Excessive approval gates encourage circumvention, while unrestricted self-service creates unmanaged risk. Security teams should use risk-based controls, automated guardrails, reusable secure templates, and developer-facing feedback rather than relying solely on manual review.

Important limitations must also be acknowledged. Automated scanners produce false positives and may miss business-logic flaws. Compliance benchmarks indicate baseline configuration but do not prove that a system is secure. Service meshes can obscure application behaviour if telemetry is poorly designed. Containers reduce packaging friction but do not remove the need for host and kernel security. Managed services reduce operational burden but may reduce visibility and constrain response options.

Governance should address data residency, privacy, retention, lawful access, third-party processing, auditability, software licensing, and cross-border transfers. Security monitoring must be proportionate and transparent, especially where employee or customer behaviour is analysed. Organisations should avoid collecting more telemetry than necessary and should protect logs because they may contain identifiers, tokens, request data, or personal information.

Current Developments and Emerging Directions

Cloud workload security is increasingly influenced by software supply-chain security, confidential computing, identity-aware networking, and automated policy enforcement. Confidential-computing technologies seek to protect data while it is being processed through hardware-supported trusted execution environments, although attestation, key release, performance, and operational integration remain important considerations.

Software bills of materials, artifact signing, provenance attestations, and verifiable build processes are becoming central to supply-chain assurance. Runtime security is also moving toward eBPF-based observability and behaviour detection, though these capabilities require careful privilege management and tuning. Artificial intelligence can assist with alert prioritization, configuration analysis, attack-path discovery, and anomaly detection. It should support, not replace, human validation: generated remediation can create widespread outages if context and dependencies are misunderstood.

Platform engineering is encouraging the creation of approved internal platforms that provide secure defaults, reusable templates, identity integration, and automated compliance evidence. The strategic objective is not to add security after deployment, but to make the secure path the easiest path for engineering teams.

Best Practices for Practitioners

A defensible cloud workload program should:

• Maintain a complete inventory of accounts, clusters, workloads, identities, data stores, and dependencies.
• Use separate environments and administrative boundaries for development, testing, and production.
• Prefer short-lived, federated workload identities over embedded credentials.
• Build minimal, patched, signed, and traceable images from approved sources.
• Enforce least privilege for users, services, functions, pipelines, and orchestration components.
• Treat APIs, storage policies, network routes, and cloud control-plane permissions as security-critical code.
• Apply policy-as-code and continuously verify deployed state against intended state.
• Protect control planes, admission paths, secrets, logs, backups, and recovery mechanisms.
• Combine preventive controls with runtime detection and tested incident response.
• Measure remediation, recovery, and control effectiveness rather than merely counting tools or alerts.

Chapter Summary

Cloud workload and platform security protects the compute, identity, network, data, application, orchestration, and control-plane elements that support cloud services. Virtual machines require hardened images, patching, controlled administration, and monitoring. Storage requires classification, access control, encryption, key governance, protected backups, and logging. APIs and microservices require strong authentication, object-level authorization, input validation, secrets management, and service-aware observability.

Containers and Kubernetes demand image assurance, non-root execution, restricted capabilities, network policies, protected service accounts, admission controls, and secure control-plane operations. Serverless systems shift emphasis toward execution roles, event validation, dependency security, and durable telemetry. Service meshes can provide mutual TLS and traffic policy but do not remove the need for application authorization. IaC, policy-as-code, and CSPM create a continuous control loop for detecting and correcting drift. Across all models, least privilege, isolation, provenance, runtime protection, evidence, recovery, and accountable governance are essential.

Key Terms

Workload: A computational unit that processes data or provides a service.

Cloud control plane: The management layer through which cloud resources and policies are created or modified.

Shared responsibility: The division of security duties between a cloud provider and its customer.

Isolation: Separation of workloads or components to limit interference and blast radius.

Least privilege: Granting only the permissions necessary for an identity or process to perform its task.

Workload identity: An identity assigned to an application, service, or machine process.

Golden image: An approved, hardened, and versioned image used as a deployment baseline.

Configuration drift: Divergence between intended secure configuration and actual deployed configuration.

Container: An isolated process environment that generally shares the host operating-system kernel.

Kubernetes: A platform for orchestrating, scheduling, and managing containerized workloads.

Admission control: A deployment-time mechanism that validates or rejects workload requests.

Service account: A non-human identity used by an application, workload, or automation process.

API gateway: A managed entry point that can route, authenticate, limit, and monitor API traffic.

Service mesh: A communication infrastructure layer that manages service-to-service traffic and identity.

Mutual TLS: A protocol arrangement in which both communicating parties authenticate using certificates.

Infrastructure as code: The representation and management of infrastructure through version-controlled definitions.

Policy-as-code: Machine-evaluable rules that enforce security or compliance requirements.

CSPM: Cloud security posture management, involving discovery, assessment, prioritization, and remediation of cloud misconfigurations.

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

Runtime protection: Controls that detect or prevent malicious or abnormal behaviour during execution.

Review Questions

Short Answer Questions

1. What is meant by the shared-responsibility model in cloud security?

2. Why are containers not automatically equivalent to virtual machines in terms of isolation?

3. What is the difference between API authentication and authorization?

4. State two security benefits of infrastructure as code.

5. Why should cloud backups be protected from the same administrative boundary as production systems?

Long Answer Questions

1. Explain a layered security architecture for cloud workloads, including identity, control plane, compute, network, data, application, and monitoring layers.

2. Discuss the security controls required for a production Kubernetes cluster.

3. Compare the security responsibilities and risks of virtual machines, containers, and serverless functions.

4. Explain how CSPM, policy-as-code, and configuration management operate as a continuous security control loop.

5. Discuss the role of service meshes in microservice security and explain their limitations.

Analytical / Application Questions

1. A deployment pipeline has permission to create resources across every production account. Analyse the risks and propose a redesigned identity and authorization model.

2. A public object-storage bucket contains encrypted customer records, and access logs show downloads by an unfamiliar service identity. Determine the likely security issues and outline an incident-response plan.

3. A Kubernetes application requires a privileged container, host networking, and unrestricted outbound access. Evaluate the request and design compensating controls or an alternative architecture.

22. Multiple Choice Questions with Answers

Question 1

Which control most directly limits the impact of a compromised Kubernetes service account?

A. Increasing container CPU limits

B. Assigning a narrowly scoped role and restricting its namespace access

C. Enabling object-storage versioning

D. Increasing API gateway timeout values

Correct Answer: B. Assigning a narrowly scoped role and restricting its namespace access

Question 2

Why does encryption at rest not by itself prevent data theft from cloud storage?

A. Encrypted data cannot be logged

B. Encryption prevents all authorized access

C. A compromised authorized identity may still retrieve and decrypt the data

D. Encryption applies only to virtual machines

Correct Answer: C. A compromised authorized identity may still retrieve and decrypt the data

Question 3

Which practice best protects a container supply chain?

A. Allowing images from any public registry

B. Embedding credentials in the image for convenience

C. Using signed images from approved sources and verifying them at admission

D. Running every container as root

Correct Answer: C. Using signed images from approved sources and verifying them at admission

Question 4

A service mesh provides mutual TLS between two services. What additional control is still required?

A. Object-level authorization for the requested resource

B. Disabling all service identities

C. Removing application logging

D. Making both services publicly accessible

Correct Answer: A. Object-level authorization for the requested resource

Question 5

What is the primary purpose of CSPM?

A. To replace application security testing

B. To discover, assess, prioritize, and remediate cloud configuration risks

C. To encrypt every network packet using one universal key

D. To compile container source code

Correct Answer: B. To discover, assess, prioritize, and remediate cloud configuration risks

Question 6

Which design most closely follows least privilege for a serverless function?

A. Giving every function administrator access

B. Sharing one broad role across all functions

C. Giving the function only the permissions needed for its specific event and task

D. Removing authentication from its event source

Correct Answer: C. Giving the function only the permissions needed for its specific event and task

Question 7

In the Northstar case, which combination best addressed the root causes?

A. A larger public subnet and longer-lived credentials

B. Credential rotation, workload identity, image admission, and restrictive network policies

C. Disabling all audit logs to improve performance

D. Encrypting only the developer repository

Correct Answer: B. Credential rotation, workload identity, image admission, and restrictive network policies

Question 8

What is configuration drift?

A. A change in cloud-provider pricing

B. A difference between approved intended configuration and deployed configuration

C. A failure of TLS certificate validation only

D. A reduction in container CPU usage

Correct Answer: B. A difference between approved intended configuration and deployed configuration

Question 9

Which action provides the strongest protection against destructive attacks on production backups?

A. Giving production administrators unrestricted deletion rights

B. Storing backups in the same account with identical privileges

C. Using separate administrative boundaries and immutable retention

D. Disabling recovery testing

Correct Answer: C. Using separate administrative boundaries and immutable retention

Question 10

Why should a deployment role normally be separated from a build role?

A. Separation reduces the ability of a compromised build process to directly modify production

B. Build roles cannot access source code

C. Deployment roles are used only by human users

D. Separation eliminates the need for image scanning

Correct Answer: A. Separation reduces the ability of a compromised build process to directly modify production