Devops (DVO5)

DevOps
5

Brian can escape the runtime isolation of workloads to access host resources, execute privileged operations, or use the workloads to attack other internal systems

How to play?

This card focuses on failures in workload runtime isolation, where an attacker escapes the isolation boundary to access host resources or attack other internal systems.

Scenario: Brian's Escape from Workload Isolation

Consider a scenario where Brian escapes the runtime isolation of a workload to access host resources, execute privileged operations, or attack other internal systems. This vulnerability arises from:

  1. Weak Isolation Boundaries: The runtime environment does not enforce strong enough isolation between workloads and the underlying host.
  2. Misconfigured Privileges: Workloads run with elevated privileges or capabilities that allow them to interact with host resources or other workloads.

Example

Brian discovers that a workload running in a containerized environment has been granted excessive capabilities, including access to the host's filesystem. By exploiting this misconfiguration, he escapes the container's isolation boundary and gains access to the host system. From there, he reads credentials stored on the host, accesses other workloads running on the same machine, and moves laterally through the infrastructure. In another variation, workloads share a persistent, non-ephemeral runner where previous builds leave behind files and credentials that Brian's workload can access, effectively bypassing any intended isolation.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Elevation of Privilege.

Elevation of Privilege occurs when an attacker gains access to resources or capabilities beyond their intended scope. Brian's workload is supposed to be confined to its isolated runtime environment, but by escaping that boundary, he gains access to host resources and other systems - a direct escalation of privilege.

What can go wrong?

Isolation failures expose the entire host and potentially the wider infrastructure to compromise. This can manifest in various forms, including but not limited to:

  • Access to host filesystem, credentials, or network from within a workload
  • Lateral movement to other workloads or systems sharing the same host or network
  • Exfiltration of secrets or data from the host environment
  • Compromise of the orchestration or management layer through an escaped workload
  • Contamination of shared or persistent build environments where one workload's artifacts affect another

What are we going to do about it?

  1. Run workloads with the minimum necessary privileges and capabilities. Avoid running as root or granting host-level access.
  2. Use ephemeral, single-use runners or execution environments for build and deployment tasks so that one job's leftovers cannot affect the next.
  3. Make use of the runtime's security features to restrict what workloads can do: limit filesystem access, network access, and system calls.
  4. Review your workload configurations to check for excessive privileges or capabilities that are not actually needed.
  5. If certain workloads handle sensitive data or operations (e.g., signing your artifacts), consider running them on dedicated hosts or in more tightly isolated environments.
  6. Keep the runtime and host environment up to date with security patches to reduce the risk of known isolation bypass vulnerabilities.

For detailed advice on how to mitigate threats related to the card, see the OWASP SAMM and OWASP DSOMM IDs in the table below and correlate these with the IDs in the OWASP SAMM and OWASP DSOMM documentation.

Reading the mappings

Mappings use identifiers from OWASP SAMM and OWASP DSOMM.

SAMM identifiers specify a Business Function, Security Practice and Stream. For example, V-AA breaks down as Verification - Architecture Assessment, and O-EM-A as Operations - Environment Management - Stream AĀ (Configuration Hardening). Where the identifier only specifies up to a Security Practice, both streams are relevant to the card.

DSOMM identifiers specify a Dimension and Sub-Dimension. For example, I-IH breaks down as Implementation - Infrastructure Hardening, and TV-DDI as Test and Verification - Dynamic Depth for Infrastructure. A Sub-Dimension groups multiple related activities, and is used here because the activities as a group correspond to the card's scope.

Mappings

STRIDE: Elevation of Privilege

CAPECā„¢: 480,233

OWASP SAMM: V-AA,O-EM-A

OWASP DSOMM: I-IH,TV-DDI

No attacks registered!

OWASP Cornucopia

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security requirements in Agile, conventional and formal development processes. It is language, platform and technology-agnostic, and is free to use. OWASP Cornucopia is licensed under the Creative Commons Attribution-ShareAlike 4.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar licence to this one.

Ā© 2012-2025 OWASP Foundation. The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.