From 8ffc11423083c82b966abf0a96e90b0a2e71d16b Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 01/14] Move sandboxing/isolation guidance from AI Security to DevSecOps (issue #398) (cherry picked from commit 6f4e19c5657798d505e912f9b126fe4e85dc3a0d) --- ...i-execution-sandboxing-practical-guide.mdx | 213 +---------------- .../ai-security/ai-execution-sandboxing.mdx | 50 +--- ...pability-based-isolation-for-ai-agents.mdx | 44 +--- docs/pages/ai-security/index.mdx | 12 +- ...and-resource-isolation-in-ai-sandboxes.mdx | 45 +--- docs/pages/ai-security/overview.mdx | 7 +- ...mplement-to-execution-path-enforcement.mdx | 43 +--- ...andboxing-for-tool-and-execution-calls.mdx | 49 +--- docs/pages/certs/index.mdx | 1 + docs/pages/config/index.mdx | 15 ++ ...i-execution-sandboxing-practical-guide.mdx | 220 ++++++++++++++++++ .../devsecops/ai-execution-sandboxing.mdx | 57 +++++ ...pability-based-isolation-for-ai-agents.mdx | 49 ++++ docs/pages/devsecops/index.mdx | 7 + ...and-resource-isolation-in-ai-sandboxes.mdx | 50 ++++ docs/pages/devsecops/overview.mdx | 2 + .../devsecops/sandboxing-and-isolation.mdx | 44 ++++ ...mplement-to-execution-path-enforcement.mdx | 47 ++++ ...andboxing-for-tool-and-execution-calls.mdx | 54 +++++ utils/fetched-tags.json | 77 ++++++ vocs.config.tsx | 14 +- 21 files changed, 674 insertions(+), 426 deletions(-) create mode 100644 docs/pages/config/index.mdx create mode 100644 docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx create mode 100644 docs/pages/devsecops/ai-execution-sandboxing.mdx create mode 100644 docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx create mode 100644 docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx create mode 100644 docs/pages/devsecops/sandboxing-and-isolation.mdx create mode 100644 docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx create mode 100644 docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx diff --git a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx index 950ebacd..e458c579 100644 --- a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx +++ b/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx @@ -1,213 +1,12 @@ --- -title: "AI Execution Sandboxing: A Practical Guide | SEAL" -description: "Practical AI sandboxing guide with threat modeling, isolation options, and deployment-depth recommendations for developers and non-developers." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "ai execution sandboxing practical guide (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# AI Execution Sandboxing: A Practical Guide +- **New location:** [/devsecops/ai-execution-sandboxing-practical-guide](/devsecops/ai-execution-sandboxing-practical-guide) - - - -AI systems have reached a turning point. They are no longer limited to generating text inside chat windows. Many now -execute code, browse the web, call APIs, manage local files, and connect directly to production systems. As models -evolve into agents that can take action, the security model shifts with them. If an AI agent has shell access, it -inherits the same permissions as the user. It can read files, run commands, and authenticate to connected services. -Security tools such as firewalls, antivirus software, and endpoint monitoring were built to track malicious software or -suspicious users. They are not equipped to tell the difference between a legitimate user action and an AI agent acting -on a manipulated prompt. - -## Clear Boundaries Around Access, Execution, and Data Exposure - -Sandboxing fills this gap by limiting what an AI system can see and do from the outset. Instead of relying only on -detection after something goes wrong, sandboxing creates clear boundaries around access, execution, and data exposure. -It reduces the potential blast radius, enforces privilege constraints, and contains unintended side effects whether the -issue stems from a malicious prompt, a design flaw, or a simple model error. For organizations deploying AI agents that -interact with real systems, isolation is a core requirement rather than an optional safeguard. - -## Technical Capability and Risk Tolerance - -There is a wide range of sandboxing approaches, depending on technical capability and risk tolerance. For many -non-technical users, browser-based AI tools already offer a layer of separation, since applications running in a tab -cannot freely access the local filesystem or installed software. Developers often turn to Docker containers or remote -virtual machines to create controlled execution environments. At higher levels of assurance, infrastructure teams may -rely on microVM technologies such as Firecracker or gVisor, or hardened operating systems like Qubes OS. The right -approach depends on what the agent can access, what authority it holds, and how severe the consequences of misuse might -be. This calculation becomes especially important in Web3 contexts, where agents may control wallets, interact with -immutable smart contracts, or execute transactions that cannot be undone. - ---- - -The guidance that follows offers practical recommendations for implementing sandboxing across different levels of -expertise and deployment models. It builds on established security principles such as least privilege and layered -isolation, while addressing the distinct behavior of AI-driven systems. Whether you are experimenting locally or -deploying agents in production, the goal is to move from general awareness to concrete safeguards that reduce risk in -meaningful ways. - -## Quick Reference: Sandboxing Recommendations by Technical Level - -### For Non-Developers - -Most users interacting with AI tools through web interfaces already benefit from browser-level sandboxing. The following -options provide escalating levels of isolation for those who require additional protection: - -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Browser-based AI | None | Strong | ChatGPT, Claude web interfaces. Already sandboxed by the browser with no configuration required. | -| Local VM (Parallels, VMware) | Medium | Strong | Running AI tools in a fully isolated virtual machine on your local hardware. | -| Dedicated Machine | High | Strong | Using a separate physical device exclusively for AI tools, providing complete hardware-level isolation. | - -Recommendation: Start with browser-based AI tools, as they are already sandboxed by default. If you need to install AI -software locally, run it inside a virtual machine using Parallels or VMware for strong isolation without requiring deep -technical expertise. - -### For Developers - -Developer workflows demand flexible sandboxing that accommodates rapid iteration while maintaining meaningful isolation -boundaries. The following options balance security strength against operational overhead: - -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Docker Containers | Low | Moderate | Quick containerized isolation for CLI tools and agents. Shares the host kernel, providing a thinner isolation boundary. | -| Remote VMs (Modal, Sprites) | Low | Strong | Cloud-based sandboxes with pay-per-use pricing. Isolation is managed by the service provider. | -| Local VMs (Parallels, VMware, VirtualBox) | Medium | Strong | Full OS-level isolation on your own hardware with complete control over the environment. | -| Specialized Sandboxes (gVisor, Firecracker) | High | Strong | Production-grade isolation designed for multi-tenant workloads at scale. Purpose-built for running untrusted code. | - -Recommendation: For local experimentation with AI agents, use Docker or a remote VM service like Modal. For maximum -isolation on your own machine, run a full VM with Parallels or VMware. Specialized tools like gVisor and Firecracker -are designed for production infrastructure deployments rather than local development. - -## Why Sandboxing Matters Now - -AI systems have crossed a critical threshold: they can now take actions in the real world through code execution, web -browsing, and API interactions. This transforms mistakes or malicious inputs into tangible side effects including -deleted files, exfiltrated credentials, unauthorized purchases, and irreversible on-chain transactions. Native -applications like Claude Cowork and OpenAI Codex change the threat surface further by operating closer to the host -machine and generating new code that can produce unexpected behavior once executed or integrated into existing systems. - -## The Threat Model - -A practical threat model for AI sandboxing answers three fundamental questions: what assets are at risk (files, -credentials, accounts, billing limits, reputation), what entry points exist (prompts, uploaded files, web pages, tool -outputs, plugin responses), and what permissions the system holds (filesystem access, network egress, API scopes, -command execution). The following table catalogs the primary threat categories that sandboxing must address: - -| Threat | Description | Example | -| --- | --- | --- | -| Data Exfiltration | AI sends sensitive data to external servers | Agent uploads SSH keys while performing routine backup operations | -| Destructive Actions | AI deletes or corrupts files and data | Agent executes recursive file deletion while cleaning temporary directories | -| Resource Exhaustion | AI consumes excessive compute, memory, or network bandwidth | Agent spawns infinite subprocess loops or initiates multi-gigabyte downloads | -| Privilege Escalation | AI gains access beyond its intended scope | Agent modifies system configuration files or installs persistent access tools | -| Lateral Movement | AI accesses adjacent systems via discovered credentials | Agent uses cloud provider keys to provision unauthorized compute resources | -| Prompt Injection | External content hijacks agent behavior | Malicious webpage embeds hidden instructions that the agent follows | -| Supply Chain Compromise | AI is compromised through third-party dependencies | Malicious model weights or plugin code introduces persistent backdoors | - -## Why Traditional Security Is Insufficient - -Conventional security tools were designed to distinguish between trusted users and untrusted code. AI agents -fundamentally blur this distinction as they run with user-level permissions, making requests that are indistinguishable -from intentional human actions. A firewall can block connections to known malicious endpoints, but it cannot determine -whether an HTTP POST to a legitimate API represents the user pushing code or an agent exfiltrating private -repositories. The attack surface of an AI agent with shell access is functionally equivalent to the user's entire -environment: every readable file, every executable command, every authenticated service. Sandboxing addresses these -gaps by constraining what the AI can access in the first place, providing defense in depth for an era where the agent -is the user. - -## A Brief History of Sandboxing - -The concept of sandboxing has deep roots in computer science, evolving over decades as systems grew more complex and -security threats more sophisticated. Understanding this evolution provides essential context for modern AI sandboxing -approaches. - -- **Multi-User Systems (1960s-1990s):** The need for isolation originated with mainframe computing. IBM's System/360 - introduced memory protection to prevent one user's program from accessing another's memory space. As computing - transitioned to desktop and server architectures, multi-user operating systems like Unix carried this principle - forward through per-user home directories, file permissions, and process isolation. -- **The Virtualization Era (1970s-2000s):** IBM's VM/370 (1972) enabled multiple operating systems to run on a single - machine in complete isolation. This technology was commercialized for x86 systems by VMware in 1999, making full - OS-level isolation accessible to mainstream computing. Virtual machines remain one of the strongest isolation options - available today. -- **The Container Revolution (2008-2013):** Linux Containers (LXC) emerged in 2008, leveraging kernel features like - cgroups and namespaces to create lightweight containerized environments. Docker (2013) made containerization - accessible to mainstream developers. Containers provide faster startup and lower resource overhead than VMs but share - the host kernel, resulting in a thinner isolation boundary. -- **Browser Sandboxing (2008-Present):** Google Chrome's multi-process architecture (2008) introduced per-tab - sandboxing that became the industry standard. Modern browsers employ multiple isolation layers including site - isolation and WebAssembly sandboxing, which is why web-based AI tools benefit from meaningful isolation by default. -- **Microkernels and Lightweight VMs (2010s-Present):** Projects like gVisor (Google, 2018) and Firecracker (AWS, - 2018) represent the current state of the art: user-space kernels and lightweight virtual machines designed - specifically for running untrusted workloads with minimal overhead. These technologies power the isolation behind - services like AWS Lambda and Google Cloud Run, and are increasingly relevant for production AI workloads. - -## What Is an AI Sandbox? - -An AI sandbox is a controlled, containerized, and sometimes isolated environment designed to contain and monitor AI -system behavior. It creates boundaries that limit what an AI can access and modify, ensuring that even if a model is -compromised or produces unexpected behavior, the impact remains contained within the sandbox boundaries. Effective AI -sandboxes share four key characteristics: isolation (complete separation from production systems and sensitive data), -monitoring (comprehensive logging and observation of all AI actions), resource limits (controlled access to compute, -memory, and network resources), and reversibility (the ability to reset the environment to a known good state). - -## Types of AI Sandboxes - -- **Browser Sandboxes:** Web browsers already execute code in sandboxed environments. When using ChatGPT, Claude, or - other web-based AI tools, the browser isolates them from the rest of the system as they cannot access local files, - install software, or make changes outside the browser tab. File access operates on a whitelist model: users - explicitly upload documents they want the AI to process, which is the inverse of local AI agents that often have - default access to the entire filesystem. For most users, browser-based sandboxing provides sufficient isolation - without any additional configuration. -- **Container-Based Sandboxes:** Technologies like Docker and DevContainers partition AI systems at the operating - system level. Containers share the host kernel but maintain their own filesystem, process space, and network stack. - This provides meaningful isolation with faster startup and lower resource consumption than full virtualization, - making containers well-suited for development workflows and CI/CD pipeline integration. -- **Virtual Machine Sandboxes:** Full virtualization provides the strongest isolation available for local deployment. - Each VM runs its own complete operating system, ensuring that a compromised AI agent inside a VM has no direct path - to the host machine. The tradeoff is higher resource consumption and slower startup times, along with the operational - overhead of maintaining a separate operating system installation. - -## Selecting the Appropriate Sandbox Depth - -The appropriate depth of sandboxing should match your risk tolerance, technical capability, and the sensitivity of -systems the AI agent can access. The spectrum ranges from browser-based isolation requiring zero configuration to -production-grade microVM infrastructure designed for multi-tenant untrusted workloads. The key principle is that -isolation depth should scale with the consequences of a potential breach: AI tools that can only read uploaded -documents require less isolation than agents with shell access, which in turn require less isolation than agents that -can sign blockchain transactions or execute financial operations. - -- **Surface Level - Minimal Setup:** Browser sandboxes (web-based AI tools) and dedicated user accounts or machines. - These require minimal technical expertise and provide strong baseline isolation for casual AI usage. -- **Mid-Depth - Developer-Oriented:** Docker containers, DevContainers, local VMs (Parallels, VMware, VirtualBox, - UTM), and remote VMs (Modal, Sprites). These provide meaningful isolation for development workflows and agent - experimentation with moderate configuration overhead. -- **Deep Isolation - Production-Grade:** Firecracker, gVisor, Qubes OS, nsjail, and bubblewrap. These represent the - highest levels of isolation available and are appropriate for production infrastructure, multi-tenant deployments, - and environments where AI agents interact with high-value assets or irreversible operations. - -## Conclusion - -AI sandboxes represent a critical component in the responsible deployment of artificial intelligence systems. By -providing controlled environments that contain and constrain AI behavior, they bridge the gap between the expanding -capabilities of AI agents and the security requirements of production systems. As AI systems continue to gain autonomy -by executing code, managing infrastructure, and interacting with financial protocols, the necessary investment in -robust sandboxing infrastructure is not merely a best practice but a prerequisite for building AI systems that -organizations and users can trust. - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/ai-execution-sandboxing.mdx b/docs/pages/ai-security/ai-execution-sandboxing.mdx index 61b4db82..e974410e 100644 --- a/docs/pages/ai-security/ai-execution-sandboxing.mdx +++ b/docs/pages/ai-security/ai-execution-sandboxing.mdx @@ -1,50 +1,12 @@ --- -title: "AI Execution Sandboxing | SEAL" -description: "AI sandboxing foundations for isolating model and agent behavior across tool and execution paths." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "ai execution sandboxing (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# AI Execution Sandboxing +- **New location:** [/devsecops/ai-execution-sandboxing](/devsecops/ai-execution-sandboxing) - - - -AI execution sandboxing is the practice of isolating model execution and agent actions within tightly constrained -environments that limit blast radius, privilege, and side effects. As AI systems gain the ability to read files, call -tools, execute code, and interact with external systems, sandboxing becomes a primary security control rather than an -optional safeguard. - -## Predefined Boundaries and Runtime Enforcement - -Effective sandboxing ensures that even if a model is manipulated through prompt injection or -adversarial input, the resulting behavior cannot escape predefined boundaries. In production, sandboxes must be -enforced at runtime and applied consistently across text, document, image, and tool execution paths. For Web3 agents, -sandboxing is especially critical when interacting with wallets, signing flows, or smart contract interfaces, where -unintended actions can be irreversible. - -## Consider using - -- Modal - cloud-based sandboxed execution environments for AI agent workloads -- Firecracker (AWS) - lightweight microVMs for untrusted workload isolation -- Docker sandbox patterns for fast development-stage containment -- Parallels, VMware, VirtualBox, UTM, or Qemu for VM-level isolation -- E2B - cloud sandboxes purpose-built for AI agents and code execution - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx b/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx index d62e124f..9b64df0b 100644 --- a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx +++ b/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx @@ -1,44 +1,12 @@ --- -title: "Capability-Based Isolation for AI Agents | SEAL" -description: "Capability-scoped isolation patterns for AI agents operating across tools, APIs, and external systems." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "capability based isolation for ai agents (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# Capability-Based Isolation for AI Agents +- **New location:** [/devsecops/capability-based-isolation-for-ai-agents](/devsecops/capability-based-isolation-for-ai-agents) - - - -Traditional sandboxing approaches often rely on coarse-grained isolation, such as container boundaries or virtual -machines, which are insufficient for agentic AI systems that operate across multiple tools and services. -Capability-based isolation refines sandboxing by explicitly defining which actions an agent is permitted to perform and -under what conditions. Rather than granting broad access to file systems, networks, or APIs, agents are issued narrowly -scoped capabilities that are evaluated at execution time. This model aligns security controls with actual behavior -rather than assumed intent. In practice, capability-based isolation allows organizations to safely deploy agents that -can read data without writing, query systems without mutating state, or simulate actions without executing them. In -decentralized systems, this approach maps naturally to permissioned contract calls and limited signing authority. - -## Consider using - -- Zenity - secure-by-design policy checks on agent permissions and tool access -- Palo Alto Prisma AIRS - runtime model inspection and granular capability controls -- Operant AI - MCP gateway authentication and capability boundary enforcement -- Cisco AI Defense - capability-scoped guardrails integrated in AI development flow - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/index.mdx b/docs/pages/ai-security/index.mdx index bec5a4b0..166dcd3e 100644 --- a/docs/pages/ai-security/index.mdx +++ b/docs/pages/ai-security/index.mdx @@ -17,9 +17,9 @@ title: "Ai Security" - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) -- [AI Execution Sandboxing](/ai-security/ai-execution-sandboxing) -- [Capability-Based Isolation for AI Agents](/ai-security/capability-based-isolation-for-ai-agents) -- [Sandboxing for Tool and Execution Calls](/ai-security/sandboxing-for-tool-and-execution-calls) -- [Network and Resource Isolation in AI Sandboxes](/ai-security/network-and-resource-isolation-in-ai-sandboxes) -- [Sandboxing as a Complement to Execution-Path Enforcement](/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement) -- [AI Execution Sandboxing: A Practical Guide](/ai-security/ai-execution-sandboxing-practical-guide) +- [ai execution sandboxing (moved)](/ai-security/ai-execution-sandboxing) +- [ai execution sandboxing practical guide (moved)](/ai-security/ai-execution-sandboxing-practical-guide) +- [capability based isolation for ai agents (moved)](/ai-security/capability-based-isolation-for-ai-agents) +- [network and resource isolation in ai sandboxes (moved)](/ai-security/network-and-resource-isolation-in-ai-sandboxes) +- [sandboxing as a complement to execution path enforcement (moved)](/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement) +- [sandboxing for tool and execution calls (moved)](/ai-security/sandboxing-for-tool-and-execution-calls) diff --git a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx index bfe0c987..f5ea3cb3 100644 --- a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx +++ b/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx @@ -1,45 +1,12 @@ --- -title: "Network and Resource Isolation in AI Sandboxes | SEAL" -description: "Deny-by-default network and compute isolation strategy for sandboxed AI workloads." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "network and resource isolation in ai sandboxes (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# Network and Resource Isolation in AI Sandboxes +- **New location:** [/devsecops/network-and-resource-isolation-in-ai-sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) - - - -Network access is one of the most powerful and dangerous capabilities granted to AI systems. Without isolation, models -can be manipulated into exfiltrating data, scanning internal services, or interacting with untrusted external -endpoints. AI sandboxes must enforce strict network policies that default to denial and explicitly allow only required -destinations and protocols. Resource isolation, including CPU, memory, and storage limits, is equally important to -prevent denial-of-service conditions or runaway execution. These controls should be applied dynamically based on agent -role and context rather than statically configured per deployment. In environments where AI agents interact with -decentralized networks, resource and network isolation help prevent unintended propagation across nodes or chains. - -## Consider using - -- Cloudflare - edge DLP and network policy controls for AI traffic -- AccuKnox - zero trust eBPF runtime enforcement for containerized AI workloads -- gVisor (Google) - user-space kernel for granular syscall and network mediation -- Operant AI - API discovery and runtime network access controls for agent ecosystems - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/overview.mdx b/docs/pages/ai-security/overview.mdx index 3657aed8..bff86a34 100644 --- a/docs/pages/ai-security/overview.mdx +++ b/docs/pages/ai-security/overview.mdx @@ -124,12 +124,7 @@ specific deployment models and risk tolerance. - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) -- [AI Execution Sandboxing](/ai-security/ai-execution-sandboxing) -- [Capability-Based Isolation for AI Agents](/ai-security/capability-based-isolation-for-ai-agents) -- [Sandboxing for Tool and Execution Calls](/ai-security/sandboxing-for-tool-and-execution-calls) -- [Network and Resource Isolation in AI Sandboxes](/ai-security/network-and-resource-isolation-in-ai-sandboxes) -- [Sandboxing as a Complement to Execution-Path Enforcement](/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement) -- [AI Execution Sandboxing: A Practical Guide](/ai-security/ai-execution-sandboxing-practical-guide) +- [Sandboxing & Isolation (canonical)](/devsecops/sandboxing-and-isolation) --- diff --git a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx index 1374dbe2..ddcaa130 100644 --- a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx +++ b/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx @@ -1,43 +1,12 @@ --- -title: "Sandboxing as a Complement to Execution-Path Enforcement | SEAL" -description: "Defense-in-depth model combining execution-path policy controls with sandbox isolation boundaries." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "sandboxing as a complement to execution path enforcement (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# Sandboxing as a Complement to Execution-Path Enforcement +- **New location:** [/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) - - - -Sandboxing alone does not solve AI security, but it is a necessary complement to execution-path enforcement. While -execution-path controls determine whether an action should occur, sandboxing constrains what happens if an action is -allowed. Together, these mechanisms ensure that AI systems remain safe even under partial failure or misclassification. -Sandboxing provides defense in depth by limiting the impact of mistakes, adversarial behavior, or unforeseen -interactions between modalities. In production, sandboxing should be treated as an always-on control rather than a -development-time feature, with continuous validation that isolation boundaries remain intact as systems evolve. - -## Consider using - -- Palo Alto Prisma AIRS + Firecracker - posture management plus runtime microVM guardrails -- Zenity + gVisor - agent-level execution monitoring plus kernel-level isolation -- Cisco AI Defense + E2B - MCP inspection plus isolated code execution sandboxes -- Operant AI + AccuKnox - application-level agent controls plus eBPF infrastructure enforcement - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx index 3b38de95..b65be432 100644 --- a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx +++ b/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx @@ -1,49 +1,12 @@ --- -title: "Sandboxing for Tool and Execution Calls | SEAL" -description: "High-risk tool invocation controls for AI agents with sandboxed execution and runtime policy checks." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "sandboxing for tool and execution calls (moved) | SEAL" +description: "This page moved to DevSecOps (canonical location)." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This content moved - - +The canonical version of this page now lives under **DevSecOps**: -# Sandboxing for Tool and Execution Calls +- **New location:** [/devsecops/sandboxing-for-tool-and-execution-calls](/devsecops/sandboxing-for-tool-and-execution-calls) - - - -AI systems increasingly rely on tools to perform real-world actions, including database queries, API calls, and system -commands. Tool execution represents the highest-risk surface in agentic systems because it bridges model output and -external side effects. Sandboxing for tool execution requires intercepting tool calls before execution and evaluating -them within a controlled environment that enforces policy and resource limits. - -## Restricting Escalation Vectors - -Effective sandboxing restricts network access, -limits execution time, controls input and output size, and prevents chained or recursive tool invocation. -Production-grade sandboxing ensures that tools cannot be abused as escalation vectors even when invoked by a -compromised or misaligned model. For AI agents managing infrastructure, financial operations, or blockchain -interactions, sandboxed tool execution is essential to prevent cascading failures. - -## Consider using - -- E2B - dedicated cloud sandboxes for AI code execution with isolated filesystems and network controls -- Firecracker (AWS) - microVM isolation for ephemeral, resource-constrained tool execution -- Prompt Security - runtime policy enforcement before tool and MCP side effects -- Microsoft Defender for AI - policy evaluation of tool calls before execution - ---- - - - +If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/certs/index.mdx b/docs/pages/certs/index.mdx index 9754e4aa..65701348 100644 --- a/docs/pages/certs/index.mdx +++ b/docs/pages/certs/index.mdx @@ -21,3 +21,4 @@ title: "Certs" - [SFC: Workspace Security](/certs/sfc-workspace-security) - [Certification Guidelines](/certs/certification-guidelines) - [Contributing to SEAL Certifications](/certs/contributions) +- [Certified Protocols](/certs/certified-protocols) diff --git a/docs/pages/config/index.mdx b/docs/pages/config/index.mdx new file mode 100644 index 00000000..12ece8be --- /dev/null +++ b/docs/pages/config/index.mdx @@ -0,0 +1,15 @@ +--- +title: "Config" +--- + +{/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} + +# Config + +> _Note:_ This page is auto-generated. Please use the sidebar to explore the docs instead of +> navigating directory paths directly. + +## Pages + +- [Template](/config/template) +- [Using Contributors](/config/using-contributors) diff --git a/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx new file mode 100644 index 00000000..9d78ac59 --- /dev/null +++ b/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx @@ -0,0 +1,220 @@ +--- +title: "AI Execution Sandboxing: A Practical Guide | SEAL" +description: "Practical AI sandboxing guide with threat modeling, isolation options, and deployment-depth recommendations for developers and non-developers." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# AI Execution Sandboxing: A Practical Guide + + + + +AI systems have reached a turning point. They are no longer limited to generating text inside chat windows. Many now +execute code, browse the web, call APIs, manage local files, and connect directly to production systems. As models +evolve into agents that can take action, the security model shifts with them. If an AI agent has shell access, it +inherits the same permissions as the user. It can read files, run commands, and authenticate to connected services. +Security tools such as firewalls, antivirus software, and endpoint monitoring were built to track malicious software or +suspicious users. They are not equipped to tell the difference between a legitimate user action and an AI agent acting +on a manipulated prompt. + +## Clear Boundaries Around Access, Execution, and Data Exposure + +Sandboxing fills this gap by limiting what an AI system can see and do from the outset. Instead of relying only on +detection after something goes wrong, sandboxing creates clear boundaries around access, execution, and data exposure. +It reduces the potential blast radius, enforces privilege constraints, and contains unintended side effects whether the +issue stems from a malicious prompt, a design flaw, or a simple model error. For organizations deploying AI agents that +interact with real systems, isolation is a core requirement rather than an optional safeguard. + +## Technical Capability and Risk Tolerance + +There is a wide range of sandboxing approaches, depending on technical capability and risk tolerance. For many +non-technical users, browser-based AI tools already offer a layer of separation, since applications running in a tab +cannot freely access the local filesystem or installed software. Developers often turn to Docker containers or remote +virtual machines to create controlled execution environments. At higher levels of assurance, infrastructure teams may +rely on microVM technologies such as Firecracker or gVisor, or hardened operating systems like Qubes OS. The right +approach depends on what the agent can access, what authority it holds, and how severe the consequences of misuse might +be. This calculation becomes especially important in Web3 contexts, where agents may control wallets, interact with +immutable smart contracts, or execute transactions that cannot be undone. + +--- + +The guidance that follows offers practical recommendations for implementing sandboxing across different levels of +expertise and deployment models. It builds on established security principles such as least privilege and layered +isolation, while addressing the distinct behavior of AI-driven systems. Whether you are experimenting locally or +deploying agents in production, the goal is to move from general awareness to concrete safeguards that reduce risk in +meaningful ways. + +## Quick Reference: Sandboxing Recommendations by Technical Level + +### For Non-Developers + +Most users interacting with AI tools through web interfaces already benefit from browser-level sandboxing. The following +options provide escalating levels of isolation for those who require additional protection: + +| Option | Effort | Isolation | Best For | +| --- | --- | --- | --- | +| Browser-based AI | None | Strong | ChatGPT, Claude web interfaces. Already sandboxed by the browser with no configuration required. | +| Local VM (Parallels, VMware) | Medium | Strong | Running AI tools in a fully isolated virtual machine on your local hardware. | +| Dedicated Machine | High | Strong | Using a separate physical device exclusively for AI tools, providing complete hardware-level isolation. | + +Recommendation: Start with browser-based AI tools, as they are already sandboxed by default. If you need to install AI +software locally, run it inside a virtual machine using Parallels or VMware for strong isolation without requiring deep +technical expertise. + +### For Developers + +Developer workflows demand flexible sandboxing that accommodates rapid iteration while maintaining meaningful isolation +boundaries. The following options balance security strength against operational overhead: + +| Option | Effort | Isolation | Best For | +| --- | --- | --- | --- | +| Docker Containers | Low | Moderate | Quick containerized isolation for CLI tools and agents. Shares the host kernel, providing a thinner isolation boundary. | +| Remote VMs (Modal, Sprites) | Low | Strong | Cloud-based sandboxes with pay-per-use pricing. Isolation is managed by the service provider. | +| Local VMs (Parallels, VMware, VirtualBox) | Medium | Strong | Full OS-level isolation on your own hardware with complete control over the environment. | +| Specialized Sandboxes (gVisor, Firecracker) | High | Strong | Production-grade isolation designed for multi-tenant workloads at scale. Purpose-built for running untrusted code. | + +Recommendation: For local experimentation with AI agents, use Docker or a remote VM service like Modal. For maximum +isolation on your own machine, run a full VM with Parallels or VMware. Specialized tools like gVisor and Firecracker +are designed for production infrastructure deployments rather than local development. + +## Why Sandboxing Matters Now + +AI systems have crossed a critical threshold: they can now take actions in the real world through code execution, web +browsing, and API interactions. This transforms mistakes or malicious inputs into tangible side effects including +deleted files, exfiltrated credentials, unauthorized purchases, and irreversible on-chain transactions. Native +applications like Claude Cowork and OpenAI Codex change the threat surface further by operating closer to the host +machine and generating new code that can produce unexpected behavior once executed or integrated into existing systems. + +## The Threat Model + +A practical threat model for AI sandboxing answers three fundamental questions: what assets are at risk (files, +credentials, accounts, billing limits, reputation), what entry points exist (prompts, uploaded files, web pages, tool +outputs, plugin responses), and what permissions the system holds (filesystem access, network egress, API scopes, +command execution). The following table catalogs the primary threat categories that sandboxing must address: + +| Threat | Description | Example | +| --- | --- | --- | +| Data Exfiltration | AI sends sensitive data to external servers | Agent uploads SSH keys while performing routine backup operations | +| Destructive Actions | AI deletes or corrupts files and data | Agent executes recursive file deletion while cleaning temporary directories | +| Resource Exhaustion | AI consumes excessive compute, memory, or network bandwidth | Agent spawns infinite subprocess loops or initiates multi-gigabyte downloads | +| Privilege Escalation | AI gains access beyond its intended scope | Agent modifies system configuration files or installs persistent access tools | +| Lateral Movement | AI accesses adjacent systems via discovered credentials | Agent uses cloud provider keys to provision unauthorized compute resources | +| Prompt Injection | External content hijacks agent behavior | Malicious webpage embeds hidden instructions that the agent follows | +| Supply Chain Compromise | AI is compromised through third-party dependencies | Malicious model weights or plugin code introduces persistent backdoors | + +## Why Traditional Security Is Insufficient + +Conventional security tools were designed to distinguish between trusted users and untrusted code. AI agents +fundamentally blur this distinction as they run with user-level permissions, making requests that are indistinguishable +from intentional human actions. A firewall can block connections to known malicious endpoints, but it cannot determine +whether an HTTP POST to a legitimate API represents the user pushing code or an agent exfiltrating private +repositories. The attack surface of an AI agent with shell access is functionally equivalent to the user's entire +environment: every readable file, every executable command, every authenticated service. Sandboxing addresses these +gaps by constraining what the AI can access in the first place, providing defense in depth for an era where the agent +is the user. + +## A Brief History of Sandboxing + +The concept of sandboxing has deep roots in computer science, evolving over decades as systems grew more complex and +security threats more sophisticated. Understanding this evolution provides essential context for modern AI sandboxing +approaches. + +- **Multi-User Systems (1960s-1990s):** The need for isolation originated with mainframe computing. IBM's System/360 + introduced memory protection to prevent one user's program from accessing another's memory space. As computing + transitioned to desktop and server architectures, multi-user operating systems like Unix carried this principle + forward through per-user home directories, file permissions, and process isolation. +- **The Virtualization Era (1970s-2000s):** IBM's VM/370 (1972) enabled multiple operating systems to run on a single + machine in complete isolation. This technology was commercialized for x86 systems by VMware in 1999, making full + OS-level isolation accessible to mainstream computing. Virtual machines remain one of the strongest isolation options + available today. +- **The Container Revolution (2008-2013):** Linux Containers (LXC) emerged in 2008, leveraging kernel features like + cgroups and namespaces to create lightweight containerized environments. Docker (2013) made containerization + accessible to mainstream developers. Containers provide faster startup and lower resource overhead than VMs but share + the host kernel, resulting in a thinner isolation boundary. +- **Browser Sandboxing (2008-Present):** Google Chrome's multi-process architecture (2008) introduced per-tab + sandboxing that became the industry standard. Modern browsers employ multiple isolation layers including site + isolation and WebAssembly sandboxing, which is why web-based AI tools benefit from meaningful isolation by default. +- **Microkernels and Lightweight VMs (2010s-Present):** Projects like gVisor (Google, 2018) and Firecracker (AWS, + 2018) represent the current state of the art: user-space kernels and lightweight virtual machines designed + specifically for running untrusted workloads with minimal overhead. These technologies power the isolation behind + services like AWS Lambda and Google Cloud Run, and are increasingly relevant for production AI workloads. + +## What Is an AI Sandbox? + +An AI sandbox is a controlled, containerized, and sometimes isolated environment designed to contain and monitor AI +system behavior. It creates boundaries that limit what an AI can access and modify, ensuring that even if a model is +compromised or produces unexpected behavior, the impact remains contained within the sandbox boundaries. Effective AI +sandboxes share four key characteristics: isolation (complete separation from production systems and sensitive data), +monitoring (comprehensive logging and observation of all AI actions), resource limits (controlled access to compute, +memory, and network resources), and reversibility (the ability to reset the environment to a known good state). + +## Types of AI Sandboxes + +- **Browser Sandboxes:** Web browsers already execute code in sandboxed environments. When using ChatGPT, Claude, or + other web-based AI tools, the browser isolates them from the rest of the system as they cannot access local files, + install software, or make changes outside the browser tab. File access operates on a whitelist model: users + explicitly upload documents they want the AI to process, which is the inverse of local AI agents that often have + default access to the entire filesystem. For most users, browser-based sandboxing provides sufficient isolation + without any additional configuration. +- **Container-Based Sandboxes:** Technologies like Docker and DevContainers partition AI systems at the operating + system level. Containers share the host kernel but maintain their own filesystem, process space, and network stack. + This provides meaningful isolation with faster startup and lower resource consumption than full virtualization, + making containers well-suited for development workflows and CI/CD pipeline integration. +- **Virtual Machine Sandboxes:** Full virtualization provides the strongest isolation available for local deployment. + Each VM runs its own complete operating system, ensuring that a compromised AI agent inside a VM has no direct path + to the host machine. The tradeoff is higher resource consumption and slower startup times, along with the operational + overhead of maintaining a separate operating system installation. + +## Selecting the Appropriate Sandbox Depth + +The appropriate depth of sandboxing should match your risk tolerance, technical capability, and the sensitivity of +systems the AI agent can access. The spectrum ranges from browser-based isolation requiring zero configuration to +production-grade microVM infrastructure designed for multi-tenant untrusted workloads. The key principle is that +isolation depth should scale with the consequences of a potential breach: AI tools that can only read uploaded +documents require less isolation than agents with shell access, which in turn require less isolation than agents that +can sign blockchain transactions or execute financial operations. + +- **Surface Level - Minimal Setup:** Browser sandboxes (web-based AI tools) and dedicated user accounts or machines. + These require minimal technical expertise and provide strong baseline isolation for casual AI usage. +- **Mid-Depth - Developer-Oriented:** Docker containers, DevContainers, local VMs (Parallels, VMware, VirtualBox, + UTM), and remote VMs (Modal, Sprites). These provide meaningful isolation for development workflows and agent + experimentation with moderate configuration overhead. +- **Deep Isolation - Production-Grade:** Firecracker, gVisor, Qubes OS, nsjail, and bubblewrap. These represent the + highest levels of isolation available and are appropriate for production infrastructure, multi-tenant deployments, + and environments where AI agents interact with high-value assets or irreversible operations. + +## Conclusion + +AI sandboxes represent a critical component in the responsible deployment of artificial intelligence systems. By +providing controlled environments that contain and constrain AI behavior, they bridge the gap between the expanding +capabilities of AI agents and the security requirements of production systems. As AI systems continue to gain autonomy +by executing code, managing infrastructure, and interacting with financial protocols, the necessary investment in +robust sandboxing infrastructure is not merely a best practice but a prerequisite for building AI systems that +organizations and users can trust. + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- gVisor: https://gvisor.dev/docs/ +- nsjail: https://github.com/google/nsjail +- bubblewrap: https://github.com/containers/bubblewrap + +--- + + + diff --git a/docs/pages/devsecops/ai-execution-sandboxing.mdx b/docs/pages/devsecops/ai-execution-sandboxing.mdx new file mode 100644 index 00000000..4d5f71a0 --- /dev/null +++ b/docs/pages/devsecops/ai-execution-sandboxing.mdx @@ -0,0 +1,57 @@ +--- +title: "AI Execution Sandboxing | SEAL" +description: "AI sandboxing foundations for isolating model and agent behavior across tool and execution paths." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# AI Execution Sandboxing + + + + +AI execution sandboxing is the practice of isolating model execution and agent actions within tightly constrained +environments that limit blast radius, privilege, and side effects. As AI systems gain the ability to read files, call +tools, execute code, and interact with external systems, sandboxing becomes a primary security control rather than an +optional safeguard. + +## Predefined Boundaries and Runtime Enforcement + +Effective sandboxing ensures that even if a model is manipulated through prompt injection or +adversarial input, the resulting behavior cannot escape predefined boundaries. In production, sandboxes must be +enforced at runtime and applied consistently across text, document, image, and tool execution paths. For Web3 agents, +sandboxing is especially critical when interacting with wallets, signing flows, or smart contract interfaces, where +unintended actions can be irreversible. + +## Consider using + +- Modal - cloud-based sandboxed execution environments for AI agent workloads +- Firecracker (AWS) - lightweight microVMs for untrusted workload isolation +- Docker sandbox patterns for fast development-stage containment +- Parallels, VMware, VirtualBox, UTM, or Qemu for VM-level isolation +- E2B - cloud sandboxes purpose-built for AI agents and code execution + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- gVisor: https://gvisor.dev/docs/ +- Kata Containers: https://katacontainers.io/ +- Docker security: https://docs.docker.com/engine/security/ + +--- + + + diff --git a/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx b/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx new file mode 100644 index 00000000..10c9bce6 --- /dev/null +++ b/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx @@ -0,0 +1,49 @@ +--- +title: "Capability-Based Isolation for AI Agents | SEAL" +description: "Capability-scoped isolation patterns for AI agents operating across tools, APIs, and external systems." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Capability-Based Isolation for AI Agents + + + + +Traditional sandboxing approaches often rely on coarse-grained isolation, such as container boundaries or virtual +machines, which are insufficient for agentic AI systems that operate across multiple tools and services. +Capability-based isolation refines sandboxing by explicitly defining which actions an agent is permitted to perform and +under what conditions. Rather than granting broad access to file systems, networks, or APIs, agents are issued narrowly +scoped capabilities that are evaluated at execution time. This model aligns security controls with actual behavior +rather than assumed intent. In practice, capability-based isolation allows organizations to safely deploy agents that +can read data without writing, query systems without mutating state, or simulate actions without executing them. In +decentralized systems, this approach maps naturally to permissioned contract calls and limited signing authority. + +## Consider using + +- Zenity - secure-by-design policy checks on agent permissions and tool access +- Palo Alto Prisma AIRS - runtime model inspection and granular capability controls +- Operant AI - MCP gateway authentication and capability boundary enforcement +- Cisco AI Defense - capability-scoped guardrails integrated in AI development flow + +## References + +- Principle of least privilege (NIST): https://csrc.nist.gov/glossary/term/least_privilege +- Capability-based security (background): https://en.wikipedia.org/wiki/Capability-based_security + +--- + + + diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx index 108bc11a..eb2b9617 100644 --- a/docs/pages/devsecops/index.mdx +++ b/docs/pages/devsecops/index.mdx @@ -12,6 +12,13 @@ title: "Devsecops" ## Pages - [DevSecOps](/devsecops/overview) +- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) +- [AI Execution Sandboxing](/devsecops/ai-execution-sandboxing) +- [Capability-Based Isolation for AI Agents](/devsecops/capability-based-isolation-for-ai-agents) +- [Sandboxing for Tool and Execution Calls](/devsecops/sandboxing-for-tool-and-execution-calls) +- [Network and Resource Isolation in AI Sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) +- [Sandboxing as a Complement to Execution-Path Enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) +- [AI Execution Sandboxing: A Practical Guide](/devsecops/ai-execution-sandboxing-practical-guide) - [Implementing Code Signing](/devsecops/code-signing) - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) - [Securing Development Environments](/devsecops/integrated-development-environments) diff --git a/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx new file mode 100644 index 00000000..d47dd815 --- /dev/null +++ b/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx @@ -0,0 +1,50 @@ +--- +title: "Network and Resource Isolation in AI Sandboxes | SEAL" +description: "Deny-by-default network and compute isolation strategy for sandboxed AI workloads." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Network and Resource Isolation in AI Sandboxes + + + + +Network access is one of the most powerful and dangerous capabilities granted to AI systems. Without isolation, models +can be manipulated into exfiltrating data, scanning internal services, or interacting with untrusted external +endpoints. AI sandboxes must enforce strict network policies that default to denial and explicitly allow only required +destinations and protocols. Resource isolation, including CPU, memory, and storage limits, is equally important to +prevent denial-of-service conditions or runaway execution. These controls should be applied dynamically based on agent +role and context rather than statically configured per deployment. In environments where AI agents interact with +decentralized networks, resource and network isolation help prevent unintended propagation across nodes or chains. + +## Consider using + +- Cloudflare - edge DLP and network policy controls for AI traffic +- AccuKnox - zero trust eBPF runtime enforcement for containerized AI workloads +- gVisor (Google) - user-space kernel for granular syscall and network mediation +- Operant AI - API discovery and runtime network access controls for agent ecosystems + +## References + +- Kubernetes Network Policies (concepts): https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- gVisor: https://gvisor.dev/docs/ + +--- + + + diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index ea4d0640..78bb1230 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -34,6 +34,8 @@ Some of the key areas to consider are: critical issues. 2. Implement automated security testing and monitoring. 3. Development, Operations and Security teams should be aligned and work closely together. +4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. + - See: [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) --- diff --git a/docs/pages/devsecops/sandboxing-and-isolation.mdx b/docs/pages/devsecops/sandboxing-and-isolation.mdx new file mode 100644 index 00000000..f4463c2c --- /dev/null +++ b/docs/pages/devsecops/sandboxing-and-isolation.mdx @@ -0,0 +1,44 @@ +--- +title: "Sandboxing & Isolation | SEAL" +description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across builds, tooling, and execution environments." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Sandboxing & Isolation + + + + +This section is the **canonical home** for guidance on sandboxing, isolation, and containment as part of DevSecOps. + +Sandboxing and isolation are *implementation controls* used to reduce blast radius when running untrusted or semi-trusted code and workflows (CI steps, build tooling, plugins, scripts, AI tool calls, etc.). + +## Pages in this section + +- [AI Execution Sandboxing](/devsecops/ai-execution-sandboxing) +- [Capability-Based Isolation for AI Agents](/devsecops/capability-based-isolation-for-ai-agents) +- [Sandboxing for Tool and Execution Calls](/devsecops/sandboxing-for-tool-and-execution-calls) +- [Network and Resource Isolation in AI Sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) +- [Sandboxing as a Complement to Execution-Path Enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) +- [AI Execution Sandboxing: A Practical Guide](/devsecops/ai-execution-sandboxing-practical-guide) + +## Notes + +AI Security pages that previously hosted this material now link here so that isolation guidance stays centralized and consistent. + +--- + + + diff --git a/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx new file mode 100644 index 00000000..5e3ed5aa --- /dev/null +++ b/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx @@ -0,0 +1,47 @@ +--- +title: "Sandboxing as a Complement to Execution-Path Enforcement | SEAL" +description: "Defense-in-depth model combining execution-path policy controls with sandbox isolation boundaries." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Sandboxing as a Complement to Execution-Path Enforcement + + + + +Sandboxing alone does not solve AI security, but it is a necessary complement to execution-path enforcement. While +execution-path controls determine whether an action should occur, sandboxing constrains what happens if an action is +allowed. Together, these mechanisms ensure that AI systems remain safe even under partial failure or misclassification. +Sandboxing provides defense in depth by limiting the impact of mistakes, adversarial behavior, or unforeseen +interactions between modalities. In production, sandboxing should be treated as an always-on control rather than a +development-time feature, with continuous validation that isolation boundaries remain intact as systems evolve. + +## Consider using + +- Palo Alto Prisma AIRS + Firecracker - posture management plus runtime microVM guardrails +- Zenity + gVisor - agent-level execution monitoring plus kernel-level isolation +- Cisco AI Defense + E2B - MCP inspection plus isolated code execution sandboxes +- Operant AI + AccuKnox - application-level agent controls plus eBPF infrastructure enforcement + +## References + +- Defense in depth (CISA): https://www.cisa.gov/resources-tools/resources/defense-depth + +--- + + + diff --git a/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx new file mode 100644 index 00000000..6d6e3019 --- /dev/null +++ b/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx @@ -0,0 +1,54 @@ +--- +title: "Sandboxing for Tool and Execution Calls | SEAL" +description: "High-risk tool invocation controls for AI agents with sandboxed execution and runtime policy checks." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Sandboxing for Tool and Execution Calls + + + + +AI systems increasingly rely on tools to perform real-world actions, including database queries, API calls, and system +commands. Tool execution represents the highest-risk surface in agentic systems because it bridges model output and +external side effects. Sandboxing for tool execution requires intercepting tool calls before execution and evaluating +them within a controlled environment that enforces policy and resource limits. + +## Restricting Escalation Vectors + +Effective sandboxing restricts network access, +limits execution time, controls input and output size, and prevents chained or recursive tool invocation. +Production-grade sandboxing ensures that tools cannot be abused as escalation vectors even when invoked by a +compromised or misaligned model. For AI agents managing infrastructure, financial operations, or blockchain +interactions, sandboxed tool execution is essential to prevent cascading failures. + +## Consider using + +- E2B - dedicated cloud sandboxes for AI code execution with isolated filesystems and network controls +- Firecracker (AWS) - microVM isolation for ephemeral, resource-constrained tool execution +- Prompt Security - runtime policy enforcement before tool and MCP side effects +- Microsoft Defender for AI - policy evaluation of tool calls before execution + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- seccomp (Linux): https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html + +--- + + + diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 8c475f51..338c53c3 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -25,6 +25,39 @@ "Whitehat" ], "pageTagsMap": { + "/ai-security/ai-browsers": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy" + ], + "/ai-security/ai-workflows-developers-vs-non-developers": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Community & Marketing" + ], + "/ai-security/data-exfiltration-via-generative-systems": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy" + ], + "/ai-security/execution-path-enforcement": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/ai-security/overview": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/ai-security/prompt-injection-defenses": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy" + ], "/awareness/core-awareness-principles": [ "Security Specialist", "Operations & Strategy", @@ -126,6 +159,24 @@ "/community-management/twitter": [ "Community & Marketing" ], + "/devsecops/ai-execution-sandboxing-practical-guide": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops", + "SRE" + ], + "/devsecops/ai-execution-sandboxing": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/devsecops/capability-based-isolation-for-ai-agents": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy" + ], "/devsecops/code-signing": [ "Engineer/Developer", "Security Specialist", @@ -142,6 +193,13 @@ "Security Specialist", "Devops" ], + "/devsecops/network-and-resource-isolation-in-ai-sandboxes": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops", + "SRE" + ], "/devsecops/overview": [ "Engineer/Developer", "Security Specialist", @@ -153,6 +211,24 @@ "Security Specialist", "Devops" ], + "/devsecops/sandboxing-and-isolation": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/devsecops/sandboxing-for-tool-and-execution-calls": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], "/devsecops/security-testing": [ "Engineer/Developer", "Security Specialist", @@ -1048,6 +1124,7 @@ "Identity and Access Management IAM": "iam", "Secure Software Development": "secure-software-development", "Security Testing": "security-testing", + "AI Security": "ai-security", "ENS": "ens", "Safe Harbor": "safe-harbor", "Encryption": "encryption", diff --git a/vocs.config.tsx b/vocs.config.tsx index ae34506d..540f4a54 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -300,6 +300,13 @@ const config = { dev: true, items: [ { text: 'Overview', link: '/devsecops/overview', dev: true }, + { text: 'Sandboxing & Isolation', link: '/devsecops/sandboxing-and-isolation', dev: true }, + { text: 'AI Execution Sandboxing', link: '/devsecops/ai-execution-sandboxing', dev: true }, + { text: 'Capability-Based Isolation for AI Agents', link: '/devsecops/capability-based-isolation-for-ai-agents', dev: true }, + { text: 'Sandboxing for Tool and Execution Calls', link: '/devsecops/sandboxing-for-tool-and-execution-calls', dev: true }, + { text: 'Network and Resource Isolation in AI Sandboxes', link: '/devsecops/network-and-resource-isolation-in-ai-sandboxes', dev: true }, + { text: 'Sandboxing as a Complement to Execution-Path Enforcement', link: '/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement', dev: true }, + { text: 'AI Execution Sandboxing: A Practical Guide', link: '/devsecops/ai-execution-sandboxing-practical-guide', dev: true }, { text: 'Code Signing', link: '/devsecops/code-signing', dev: true }, { text: 'Continuous Integration and Deployment', link: '/devsecops/continuous-integration-continuous-deployment', dev: true }, { text: 'Integrated Development Environments', link: '/devsecops/integrated-development-environments', dev: true }, @@ -390,12 +397,7 @@ const config = { { text: 'AI Workflows: Developers vs Non-Developers', link: '/ai-security/ai-workflows-developers-vs-non-developers', dev: true }, { text: 'Data Exfiltration via Generative Systems', link: '/ai-security/data-exfiltration-via-generative-systems', dev: true }, { text: 'Execution-Path Enforcement', link: '/ai-security/execution-path-enforcement', dev: true }, - { text: 'AI Execution Sandboxing', link: '/ai-security/ai-execution-sandboxing', dev: true }, - { text: 'Capability-Based Isolation for AI Agents', link: '/ai-security/capability-based-isolation-for-ai-agents', dev: true }, - { text: 'Sandboxing for Tool and Execution Calls', link: '/ai-security/sandboxing-for-tool-and-execution-calls', dev: true }, - { text: 'Network and Resource Isolation in AI Sandboxes', link: '/ai-security/network-and-resource-isolation-in-ai-sandboxes', dev: true }, - { text: 'Sandboxing as a Complement to Execution-Path Enforcement', link: '/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement', dev: true }, - { text: 'AI Execution Sandboxing: A Practical Guide', link: '/ai-security/ai-execution-sandboxing-practical-guide', dev: true }, + { text: 'Sandboxing & Isolation (DevSecOps)', link: '/devsecops/sandboxing-and-isolation', dev: true }, ] }, { From 3be69bc6cde7935b2dfbe3fb9f9a1967c1f0f2f7 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 02/14] Rename sandboxing pages and remove AI-specific wording (issue #398) (cherry picked from commit 6526afbabfe333ee37f5d68ea4e9df60a415f23d) --- ...i-execution-sandboxing-practical-guide.mdx | 2 +- .../ai-security/ai-execution-sandboxing.mdx | 2 +- ...pability-based-isolation-for-ai-agents.mdx | 2 +- ...and-resource-isolation-in-ai-sandboxes.mdx | 2 +- ...mplement-to-execution-path-enforcement.mdx | 2 +- ...andboxing-for-tool-and-execution-calls.mdx | 2 +- ...i-execution-sandboxing-practical-guide.mdx | 220 +----------------- .../devsecops/ai-execution-sandboxing.mdx | 57 +---- ...pability-based-isolation-for-ai-agents.mdx | 49 +--- .../devsecops/capability-based-isolation.mdx | 52 +++++ .../execution-sandboxing-practical-guide.mdx | 217 +++++++++++++++++ docs/pages/devsecops/execution-sandboxing.mdx | 67 ++++++ docs/pages/devsecops/index.mdx | 18 +- ...and-resource-isolation-in-ai-sandboxes.mdx | 50 +--- .../network-and-resource-isolation.mdx | 48 ++++ docs/pages/devsecops/overview.mdx | 2 +- .../devsecops/sandboxing-and-isolation.mdx | 12 +- .../sandboxing-and-policy-enforcement.mdx | 46 ++++ ...mplement-to-execution-path-enforcement.mdx | 47 +--- ...andboxing-for-tool-and-execution-calls.mdx | 54 +---- .../sandboxing-for-tool-execution.mdx | 53 +++++ vocs.config.tsx | 12 +- 22 files changed, 538 insertions(+), 478 deletions(-) create mode 100644 docs/pages/devsecops/capability-based-isolation.mdx create mode 100644 docs/pages/devsecops/execution-sandboxing-practical-guide.mdx create mode 100644 docs/pages/devsecops/execution-sandboxing.mdx create mode 100644 docs/pages/devsecops/network-and-resource-isolation.mdx create mode 100644 docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx create mode 100644 docs/pages/devsecops/sandboxing-for-tool-execution.mdx diff --git a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx index e458c579..f843a4ad 100644 --- a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx +++ b/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/ai-execution-sandboxing-practical-guide](/devsecops/ai-execution-sandboxing-practical-guide) +- **New location:** [/devsecops/execution-sandboxing-practical-guide](/devsecops/execution-sandboxing-practical-guide) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/ai-execution-sandboxing.mdx b/docs/pages/ai-security/ai-execution-sandboxing.mdx index e974410e..0cdf3852 100644 --- a/docs/pages/ai-security/ai-execution-sandboxing.mdx +++ b/docs/pages/ai-security/ai-execution-sandboxing.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/ai-execution-sandboxing](/devsecops/ai-execution-sandboxing) +- **New location:** [/devsecops/execution-sandboxing](/devsecops/execution-sandboxing) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx b/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx index 9b64df0b..a8163bec 100644 --- a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx +++ b/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/capability-based-isolation-for-ai-agents](/devsecops/capability-based-isolation-for-ai-agents) +- **New location:** [/devsecops/capability-based-isolation](/devsecops/capability-based-isolation) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx index f5ea3cb3..1efbcc1e 100644 --- a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx +++ b/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/network-and-resource-isolation-in-ai-sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) +- **New location:** [/devsecops/network-and-resource-isolation](/devsecops/network-and-resource-isolation) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx index ddcaa130..4ca74152 100644 --- a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx +++ b/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) +- **New location:** [/devsecops/sandboxing-and-policy-enforcement](/devsecops/sandboxing-and-policy-enforcement) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx index b65be432..78c282d4 100644 --- a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx +++ b/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx @@ -7,6 +7,6 @@ description: "This page moved to DevSecOps (canonical location)." The canonical version of this page now lives under **DevSecOps**: -- **New location:** [/devsecops/sandboxing-for-tool-and-execution-calls](/devsecops/sandboxing-for-tool-and-execution-calls) +- **New location:** [/devsecops/sandboxing-for-tool-execution](/devsecops/sandboxing-for-tool-execution) If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx index 9d78ac59..90abac42 100644 --- a/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx @@ -1,220 +1,8 @@ --- -title: "AI Execution Sandboxing: A Practical Guide | SEAL" -description: "Practical AI sandboxing guide with threat modeling, isolation options, and deployment-depth recommendations for developers and non-developers." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Execution Sandboxing: Practical Guide (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# AI Execution Sandboxing: A Practical Guide - - - - -AI systems have reached a turning point. They are no longer limited to generating text inside chat windows. Many now -execute code, browse the web, call APIs, manage local files, and connect directly to production systems. As models -evolve into agents that can take action, the security model shifts with them. If an AI agent has shell access, it -inherits the same permissions as the user. It can read files, run commands, and authenticate to connected services. -Security tools such as firewalls, antivirus software, and endpoint monitoring were built to track malicious software or -suspicious users. They are not equipped to tell the difference between a legitimate user action and an AI agent acting -on a manipulated prompt. - -## Clear Boundaries Around Access, Execution, and Data Exposure - -Sandboxing fills this gap by limiting what an AI system can see and do from the outset. Instead of relying only on -detection after something goes wrong, sandboxing creates clear boundaries around access, execution, and data exposure. -It reduces the potential blast radius, enforces privilege constraints, and contains unintended side effects whether the -issue stems from a malicious prompt, a design flaw, or a simple model error. For organizations deploying AI agents that -interact with real systems, isolation is a core requirement rather than an optional safeguard. - -## Technical Capability and Risk Tolerance - -There is a wide range of sandboxing approaches, depending on technical capability and risk tolerance. For many -non-technical users, browser-based AI tools already offer a layer of separation, since applications running in a tab -cannot freely access the local filesystem or installed software. Developers often turn to Docker containers or remote -virtual machines to create controlled execution environments. At higher levels of assurance, infrastructure teams may -rely on microVM technologies such as Firecracker or gVisor, or hardened operating systems like Qubes OS. The right -approach depends on what the agent can access, what authority it holds, and how severe the consequences of misuse might -be. This calculation becomes especially important in Web3 contexts, where agents may control wallets, interact with -immutable smart contracts, or execute transactions that cannot be undone. - ---- - -The guidance that follows offers practical recommendations for implementing sandboxing across different levels of -expertise and deployment models. It builds on established security principles such as least privilege and layered -isolation, while addressing the distinct behavior of AI-driven systems. Whether you are experimenting locally or -deploying agents in production, the goal is to move from general awareness to concrete safeguards that reduce risk in -meaningful ways. - -## Quick Reference: Sandboxing Recommendations by Technical Level - -### For Non-Developers - -Most users interacting with AI tools through web interfaces already benefit from browser-level sandboxing. The following -options provide escalating levels of isolation for those who require additional protection: - -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Browser-based AI | None | Strong | ChatGPT, Claude web interfaces. Already sandboxed by the browser with no configuration required. | -| Local VM (Parallels, VMware) | Medium | Strong | Running AI tools in a fully isolated virtual machine on your local hardware. | -| Dedicated Machine | High | Strong | Using a separate physical device exclusively for AI tools, providing complete hardware-level isolation. | - -Recommendation: Start with browser-based AI tools, as they are already sandboxed by default. If you need to install AI -software locally, run it inside a virtual machine using Parallels or VMware for strong isolation without requiring deep -technical expertise. - -### For Developers - -Developer workflows demand flexible sandboxing that accommodates rapid iteration while maintaining meaningful isolation -boundaries. The following options balance security strength against operational overhead: - -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Docker Containers | Low | Moderate | Quick containerized isolation for CLI tools and agents. Shares the host kernel, providing a thinner isolation boundary. | -| Remote VMs (Modal, Sprites) | Low | Strong | Cloud-based sandboxes with pay-per-use pricing. Isolation is managed by the service provider. | -| Local VMs (Parallels, VMware, VirtualBox) | Medium | Strong | Full OS-level isolation on your own hardware with complete control over the environment. | -| Specialized Sandboxes (gVisor, Firecracker) | High | Strong | Production-grade isolation designed for multi-tenant workloads at scale. Purpose-built for running untrusted code. | - -Recommendation: For local experimentation with AI agents, use Docker or a remote VM service like Modal. For maximum -isolation on your own machine, run a full VM with Parallels or VMware. Specialized tools like gVisor and Firecracker -are designed for production infrastructure deployments rather than local development. - -## Why Sandboxing Matters Now - -AI systems have crossed a critical threshold: they can now take actions in the real world through code execution, web -browsing, and API interactions. This transforms mistakes or malicious inputs into tangible side effects including -deleted files, exfiltrated credentials, unauthorized purchases, and irreversible on-chain transactions. Native -applications like Claude Cowork and OpenAI Codex change the threat surface further by operating closer to the host -machine and generating new code that can produce unexpected behavior once executed or integrated into existing systems. - -## The Threat Model - -A practical threat model for AI sandboxing answers three fundamental questions: what assets are at risk (files, -credentials, accounts, billing limits, reputation), what entry points exist (prompts, uploaded files, web pages, tool -outputs, plugin responses), and what permissions the system holds (filesystem access, network egress, API scopes, -command execution). The following table catalogs the primary threat categories that sandboxing must address: - -| Threat | Description | Example | -| --- | --- | --- | -| Data Exfiltration | AI sends sensitive data to external servers | Agent uploads SSH keys while performing routine backup operations | -| Destructive Actions | AI deletes or corrupts files and data | Agent executes recursive file deletion while cleaning temporary directories | -| Resource Exhaustion | AI consumes excessive compute, memory, or network bandwidth | Agent spawns infinite subprocess loops or initiates multi-gigabyte downloads | -| Privilege Escalation | AI gains access beyond its intended scope | Agent modifies system configuration files or installs persistent access tools | -| Lateral Movement | AI accesses adjacent systems via discovered credentials | Agent uses cloud provider keys to provision unauthorized compute resources | -| Prompt Injection | External content hijacks agent behavior | Malicious webpage embeds hidden instructions that the agent follows | -| Supply Chain Compromise | AI is compromised through third-party dependencies | Malicious model weights or plugin code introduces persistent backdoors | - -## Why Traditional Security Is Insufficient - -Conventional security tools were designed to distinguish between trusted users and untrusted code. AI agents -fundamentally blur this distinction as they run with user-level permissions, making requests that are indistinguishable -from intentional human actions. A firewall can block connections to known malicious endpoints, but it cannot determine -whether an HTTP POST to a legitimate API represents the user pushing code or an agent exfiltrating private -repositories. The attack surface of an AI agent with shell access is functionally equivalent to the user's entire -environment: every readable file, every executable command, every authenticated service. Sandboxing addresses these -gaps by constraining what the AI can access in the first place, providing defense in depth for an era where the agent -is the user. - -## A Brief History of Sandboxing - -The concept of sandboxing has deep roots in computer science, evolving over decades as systems grew more complex and -security threats more sophisticated. Understanding this evolution provides essential context for modern AI sandboxing -approaches. - -- **Multi-User Systems (1960s-1990s):** The need for isolation originated with mainframe computing. IBM's System/360 - introduced memory protection to prevent one user's program from accessing another's memory space. As computing - transitioned to desktop and server architectures, multi-user operating systems like Unix carried this principle - forward through per-user home directories, file permissions, and process isolation. -- **The Virtualization Era (1970s-2000s):** IBM's VM/370 (1972) enabled multiple operating systems to run on a single - machine in complete isolation. This technology was commercialized for x86 systems by VMware in 1999, making full - OS-level isolation accessible to mainstream computing. Virtual machines remain one of the strongest isolation options - available today. -- **The Container Revolution (2008-2013):** Linux Containers (LXC) emerged in 2008, leveraging kernel features like - cgroups and namespaces to create lightweight containerized environments. Docker (2013) made containerization - accessible to mainstream developers. Containers provide faster startup and lower resource overhead than VMs but share - the host kernel, resulting in a thinner isolation boundary. -- **Browser Sandboxing (2008-Present):** Google Chrome's multi-process architecture (2008) introduced per-tab - sandboxing that became the industry standard. Modern browsers employ multiple isolation layers including site - isolation and WebAssembly sandboxing, which is why web-based AI tools benefit from meaningful isolation by default. -- **Microkernels and Lightweight VMs (2010s-Present):** Projects like gVisor (Google, 2018) and Firecracker (AWS, - 2018) represent the current state of the art: user-space kernels and lightweight virtual machines designed - specifically for running untrusted workloads with minimal overhead. These technologies power the isolation behind - services like AWS Lambda and Google Cloud Run, and are increasingly relevant for production AI workloads. - -## What Is an AI Sandbox? - -An AI sandbox is a controlled, containerized, and sometimes isolated environment designed to contain and monitor AI -system behavior. It creates boundaries that limit what an AI can access and modify, ensuring that even if a model is -compromised or produces unexpected behavior, the impact remains contained within the sandbox boundaries. Effective AI -sandboxes share four key characteristics: isolation (complete separation from production systems and sensitive data), -monitoring (comprehensive logging and observation of all AI actions), resource limits (controlled access to compute, -memory, and network resources), and reversibility (the ability to reset the environment to a known good state). - -## Types of AI Sandboxes - -- **Browser Sandboxes:** Web browsers already execute code in sandboxed environments. When using ChatGPT, Claude, or - other web-based AI tools, the browser isolates them from the rest of the system as they cannot access local files, - install software, or make changes outside the browser tab. File access operates on a whitelist model: users - explicitly upload documents they want the AI to process, which is the inverse of local AI agents that often have - default access to the entire filesystem. For most users, browser-based sandboxing provides sufficient isolation - without any additional configuration. -- **Container-Based Sandboxes:** Technologies like Docker and DevContainers partition AI systems at the operating - system level. Containers share the host kernel but maintain their own filesystem, process space, and network stack. - This provides meaningful isolation with faster startup and lower resource consumption than full virtualization, - making containers well-suited for development workflows and CI/CD pipeline integration. -- **Virtual Machine Sandboxes:** Full virtualization provides the strongest isolation available for local deployment. - Each VM runs its own complete operating system, ensuring that a compromised AI agent inside a VM has no direct path - to the host machine. The tradeoff is higher resource consumption and slower startup times, along with the operational - overhead of maintaining a separate operating system installation. - -## Selecting the Appropriate Sandbox Depth - -The appropriate depth of sandboxing should match your risk tolerance, technical capability, and the sensitivity of -systems the AI agent can access. The spectrum ranges from browser-based isolation requiring zero configuration to -production-grade microVM infrastructure designed for multi-tenant untrusted workloads. The key principle is that -isolation depth should scale with the consequences of a potential breach: AI tools that can only read uploaded -documents require less isolation than agents with shell access, which in turn require less isolation than agents that -can sign blockchain transactions or execute financial operations. - -- **Surface Level - Minimal Setup:** Browser sandboxes (web-based AI tools) and dedicated user accounts or machines. - These require minimal technical expertise and provide strong baseline isolation for casual AI usage. -- **Mid-Depth - Developer-Oriented:** Docker containers, DevContainers, local VMs (Parallels, VMware, VirtualBox, - UTM), and remote VMs (Modal, Sprites). These provide meaningful isolation for development workflows and agent - experimentation with moderate configuration overhead. -- **Deep Isolation - Production-Grade:** Firecracker, gVisor, Qubes OS, nsjail, and bubblewrap. These represent the - highest levels of isolation available and are appropriate for production infrastructure, multi-tenant deployments, - and environments where AI agents interact with high-value assets or irreversible operations. - -## Conclusion - -AI sandboxes represent a critical component in the responsible deployment of artificial intelligence systems. By -providing controlled environments that contain and constrain AI behavior, they bridge the gap between the expanding -capabilities of AI agents and the security requirements of production systems. As AI systems continue to gain autonomy -by executing code, managing infrastructure, and interacting with financial protocols, the necessary investment in -robust sandboxing infrastructure is not merely a best practice but a prerequisite for building AI systems that -organizations and users can trust. - -## References - -- Firecracker: https://firecracker-microvm.github.io/ -- gVisor: https://gvisor.dev/docs/ -- nsjail: https://github.com/google/nsjail -- bubblewrap: https://github.com/containers/bubblewrap - ---- - - - +- Canonical page: [/devsecops/execution-sandboxing-practical-guide](/devsecops/execution-sandboxing-practical-guide) diff --git a/docs/pages/devsecops/ai-execution-sandboxing.mdx b/docs/pages/devsecops/ai-execution-sandboxing.mdx index 4d5f71a0..29752973 100644 --- a/docs/pages/devsecops/ai-execution-sandboxing.mdx +++ b/docs/pages/devsecops/ai-execution-sandboxing.mdx @@ -1,57 +1,8 @@ --- -title: "AI Execution Sandboxing | SEAL" -description: "AI sandboxing foundations for isolating model and agent behavior across tool and execution paths." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Execution Sandboxing (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# AI Execution Sandboxing - - - - -AI execution sandboxing is the practice of isolating model execution and agent actions within tightly constrained -environments that limit blast radius, privilege, and side effects. As AI systems gain the ability to read files, call -tools, execute code, and interact with external systems, sandboxing becomes a primary security control rather than an -optional safeguard. - -## Predefined Boundaries and Runtime Enforcement - -Effective sandboxing ensures that even if a model is manipulated through prompt injection or -adversarial input, the resulting behavior cannot escape predefined boundaries. In production, sandboxes must be -enforced at runtime and applied consistently across text, document, image, and tool execution paths. For Web3 agents, -sandboxing is especially critical when interacting with wallets, signing flows, or smart contract interfaces, where -unintended actions can be irreversible. - -## Consider using - -- Modal - cloud-based sandboxed execution environments for AI agent workloads -- Firecracker (AWS) - lightweight microVMs for untrusted workload isolation -- Docker sandbox patterns for fast development-stage containment -- Parallels, VMware, VirtualBox, UTM, or Qemu for VM-level isolation -- E2B - cloud sandboxes purpose-built for AI agents and code execution - -## References - -- Firecracker: https://firecracker-microvm.github.io/ -- gVisor: https://gvisor.dev/docs/ -- Kata Containers: https://katacontainers.io/ -- Docker security: https://docs.docker.com/engine/security/ - ---- - - - +- Canonical page: [/devsecops/execution-sandboxing](/devsecops/execution-sandboxing) diff --git a/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx b/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx index 10c9bce6..3060e366 100644 --- a/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx +++ b/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx @@ -1,49 +1,8 @@ --- -title: "Capability-Based Isolation for AI Agents | SEAL" -description: "Capability-scoped isolation patterns for AI agents operating across tools, APIs, and external systems." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Capability-Based Isolation (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# Capability-Based Isolation for AI Agents - - - - -Traditional sandboxing approaches often rely on coarse-grained isolation, such as container boundaries or virtual -machines, which are insufficient for agentic AI systems that operate across multiple tools and services. -Capability-based isolation refines sandboxing by explicitly defining which actions an agent is permitted to perform and -under what conditions. Rather than granting broad access to file systems, networks, or APIs, agents are issued narrowly -scoped capabilities that are evaluated at execution time. This model aligns security controls with actual behavior -rather than assumed intent. In practice, capability-based isolation allows organizations to safely deploy agents that -can read data without writing, query systems without mutating state, or simulate actions without executing them. In -decentralized systems, this approach maps naturally to permissioned contract calls and limited signing authority. - -## Consider using - -- Zenity - secure-by-design policy checks on agent permissions and tool access -- Palo Alto Prisma AIRS - runtime model inspection and granular capability controls -- Operant AI - MCP gateway authentication and capability boundary enforcement -- Cisco AI Defense - capability-scoped guardrails integrated in AI development flow - -## References - -- Principle of least privilege (NIST): https://csrc.nist.gov/glossary/term/least_privilege -- Capability-based security (background): https://en.wikipedia.org/wiki/Capability-based_security - ---- - - - +- Canonical page: [/devsecops/capability-based-isolation](/devsecops/capability-based-isolation) diff --git a/docs/pages/devsecops/capability-based-isolation.mdx b/docs/pages/devsecops/capability-based-isolation.mdx new file mode 100644 index 00000000..94aae34f --- /dev/null +++ b/docs/pages/devsecops/capability-based-isolation.mdx @@ -0,0 +1,52 @@ +--- +title: "Capability-Based Isolation | SEAL" +description: "Capability-scoped isolation patterns for automation operating across tools, APIs, and external systems." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Capability-Based Isolation + + + + +Traditional sandboxing approaches often rely on coarse-grained isolation (e.g., “it’s in a container”), which is often insufficient for real-world DevSecOps workflows that span multiple tools and services. + +Capability-based isolation refines sandboxing by explicitly defining which actions a workload is permitted to perform and under what conditions. Rather than granting broad access to filesystems, networks, or APIs, automation is issued narrowly scoped **capabilities** that are evaluated at execution time. + +This model aligns security controls with actual behavior rather than assumed intent. In practice, capability-based isolation lets you safely run automation that can: + +- read data without writing +- query systems without mutating state +- simulate actions without executing them + +This is useful for CI workflows, internal bots, and AI agents alike. In decentralized systems, it also maps naturally to permissioned contract calls and limited signing authority. + +## Consider using + +- Zenity - secure-by-design policy checks on agent permissions and tool access +- Palo Alto Prisma AIRS - runtime model inspection and granular capability controls +- Operant AI - MCP gateway authentication and capability boundary enforcement +- Cisco AI Defense - capability-scoped guardrails integrated in AI development flow + +## References + +- Principle of least privilege (NIST): https://csrc.nist.gov/glossary/term/least_privilege +- Capability-based security (background): https://en.wikipedia.org/wiki/Capability-based_security + +--- + + + diff --git a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx new file mode 100644 index 00000000..f966ddab --- /dev/null +++ b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx @@ -0,0 +1,217 @@ +--- +title: "Execution Sandboxing: A Practical Guide | SEAL" +description: "Practical sandboxing guide with isolation options and deployment-depth recommendations for DevSecOps workflows." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Execution Sandboxing: A Practical Guide + + + + +Modern automation has reached a turning point: it’s no longer limited to passive “advice” or read-only reporting. CI jobs, developer tools, bots, and agents can execute code, browse the web, call APIs, manage local files, and connect directly to production systems. + +If an automated workflow has shell access, it inherits the same permissions as the runner/user. It can read files, run commands, and authenticate to connected services. Many traditional security controls were built to detect malicious software or suspicious humans; they often struggle to distinguish legitimate automation from compromised automation. + +## Clear Boundaries Around Access, Execution, and Data Exposure + +Sandboxing fills this gap by limiting what an automated workload can see and do from the outset. Instead of relying only on detection after something goes wrong, sandboxing creates clear boundaries around access, execution, and data exposure. + +It reduces blast radius, enforces privilege constraints, and contains unintended side effects whether the issue stems from malicious input, a supply-chain compromise, a configuration mistake, or a tool/agent error. + +For teams deploying automation that +interact with real systems, isolation is a core requirement rather than an optional safeguard. + +## Technical Capability and Risk Tolerance + +There is a wide range of sandboxing approaches, depending on technical capability and risk tolerance. For many +non-technical users, browser-based AI tools already offer a layer of separation, since applications running in a tab +cannot freely access the local filesystem or installed software. Developers often turn to Docker containers or remote +virtual machines to create controlled execution environments. At higher levels of assurance, infrastructure teams may +rely on microVM technologies such as Firecracker or gVisor, or hardened operating systems like Qubes OS. The right +approach depends on what the agent can access, what authority it holds, and how severe the consequences of misuse might +be. This calculation becomes especially important in Web3 contexts, where agents may control wallets, interact with +immutable smart contracts, or execute transactions that cannot be undone. + +--- + +The guidance that follows offers practical recommendations for implementing sandboxing across different levels of +expertise and deployment models. It builds on established security principles such as least privilege and layered +isolation, while addressing the distinct behavior of AI-driven systems. Whether you are experimenting locally or +deploying agents in production, the goal is to move from general awareness to concrete safeguards that reduce risk in +meaningful ways. + +## Quick Reference: Sandboxing Recommendations by Technical Level + +### For Non-Developers + +Most users interacting with AI tools through web interfaces already benefit from browser-level sandboxing. The following +options provide escalating levels of isolation for those who require additional protection: + +| Option | Effort | Isolation | Best For | +| --- | --- | --- | --- | +| Browser-based AI | None | Strong | ChatGPT, Claude web interfaces. Already sandboxed by the browser with no configuration required. | +| Local VM (Parallels, VMware) | Medium | Strong | Running AI tools in a fully isolated virtual machine on your local hardware. | +| Dedicated Machine | High | Strong | Using a separate physical device exclusively for AI tools, providing complete hardware-level isolation. | + +Recommendation: Start with browser-based AI tools, as they are already sandboxed by default. If you need to install AI +software locally, run it inside a virtual machine using Parallels or VMware for strong isolation without requiring deep +technical expertise. + +### For Developers + +Developer workflows demand flexible sandboxing that accommodates rapid iteration while maintaining meaningful isolation +boundaries. The following options balance security strength against operational overhead: + +| Option | Effort | Isolation | Best For | +| --- | --- | --- | --- | +| Docker Containers | Low | Moderate | Quick containerized isolation for CLI tools and agents. Shares the host kernel, providing a thinner isolation boundary. | +| Remote VMs (Modal, Sprites) | Low | Strong | Cloud-based sandboxes with pay-per-use pricing. Isolation is managed by the service provider. | +| Local VMs (Parallels, VMware, VirtualBox) | Medium | Strong | Full OS-level isolation on your own hardware with complete control over the environment. | +| Specialized Sandboxes (gVisor, Firecracker) | High | Strong | Production-grade isolation designed for multi-tenant workloads at scale. Purpose-built for running untrusted code. | + +Recommendation: For local experimentation with AI agents, use Docker or a remote VM service like Modal. For maximum +isolation on your own machine, run a full VM with Parallels or VMware. Specialized tools like gVisor and Firecracker +are designed for production infrastructure deployments rather than local development. + +## Why Sandboxing Matters Now + +AI systems have crossed a critical threshold: they can now take actions in the real world through code execution, web +browsing, and API interactions. This transforms mistakes or malicious inputs into tangible side effects including +deleted files, exfiltrated credentials, unauthorized purchases, and irreversible on-chain transactions. Native +applications like Claude Cowork and OpenAI Codex change the threat surface further by operating closer to the host +machine and generating new code that can produce unexpected behavior once executed or integrated into existing systems. + +## The Threat Model + +A practical threat model for AI sandboxing answers three fundamental questions: what assets are at risk (files, +credentials, accounts, billing limits, reputation), what entry points exist (prompts, uploaded files, web pages, tool +outputs, plugin responses), and what permissions the system holds (filesystem access, network egress, API scopes, +command execution). The following table catalogs the primary threat categories that sandboxing must address: + +| Threat | Description | Example | +| --- | --- | --- | +| Data Exfiltration | AI sends sensitive data to external servers | Agent uploads SSH keys while performing routine backup operations | +| Destructive Actions | AI deletes or corrupts files and data | Agent executes recursive file deletion while cleaning temporary directories | +| Resource Exhaustion | AI consumes excessive compute, memory, or network bandwidth | Agent spawns infinite subprocess loops or initiates multi-gigabyte downloads | +| Privilege Escalation | AI gains access beyond its intended scope | Agent modifies system configuration files or installs persistent access tools | +| Lateral Movement | AI accesses adjacent systems via discovered credentials | Agent uses cloud provider keys to provision unauthorized compute resources | +| Prompt Injection | External content hijacks agent behavior | Malicious webpage embeds hidden instructions that the agent follows | +| Supply Chain Compromise | AI is compromised through third-party dependencies | Malicious model weights or plugin code introduces persistent backdoors | + +## Why Traditional Security Is Insufficient + +Conventional security tools were designed to distinguish between trusted users and untrusted code. AI agents +fundamentally blur this distinction as they run with user-level permissions, making requests that are indistinguishable +from intentional human actions. A firewall can block connections to known malicious endpoints, but it cannot determine +whether an HTTP POST to a legitimate API represents the user pushing code or an agent exfiltrating private +repositories. The attack surface of an AI agent with shell access is functionally equivalent to the user's entire +environment: every readable file, every executable command, every authenticated service. Sandboxing addresses these +gaps by constraining what the AI can access in the first place, providing defense in depth for an era where the agent +is the user. + +## A Brief History of Sandboxing + +The concept of sandboxing has deep roots in computer science, evolving over decades as systems grew more complex and +security threats more sophisticated. Understanding this evolution provides essential context for modern AI sandboxing +approaches. + +- **Multi-User Systems (1960s-1990s):** The need for isolation originated with mainframe computing. IBM's System/360 + introduced memory protection to prevent one user's program from accessing another's memory space. As computing + transitioned to desktop and server architectures, multi-user operating systems like Unix carried this principle + forward through per-user home directories, file permissions, and process isolation. +- **The Virtualization Era (1970s-2000s):** IBM's VM/370 (1972) enabled multiple operating systems to run on a single + machine in complete isolation. This technology was commercialized for x86 systems by VMware in 1999, making full + OS-level isolation accessible to mainstream computing. Virtual machines remain one of the strongest isolation options + available today. +- **The Container Revolution (2008-2013):** Linux Containers (LXC) emerged in 2008, leveraging kernel features like + cgroups and namespaces to create lightweight containerized environments. Docker (2013) made containerization + accessible to mainstream developers. Containers provide faster startup and lower resource overhead than VMs but share + the host kernel, resulting in a thinner isolation boundary. +- **Browser Sandboxing (2008-Present):** Google Chrome's multi-process architecture (2008) introduced per-tab + sandboxing that became the industry standard. Modern browsers employ multiple isolation layers including site + isolation and WebAssembly sandboxing, which is why web-based AI tools benefit from meaningful isolation by default. +- **Microkernels and Lightweight VMs (2010s-Present):** Projects like gVisor (Google, 2018) and Firecracker (AWS, + 2018) represent the current state of the art: user-space kernels and lightweight virtual machines designed + specifically for running untrusted workloads with minimal overhead. These technologies power the isolation behind + services like AWS Lambda and Google Cloud Run, and are increasingly relevant for production AI workloads. + +## What Is an AI Sandbox? + +An AI sandbox is a controlled, containerized, and sometimes isolated environment designed to contain and monitor AI +system behavior. It creates boundaries that limit what an AI can access and modify, ensuring that even if a model is +compromised or produces unexpected behavior, the impact remains contained within the sandbox boundaries. Effective AI +sandboxes share four key characteristics: isolation (complete separation from production systems and sensitive data), +monitoring (comprehensive logging and observation of all AI actions), resource limits (controlled access to compute, +memory, and network resources), and reversibility (the ability to reset the environment to a known good state). + +## Types of AI Sandboxes + +- **Browser Sandboxes:** Web browsers already execute code in sandboxed environments. When using ChatGPT, Claude, or + other web-based AI tools, the browser isolates them from the rest of the system as they cannot access local files, + install software, or make changes outside the browser tab. File access operates on a whitelist model: users + explicitly upload documents they want the AI to process, which is the inverse of local AI agents that often have + default access to the entire filesystem. For most users, browser-based sandboxing provides sufficient isolation + without any additional configuration. +- **Container-Based Sandboxes:** Technologies like Docker and DevContainers partition AI systems at the operating + system level. Containers share the host kernel but maintain their own filesystem, process space, and network stack. + This provides meaningful isolation with faster startup and lower resource consumption than full virtualization, + making containers well-suited for development workflows and CI/CD pipeline integration. +- **Virtual Machine Sandboxes:** Full virtualization provides the strongest isolation available for local deployment. + Each VM runs its own complete operating system, ensuring that a compromised AI agent inside a VM has no direct path + to the host machine. The tradeoff is higher resource consumption and slower startup times, along with the operational + overhead of maintaining a separate operating system installation. + +## Selecting the Appropriate Sandbox Depth + +The appropriate depth of sandboxing should match your risk tolerance, technical capability, and the sensitivity of +systems the AI agent can access. The spectrum ranges from browser-based isolation requiring zero configuration to +production-grade microVM infrastructure designed for multi-tenant untrusted workloads. The key principle is that +isolation depth should scale with the consequences of a potential breach: AI tools that can only read uploaded +documents require less isolation than agents with shell access, which in turn require less isolation than agents that +can sign blockchain transactions or execute financial operations. + +- **Surface Level - Minimal Setup:** Browser sandboxes (web-based AI tools) and dedicated user accounts or machines. + These require minimal technical expertise and provide strong baseline isolation for casual AI usage. +- **Mid-Depth - Developer-Oriented:** Docker containers, DevContainers, local VMs (Parallels, VMware, VirtualBox, + UTM), and remote VMs (Modal, Sprites). These provide meaningful isolation for development workflows and agent + experimentation with moderate configuration overhead. +- **Deep Isolation - Production-Grade:** Firecracker, gVisor, Qubes OS, nsjail, and bubblewrap. These represent the + highest levels of isolation available and are appropriate for production infrastructure, multi-tenant deployments, + and environments where AI agents interact with high-value assets or irreversible operations. + +## Conclusion + +AI sandboxes represent a critical component in the responsible deployment of artificial intelligence systems. By +providing controlled environments that contain and constrain AI behavior, they bridge the gap between the expanding +capabilities of AI agents and the security requirements of production systems. As AI systems continue to gain autonomy +by executing code, managing infrastructure, and interacting with financial protocols, the necessary investment in +robust sandboxing infrastructure is not merely a best practice but a prerequisite for building AI systems that +organizations and users can trust. + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- gVisor: https://gvisor.dev/docs/ +- nsjail: https://github.com/google/nsjail +- bubblewrap: https://github.com/containers/bubblewrap + +--- + + + diff --git a/docs/pages/devsecops/execution-sandboxing.mdx b/docs/pages/devsecops/execution-sandboxing.mdx new file mode 100644 index 00000000..292fd1d3 --- /dev/null +++ b/docs/pages/devsecops/execution-sandboxing.mdx @@ -0,0 +1,67 @@ +--- +title: "Execution Sandboxing | SEAL" +description: "How to sandbox and isolate execution (tools, code, builds) to reduce blast radius in DevSecOps workflows." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Execution Sandboxing + + + + +Execution sandboxing is the practice of running code, tools, and automation inside tightly constrained environments that limit blast radius, privilege, and side effects. + +In DevSecOps, this applies to: + +- CI jobs and build steps (especially untrusted PRs and third-party actions) +- developer tooling and local scripts +- plugins/extensions and “tool calling” systems (including AI agents) that can trigger real side effects + +Sandboxing should be treated as a primary security control rather than an optional safeguard. + +## Predefined Boundaries and Runtime Enforcement + +Effective sandboxing ensures that even if an execution flow is manipulated (malicious input, compromised dependency, vulnerable plugin, or prompt injection in agentic systems), the resulting behavior cannot escape predefined boundaries. + +In production, sandboxes must be enforced at runtime and applied consistently across: + +- job runners / containers / microVMs +- filesystem and secret access +- network egress +- CPU/memory/time limits + +For Web3 operations, sandboxing is especially critical around wallet tooling, signing flows, and smart contract interfaces, where unintended actions can be irreversible. + +## Consider using + +- Modal - cloud-based sandboxed execution environments for AI agent workloads +- Firecracker (AWS) - lightweight microVMs for untrusted workload isolation +- Docker sandbox patterns for fast development-stage containment +- Parallels, VMware, VirtualBox, UTM, or Qemu for VM-level isolation +- E2B - cloud sandboxes purpose-built for AI agents and code execution + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- gVisor: https://gvisor.dev/docs/ +- Kata Containers: https://katacontainers.io/ +- Docker security: https://docs.docker.com/engine/security/ + +--- + + + diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx index eb2b9617..ad0109b0 100644 --- a/docs/pages/devsecops/index.mdx +++ b/docs/pages/devsecops/index.mdx @@ -13,14 +13,20 @@ title: "Devsecops" - [DevSecOps](/devsecops/overview) - [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) -- [AI Execution Sandboxing](/devsecops/ai-execution-sandboxing) -- [Capability-Based Isolation for AI Agents](/devsecops/capability-based-isolation-for-ai-agents) -- [Sandboxing for Tool and Execution Calls](/devsecops/sandboxing-for-tool-and-execution-calls) -- [Network and Resource Isolation in AI Sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) -- [Sandboxing as a Complement to Execution-Path Enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) -- [AI Execution Sandboxing: A Practical Guide](/devsecops/ai-execution-sandboxing-practical-guide) +- [Execution Sandboxing](/devsecops/execution-sandboxing) +- [Capability-Based Isolation](/devsecops/capability-based-isolation) +- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) +- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) +- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) +- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) - [Implementing Code Signing](/devsecops/code-signing) - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) - [Securing Development Environments](/devsecops/integrated-development-environments) - [Repository Hardening](/devsecops/repository-hardening) - [Security Testing](/devsecops/security-testing) +- [Capability-Based Isolation (moved)](/devsecops/capability-based-isolation-for-ai-agents) +- [Execution Sandboxing (moved)](/devsecops/ai-execution-sandboxing) +- [Execution Sandboxing: Practical Guide (moved)](/devsecops/ai-execution-sandboxing-practical-guide) +- [Network & Resource Isolation (moved)](/devsecops/network-and-resource-isolation-in-ai-sandboxes) +- [Sandboxing & Policy Enforcement (moved)](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) +- [Sandboxing for Tool Execution (moved)](/devsecops/sandboxing-for-tool-and-execution-calls) diff --git a/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx index d47dd815..071bbcf2 100644 --- a/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx +++ b/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx @@ -1,50 +1,8 @@ --- -title: "Network and Resource Isolation in AI Sandboxes | SEAL" -description: "Deny-by-default network and compute isolation strategy for sandboxed AI workloads." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Network & Resource Isolation (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# Network and Resource Isolation in AI Sandboxes - - - - -Network access is one of the most powerful and dangerous capabilities granted to AI systems. Without isolation, models -can be manipulated into exfiltrating data, scanning internal services, or interacting with untrusted external -endpoints. AI sandboxes must enforce strict network policies that default to denial and explicitly allow only required -destinations and protocols. Resource isolation, including CPU, memory, and storage limits, is equally important to -prevent denial-of-service conditions or runaway execution. These controls should be applied dynamically based on agent -role and context rather than statically configured per deployment. In environments where AI agents interact with -decentralized networks, resource and network isolation help prevent unintended propagation across nodes or chains. - -## Consider using - -- Cloudflare - edge DLP and network policy controls for AI traffic -- AccuKnox - zero trust eBPF runtime enforcement for containerized AI workloads -- gVisor (Google) - user-space kernel for granular syscall and network mediation -- Operant AI - API discovery and runtime network access controls for agent ecosystems - -## References - -- Kubernetes Network Policies (concepts): https://kubernetes.io/docs/concepts/services-networking/network-policies/ -- gVisor: https://gvisor.dev/docs/ - ---- - - - +- Canonical page: [/devsecops/network-and-resource-isolation](/devsecops/network-and-resource-isolation) diff --git a/docs/pages/devsecops/network-and-resource-isolation.mdx b/docs/pages/devsecops/network-and-resource-isolation.mdx new file mode 100644 index 00000000..84b60ebe --- /dev/null +++ b/docs/pages/devsecops/network-and-resource-isolation.mdx @@ -0,0 +1,48 @@ +--- +title: "Network & Resource Isolation | SEAL" +description: "Deny-by-default network egress and strict resource limits for sandboxed workloads (CI, tooling, automation)." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Network & Resource Isolation + + + + +Network access is one of the most powerful and dangerous capabilities granted to *any* automated workload (CI runners, build jobs, test harnesses, scripts, plugins, and agentic systems). Without isolation, compromised workloads can exfiltrate data, scan internal services, or interact with untrusted external endpoints. + +Sandboxed workloads should enforce strict network policies that **default to deny** and explicitly allow only required destinations and protocols. Resource isolation (CPU, memory, disk, timeouts) is equally important to prevent denial-of-service conditions, runaway execution, or cost blowups. + +These controls should be applied based on workload risk (e.g., untrusted PRs vs trusted deployments) and context (e.g., jobs that touch secrets), not as a one-size-fits-all static default. + +## Consider using + +- Cloudflare - edge DLP and network policy controls for AI traffic +- AccuKnox - zero trust eBPF runtime enforcement for containerized AI workloads +- gVisor (Google) - user-space kernel for granular syscall and network mediation +- Operant AI - API discovery and runtime network access controls for agent ecosystems + +## References + +- Kubernetes Network Policies (concepts): https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- gVisor: https://gvisor.dev/docs/ + +--- + + + diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 78bb1230..2799fd18 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -35,7 +35,7 @@ Some of the key areas to consider are: 2. Implement automated security testing and monitoring. 3. Development, Operations and Security teams should be aligned and work closely together. 4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. - - See: [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) + - See: [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) (canonical section) --- diff --git a/docs/pages/devsecops/sandboxing-and-isolation.mdx b/docs/pages/devsecops/sandboxing-and-isolation.mdx index f4463c2c..f83ea2e1 100644 --- a/docs/pages/devsecops/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/sandboxing-and-isolation.mdx @@ -27,12 +27,12 @@ Sandboxing and isolation are *implementation controls* used to reduce blast radi ## Pages in this section -- [AI Execution Sandboxing](/devsecops/ai-execution-sandboxing) -- [Capability-Based Isolation for AI Agents](/devsecops/capability-based-isolation-for-ai-agents) -- [Sandboxing for Tool and Execution Calls](/devsecops/sandboxing-for-tool-and-execution-calls) -- [Network and Resource Isolation in AI Sandboxes](/devsecops/network-and-resource-isolation-in-ai-sandboxes) -- [Sandboxing as a Complement to Execution-Path Enforcement](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) -- [AI Execution Sandboxing: A Practical Guide](/devsecops/ai-execution-sandboxing-practical-guide) +- [Execution Sandboxing](/devsecops/execution-sandboxing) +- [Capability-Based Isolation](/devsecops/capability-based-isolation) +- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) +- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) +- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) +- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) ## Notes diff --git a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx new file mode 100644 index 00000000..84b5647d --- /dev/null +++ b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx @@ -0,0 +1,46 @@ +--- +title: "Sandboxing & Policy Enforcement | SEAL" +description: "Defense-in-depth model combining execution-path policy controls with sandbox isolation boundaries." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Sandboxing & Policy Enforcement + + + + +Sandboxing alone does not solve security, but it is a necessary complement to **policy enforcement**. While policy controls determine whether an action should occur, sandboxing constrains what happens if an action is allowed. + +Together, these mechanisms provide defense-in-depth by limiting the impact of mistakes, adversarial behavior, or unforeseen interactions between tools. + +In production, sandboxing should be treated as an always-on control rather than a development-time feature, with continuous validation that isolation boundaries remain intact as systems evolve. + +## Consider using + +- Palo Alto Prisma AIRS + Firecracker - posture management plus runtime microVM guardrails +- Zenity + gVisor - agent-level execution monitoring plus kernel-level isolation +- Cisco AI Defense + E2B - MCP inspection plus isolated code execution sandboxes +- Operant AI + AccuKnox - application-level agent controls plus eBPF infrastructure enforcement + +## References + +- Defense in depth (CISA): https://www.cisa.gov/resources-tools/resources/defense-depth + +--- + + + diff --git a/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx index 5e3ed5aa..87d992bc 100644 --- a/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx +++ b/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx @@ -1,47 +1,8 @@ --- -title: "Sandboxing as a Complement to Execution-Path Enforcement | SEAL" -description: "Defense-in-depth model combining execution-path policy controls with sandbox isolation boundaries." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Sandboxing & Policy Enforcement (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# Sandboxing as a Complement to Execution-Path Enforcement - - - - -Sandboxing alone does not solve AI security, but it is a necessary complement to execution-path enforcement. While -execution-path controls determine whether an action should occur, sandboxing constrains what happens if an action is -allowed. Together, these mechanisms ensure that AI systems remain safe even under partial failure or misclassification. -Sandboxing provides defense in depth by limiting the impact of mistakes, adversarial behavior, or unforeseen -interactions between modalities. In production, sandboxing should be treated as an always-on control rather than a -development-time feature, with continuous validation that isolation boundaries remain intact as systems evolve. - -## Consider using - -- Palo Alto Prisma AIRS + Firecracker - posture management plus runtime microVM guardrails -- Zenity + gVisor - agent-level execution monitoring plus kernel-level isolation -- Cisco AI Defense + E2B - MCP inspection plus isolated code execution sandboxes -- Operant AI + AccuKnox - application-level agent controls plus eBPF infrastructure enforcement - -## References - -- Defense in depth (CISA): https://www.cisa.gov/resources-tools/resources/defense-depth - ---- - - - +- Canonical page: [/devsecops/sandboxing-and-policy-enforcement](/devsecops/sandboxing-and-policy-enforcement) diff --git a/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx index 6d6e3019..3e6124db 100644 --- a/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx +++ b/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx @@ -1,54 +1,8 @@ --- -title: "Sandboxing for Tool and Execution Calls | SEAL" -description: "High-risk tool invocation controls for AI agents with sandboxed execution and runtime policy checks." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +title: "Sandboxing for Tool Execution (moved) | SEAL" +description: "This page moved to a more general DevSecOps slug." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# This page moved - - - -# Sandboxing for Tool and Execution Calls - - - - -AI systems increasingly rely on tools to perform real-world actions, including database queries, API calls, and system -commands. Tool execution represents the highest-risk surface in agentic systems because it bridges model output and -external side effects. Sandboxing for tool execution requires intercepting tool calls before execution and evaluating -them within a controlled environment that enforces policy and resource limits. - -## Restricting Escalation Vectors - -Effective sandboxing restricts network access, -limits execution time, controls input and output size, and prevents chained or recursive tool invocation. -Production-grade sandboxing ensures that tools cannot be abused as escalation vectors even when invoked by a -compromised or misaligned model. For AI agents managing infrastructure, financial operations, or blockchain -interactions, sandboxed tool execution is essential to prevent cascading failures. - -## Consider using - -- E2B - dedicated cloud sandboxes for AI code execution with isolated filesystems and network controls -- Firecracker (AWS) - microVM isolation for ephemeral, resource-constrained tool execution -- Prompt Security - runtime policy enforcement before tool and MCP side effects -- Microsoft Defender for AI - policy evaluation of tool calls before execution - -## References - -- Firecracker: https://firecracker-microvm.github.io/ -- seccomp (Linux): https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html - ---- - - - +- Canonical page: [/devsecops/sandboxing-for-tool-execution](/devsecops/sandboxing-for-tool-execution) diff --git a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx new file mode 100644 index 00000000..c6978440 --- /dev/null +++ b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx @@ -0,0 +1,53 @@ +--- +title: "Sandboxing for Tool Execution | SEAL" +description: "High-risk tool invocation controls for AI agents with sandboxed execution and runtime policy checks." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# Sandboxing for Tool Execution + + + + +DevSecOps workflows increasingly rely on tools to perform real-world actions (database queries, API calls, signing, deployments, and system commands). Tool execution is often the highest-risk surface because it bridges automation output and external side effects. + +Sandboxing for tool execution requires intercepting calls before execution and evaluating them within a controlled environment that enforces policy and resource limits. + +## Restricting Escalation Vectors + +Effective sandboxing restricts network access, +limits execution time, controls input and output size, and prevents chained or recursive tool invocation. +Production-grade sandboxing ensures that tools cannot be abused as escalation vectors even when invoked by a +compromised or misaligned model. For AI agents managing infrastructure, financial operations, or blockchain +interactions, sandboxed tool execution is essential to prevent cascading failures. + +## Consider using + +- E2B - dedicated cloud sandboxes for AI code execution with isolated filesystems and network controls +- Firecracker (AWS) - microVM isolation for ephemeral, resource-constrained tool execution +- Prompt Security - runtime policy enforcement before tool and MCP side effects +- Microsoft Defender for AI - policy evaluation of tool calls before execution + +## References + +- Firecracker: https://firecracker-microvm.github.io/ +- seccomp (Linux): https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html + +--- + + + diff --git a/vocs.config.tsx b/vocs.config.tsx index 540f4a54..3a6b9ae8 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -301,12 +301,12 @@ const config = { items: [ { text: 'Overview', link: '/devsecops/overview', dev: true }, { text: 'Sandboxing & Isolation', link: '/devsecops/sandboxing-and-isolation', dev: true }, - { text: 'AI Execution Sandboxing', link: '/devsecops/ai-execution-sandboxing', dev: true }, - { text: 'Capability-Based Isolation for AI Agents', link: '/devsecops/capability-based-isolation-for-ai-agents', dev: true }, - { text: 'Sandboxing for Tool and Execution Calls', link: '/devsecops/sandboxing-for-tool-and-execution-calls', dev: true }, - { text: 'Network and Resource Isolation in AI Sandboxes', link: '/devsecops/network-and-resource-isolation-in-ai-sandboxes', dev: true }, - { text: 'Sandboxing as a Complement to Execution-Path Enforcement', link: '/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement', dev: true }, - { text: 'AI Execution Sandboxing: A Practical Guide', link: '/devsecops/ai-execution-sandboxing-practical-guide', dev: true }, + { text: 'Execution Sandboxing', link: '/devsecops/execution-sandboxing', dev: true }, + { text: 'Capability-Based Isolation', link: '/devsecops/capability-based-isolation', dev: true }, + { text: 'Sandboxing for Tool Execution', link: '/devsecops/sandboxing-for-tool-execution', dev: true }, + { text: 'Network & Resource Isolation', link: '/devsecops/network-and-resource-isolation', dev: true }, + { text: 'Sandboxing & Policy Enforcement', link: '/devsecops/sandboxing-and-policy-enforcement', dev: true }, + { text: 'Execution Sandboxing: A Practical Guide', link: '/devsecops/execution-sandboxing-practical-guide', dev: true }, { text: 'Code Signing', link: '/devsecops/code-signing', dev: true }, { text: 'Continuous Integration and Deployment', link: '/devsecops/continuous-integration-continuous-deployment', dev: true }, { text: 'Integrated Development Environments', link: '/devsecops/integrated-development-environments', dev: true }, From f746038192c17b99e9949a2f01a7041c35f56b1d Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 03/14] Remove moved stub pages after DevSecOps consolidation (issue #398) (cherry picked from commit 0c0fe91b1b2d5ad420ea39db9ea63f8d90dc5275) --- .../ai-execution-sandboxing-practical-guide.mdx | 12 ------------ docs/pages/ai-security/ai-execution-sandboxing.mdx | 12 ------------ .../capability-based-isolation-for-ai-agents.mdx | 12 ------------ docs/pages/ai-security/index.mdx | 6 ------ ...etwork-and-resource-isolation-in-ai-sandboxes.mdx | 12 ------------ ...as-a-complement-to-execution-path-enforcement.mdx | 12 ------------ .../sandboxing-for-tool-and-execution-calls.mdx | 12 ------------ .../ai-execution-sandboxing-practical-guide.mdx | 8 -------- docs/pages/devsecops/ai-execution-sandboxing.mdx | 8 -------- .../capability-based-isolation-for-ai-agents.mdx | 8 -------- docs/pages/devsecops/index.mdx | 6 ------ ...etwork-and-resource-isolation-in-ai-sandboxes.mdx | 8 -------- ...as-a-complement-to-execution-path-enforcement.mdx | 8 -------- .../sandboxing-for-tool-and-execution-calls.mdx | 8 -------- 14 files changed, 132 deletions(-) delete mode 100644 docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx delete mode 100644 docs/pages/ai-security/ai-execution-sandboxing.mdx delete mode 100644 docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx delete mode 100644 docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx delete mode 100644 docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx delete mode 100644 docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx delete mode 100644 docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx delete mode 100644 docs/pages/devsecops/ai-execution-sandboxing.mdx delete mode 100644 docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx delete mode 100644 docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx delete mode 100644 docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx delete mode 100644 docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx diff --git a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx deleted file mode 100644 index f843a4ad..00000000 --- a/docs/pages/ai-security/ai-execution-sandboxing-practical-guide.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "ai execution sandboxing practical guide (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/execution-sandboxing-practical-guide](/devsecops/execution-sandboxing-practical-guide) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/ai-execution-sandboxing.mdx b/docs/pages/ai-security/ai-execution-sandboxing.mdx deleted file mode 100644 index 0cdf3852..00000000 --- a/docs/pages/ai-security/ai-execution-sandboxing.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "ai execution sandboxing (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/execution-sandboxing](/devsecops/execution-sandboxing) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx b/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx deleted file mode 100644 index a8163bec..00000000 --- a/docs/pages/ai-security/capability-based-isolation-for-ai-agents.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "capability based isolation for ai agents (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/capability-based-isolation](/devsecops/capability-based-isolation) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/index.mdx b/docs/pages/ai-security/index.mdx index 166dcd3e..c382d15e 100644 --- a/docs/pages/ai-security/index.mdx +++ b/docs/pages/ai-security/index.mdx @@ -17,9 +17,3 @@ title: "Ai Security" - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) -- [ai execution sandboxing (moved)](/ai-security/ai-execution-sandboxing) -- [ai execution sandboxing practical guide (moved)](/ai-security/ai-execution-sandboxing-practical-guide) -- [capability based isolation for ai agents (moved)](/ai-security/capability-based-isolation-for-ai-agents) -- [network and resource isolation in ai sandboxes (moved)](/ai-security/network-and-resource-isolation-in-ai-sandboxes) -- [sandboxing as a complement to execution path enforcement (moved)](/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement) -- [sandboxing for tool and execution calls (moved)](/ai-security/sandboxing-for-tool-and-execution-calls) diff --git a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx deleted file mode 100644 index 1efbcc1e..00000000 --- a/docs/pages/ai-security/network-and-resource-isolation-in-ai-sandboxes.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "network and resource isolation in ai sandboxes (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/network-and-resource-isolation](/devsecops/network-and-resource-isolation) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx deleted file mode 100644 index 4ca74152..00000000 --- a/docs/pages/ai-security/sandboxing-as-a-complement-to-execution-path-enforcement.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "sandboxing as a complement to execution path enforcement (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/sandboxing-and-policy-enforcement](/devsecops/sandboxing-and-policy-enforcement) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx deleted file mode 100644 index 78c282d4..00000000 --- a/docs/pages/ai-security/sandboxing-for-tool-and-execution-calls.mdx +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "sandboxing for tool and execution calls (moved) | SEAL" -description: "This page moved to DevSecOps (canonical location)." ---- - -# This content moved - -The canonical version of this page now lives under **DevSecOps**: - -- **New location:** [/devsecops/sandboxing-for-tool-execution](/devsecops/sandboxing-for-tool-execution) - -If you’re reading this within the AI Security framework, the intent is to keep all sandboxing + isolation guidance centralized in DevSecOps, while AI Security focuses on AI-specific threat models and mitigations. diff --git a/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx deleted file mode 100644 index 90abac42..00000000 --- a/docs/pages/devsecops/ai-execution-sandboxing-practical-guide.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Execution Sandboxing: Practical Guide (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/execution-sandboxing-practical-guide](/devsecops/execution-sandboxing-practical-guide) diff --git a/docs/pages/devsecops/ai-execution-sandboxing.mdx b/docs/pages/devsecops/ai-execution-sandboxing.mdx deleted file mode 100644 index 29752973..00000000 --- a/docs/pages/devsecops/ai-execution-sandboxing.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Execution Sandboxing (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/execution-sandboxing](/devsecops/execution-sandboxing) diff --git a/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx b/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx deleted file mode 100644 index 3060e366..00000000 --- a/docs/pages/devsecops/capability-based-isolation-for-ai-agents.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Capability-Based Isolation (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/capability-based-isolation](/devsecops/capability-based-isolation) diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx index ad0109b0..3d318a96 100644 --- a/docs/pages/devsecops/index.mdx +++ b/docs/pages/devsecops/index.mdx @@ -24,9 +24,3 @@ title: "Devsecops" - [Securing Development Environments](/devsecops/integrated-development-environments) - [Repository Hardening](/devsecops/repository-hardening) - [Security Testing](/devsecops/security-testing) -- [Capability-Based Isolation (moved)](/devsecops/capability-based-isolation-for-ai-agents) -- [Execution Sandboxing (moved)](/devsecops/ai-execution-sandboxing) -- [Execution Sandboxing: Practical Guide (moved)](/devsecops/ai-execution-sandboxing-practical-guide) -- [Network & Resource Isolation (moved)](/devsecops/network-and-resource-isolation-in-ai-sandboxes) -- [Sandboxing & Policy Enforcement (moved)](/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement) -- [Sandboxing for Tool Execution (moved)](/devsecops/sandboxing-for-tool-and-execution-calls) diff --git a/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx b/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx deleted file mode 100644 index 071bbcf2..00000000 --- a/docs/pages/devsecops/network-and-resource-isolation-in-ai-sandboxes.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Network & Resource Isolation (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/network-and-resource-isolation](/devsecops/network-and-resource-isolation) diff --git a/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx b/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx deleted file mode 100644 index 87d992bc..00000000 --- a/docs/pages/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Sandboxing & Policy Enforcement (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/sandboxing-and-policy-enforcement](/devsecops/sandboxing-and-policy-enforcement) diff --git a/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx b/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx deleted file mode 100644 index 3e6124db..00000000 --- a/docs/pages/devsecops/sandboxing-for-tool-and-execution-calls.mdx +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Sandboxing for Tool Execution (moved) | SEAL" -description: "This page moved to a more general DevSecOps slug." ---- - -# This page moved - -- Canonical page: [/devsecops/sandboxing-for-tool-execution](/devsecops/sandboxing-for-tool-execution) From af0fcaeee675adeae998c4b176df6c5465140217 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 04/14] Expand DevSecOps sandboxing/isolation guidance with concrete controls and references (issue #398) (cherry picked from commit f56ae553c04216395ddf18a625d1f2e5c20de09a) --- .../devsecops/capability-based-isolation.mdx | 86 ++++- .../execution-sandboxing-practical-guide.mdx | 340 +++++++++--------- docs/pages/devsecops/execution-sandboxing.mdx | 93 +++-- .../network-and-resource-isolation.mdx | 86 ++++- .../devsecops/sandboxing-and-isolation.mdx | 88 ++++- .../sandboxing-and-policy-enforcement.mdx | 80 ++++- .../sandboxing-for-tool-execution.mdx | 84 ++++- 7 files changed, 608 insertions(+), 249 deletions(-) diff --git a/docs/pages/devsecops/capability-based-isolation.mdx b/docs/pages/devsecops/capability-based-isolation.mdx index 94aae34f..c3607049 100644 --- a/docs/pages/devsecops/capability-based-isolation.mdx +++ b/docs/pages/devsecops/capability-based-isolation.mdx @@ -1,6 +1,6 @@ --- title: "Capability-Based Isolation | SEAL" -description: "Capability-scoped isolation patterns for automation operating across tools, APIs, and external systems." +description: "Capability-scoped isolation patterns that replace broad runtime privileges with explicit, auditable permissions." tags: - Engineer/Developer - Security Specialist @@ -22,29 +22,85 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Traditional sandboxing approaches often rely on coarse-grained isolation (e.g., “it’s in a container”), which is often insufficient for real-world DevSecOps workflows that span multiple tools and services. +Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. -Capability-based isolation refines sandboxing by explicitly defining which actions a workload is permitted to perform and under what conditions. Rather than granting broad access to filesystems, networks, or APIs, automation is issued narrowly scoped **capabilities** that are evaluated at execution time. +In practice: do not give a job “admin” rights when it only needs “read dependency metadata” or “upload artifact to one path”. -This model aligns security controls with actual behavior rather than assumed intent. In practice, capability-based isolation lets you safely run automation that can: +## Why this matters in DevSecOps -- read data without writing -- query systems without mutating state -- simulate actions without executing them +Many incidents are privilege-shape failures, not code execution failures: compromised workflows succeed because credentials are too broad. -This is useful for CI workflows, internal bots, and AI agents alike. In decentralized systems, it also maps naturally to permissioned contract calls and limited signing authority. +Capability scoping reduces blast radius by ensuring that even successful compromise has constrained impact. -## Consider using +## Capability model template -- Zenity - secure-by-design policy checks on agent permissions and tool access -- Palo Alto Prisma AIRS - runtime model inspection and granular capability controls -- Operant AI - MCP gateway authentication and capability boundary enforcement -- Cisco AI Defense - capability-scoped guardrails integrated in AI development flow +Define capabilities as structured policy units: + +| Field | Example | +| --- | --- | +| Subject | `ci/workflow/build` | +| Action | `artifact.upload` | +| Resource | `registry.example.com/team/app/*` | +| Conditions | branch is protected, artifact has provenance, session < 15 min | +| Effect | allow / deny | + +## CI/CD capability tiers + +### Tier 1: Validate + +- read repository +- execute tests +- no deploy/publish +- no production secrets + +### Tier 2: Build + +- pull dependencies from approved registries +- upload intermediate artifacts +- no release signing keys + +### Tier 3: Release + +- publish signed artifact +- write release metadata +- deploy only to approved environment targets + +Map these tiers to separate identities/roles rather than toggling permissions in a single long-lived token. + +## Implementation patterns + +- Use workload identity federation (OIDC) for short-lived credentials. +- Create role-per-purpose identities (validate/build/release/deploy). +- Bind capabilities to both identity and runtime context (repo, branch, environment, workflow name). +- Deny by default; add narrow allow rules. + +## Audit and revocation requirements + +For each capability grant, log: + +- who/what requested it +- when it was issued and expired +- what resource/action it enabled +- whether execution succeeded or was denied + +Capability revocation should be immediate and automated for suspicious activity. + +## Common anti-patterns + +- “One token to rule them all” for all pipeline stages. +- Reusing static cloud credentials across repositories. +- Capability definitions without contextual conditions. +- Missing visibility into denied actions (blind spots hide attacks). ## References -- Principle of least privilege (NIST): https://csrc.nist.gov/glossary/term/least_privilege -- Capability-based security (background): https://en.wikipedia.org/wiki/Capability-based_security +- NIST SP 800-53 Rev. 5 (least privilege and access control): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- NIST glossary, *Least Privilege*: https://csrc.nist.gov/glossary/term/least_privilege +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Kubernetes, *Role Based Access Control*: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview --- diff --git a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx index f966ddab..bf050143 100644 --- a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx @@ -1,6 +1,6 @@ --- title: "Execution Sandboxing: A Practical Guide | SEAL" -description: "Practical sandboxing guide with isolation options and deployment-depth recommendations for DevSecOps workflows." +description: "Implementation-focused sandboxing guide for CI/CD, runners, untrusted PR workflows, secrets handling, and network egress control." tags: - Engineer/Developer - Security Specialist @@ -24,192 +24,210 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Modern automation has reached a turning point: it’s no longer limited to passive “advice” or read-only reporting. CI jobs, developer tools, bots, and agents can execute code, browse the web, call APIs, manage local files, and connect directly to production systems. +This guide translates sandboxing principles into concrete controls for real CI/CD environments. -If an automated workflow has shell access, it inherits the same permissions as the runner/user. It can read files, run commands, and authenticate to connected services. Many traditional security controls were built to detect malicious software or suspicious humans; they often struggle to distinguish legitimate automation from compromised automation. +Use it when you need to answer: **“What should we deploy this quarter to materially reduce risk from untrusted execution?”** -## Clear Boundaries Around Access, Execution, and Data Exposure +## Scope and assumptions -Sandboxing fills this gap by limiting what an automated workload can see and do from the outset. Instead of relying only on detection after something goes wrong, sandboxing creates clear boundaries around access, execution, and data exposure. +This playbook focuses on execution risks from: -It reduces blast radius, enforces privilege constraints, and contains unintended side effects whether the issue stems from malicious input, a supply-chain compromise, a configuration mistake, or a tool/agent error. +- untrusted pull requests and dependencies +- shared/self-hosted runners +- build and release tooling with write privileges +- secret exposure and token misuse +- unrestricted network egress -For teams deploying automation that -interact with real systems, isolation is a core requirement rather than an optional safeguard. +It is applicable regardless of whether automation is triggered by scripts, bots, or AI-enabled systems. -## Technical Capability and Risk Tolerance +## 0) Define trust zones first -There is a wide range of sandboxing approaches, depending on technical capability and risk tolerance. For many -non-technical users, browser-based AI tools already offer a layer of separation, since applications running in a tab -cannot freely access the local filesystem or installed software. Developers often turn to Docker containers or remote -virtual machines to create controlled execution environments. At higher levels of assurance, infrastructure teams may -rely on microVM technologies such as Firecracker or gVisor, or hardened operating systems like Qubes OS. The right -approach depends on what the agent can access, what authority it holds, and how severe the consequences of misuse might -be. This calculation becomes especially important in Web3 contexts, where agents may control wallets, interact with -immutable smart contracts, or execute transactions that cannot be undone. +Before implementing controls, classify workflows into trust zones: ---- +| Zone | Typical sources | Allowed outcomes | +| --- | --- | --- | +| Untrusted validation | fork PRs, external contributions, unknown dependencies | lint/test/build checks only | +| Internal trusted CI | protected branches, approved maintainers | artifact build + internal publish | +| Release/deploy | signed tags, release managers, protected environments | production deploy and signing | -The guidance that follows offers practical recommendations for implementing sandboxing across different levels of -expertise and deployment models. It builds on established security principles such as least privilege and layered -isolation, while addressing the distinct behavior of AI-driven systems. Whether you are experimenting locally or -deploying agents in production, the goal is to move from general awareness to concrete safeguards that reduce risk in -meaningful ways. +**Rule:** never run untrusted-zone jobs on release/deploy infrastructure. -## Quick Reference: Sandboxing Recommendations by Technical Level +## 1) Runner isolation baseline -### For Non-Developers +### Required baseline -Most users interacting with AI tools through web interfaces already benefit from browser-level sandboxing. The following -options provide escalating levels of isolation for those who require additional protection: +- Ephemeral runner per job (destroy after completion). +- No privileged containers unless explicitly justified and isolated. +- No host docker socket mount for untrusted jobs. +- Read-only root filesystem where possible. +- Separate runner pools per trust zone. -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Browser-based AI | None | Strong | ChatGPT, Claude web interfaces. Already sandboxed by the browser with no configuration required. | -| Local VM (Parallels, VMware) | Medium | Strong | Running AI tools in a fully isolated virtual machine on your local hardware. | -| Dedicated Machine | High | Strong | Using a separate physical device exclusively for AI tools, providing complete hardware-level isolation. | +### Good defaults for containerized runners -Recommendation: Start with browser-based AI tools, as they are already sandboxed by default. If you need to install AI -software locally, run it inside a virtual machine using Parallels or VMware for strong isolation without requiring deep -technical expertise. +- Drop Linux capabilities by default (`cap-drop=ALL`). +- Use seccomp profile and AppArmor/SELinux policy. +- Set CPU/memory/pids limits. +- Set job timeout and process count limits. -### For Developers +## 2) Safe handling for untrusted PRs -Developer workflows demand flexible sandboxing that accommodates rapid iteration while maintaining meaningful isolation -boundaries. The following options balance security strength against operational overhead: +Untrusted PR execution is the most common CI breach path. -| Option | Effort | Isolation | Best For | -| --- | --- | --- | --- | -| Docker Containers | Low | Moderate | Quick containerized isolation for CLI tools and agents. Shares the host kernel, providing a thinner isolation boundary. | -| Remote VMs (Modal, Sprites) | Low | Strong | Cloud-based sandboxes with pay-per-use pricing. Isolation is managed by the service provider. | -| Local VMs (Parallels, VMware, VirtualBox) | Medium | Strong | Full OS-level isolation on your own hardware with complete control over the environment. | -| Specialized Sandboxes (gVisor, Firecracker) | High | Strong | Production-grade isolation designed for multi-tenant workloads at scale. Purpose-built for running untrusted code. | +### Controls -Recommendation: For local experimentation with AI agents, use Docker or a remote VM service like Modal. For maximum -isolation on your own machine, run a full VM with Parallels or VMware. Specialized tools like gVisor and Firecracker -are designed for production infrastructure deployments rather than local development. +1. Trigger untrusted jobs with minimal token permissions. +2. Do not expose deployment credentials, signing keys, or production secrets. +3. Prevent write operations to protected branches/tags. +4. Restrict artifact publication from untrusted workflows. +5. Apply strict outbound network allowlist. -## Why Sandboxing Matters Now +### GitHub Actions example (least privilege token) -AI systems have crossed a critical threshold: they can now take actions in the real world through code execution, web -browsing, and API interactions. This transforms mistakes or malicious inputs into tangible side effects including -deleted files, exfiltrated credentials, unauthorized purchases, and irreversible on-chain transactions. Native -applications like Claude Cowork and OpenAI Codex change the threat surface further by operating closer to the host -machine and generating new code that can produce unexpected behavior once executed or integrated into existing systems. +```yaml +permissions: + contents: read + pull-requests: read +``` -## The Threat Model +Only grant elevated scopes per job when required. -A practical threat model for AI sandboxing answers three fundamental questions: what assets are at risk (files, -credentials, accounts, billing limits, reputation), what entry points exist (prompts, uploaded files, web pages, tool -outputs, plugin responses), and what permissions the system holds (filesystem access, network egress, API scopes, -command execution). The following table catalogs the primary threat categories that sandboxing must address: +### Important workflow safety note -| Threat | Description | Example | -| --- | --- | --- | -| Data Exfiltration | AI sends sensitive data to external servers | Agent uploads SSH keys while performing routine backup operations | -| Destructive Actions | AI deletes or corrupts files and data | Agent executes recursive file deletion while cleaning temporary directories | -| Resource Exhaustion | AI consumes excessive compute, memory, or network bandwidth | Agent spawns infinite subprocess loops or initiates multi-gigabyte downloads | -| Privilege Escalation | AI gains access beyond its intended scope | Agent modifies system configuration files or installs persistent access tools | -| Lateral Movement | AI accesses adjacent systems via discovered credentials | Agent uses cloud provider keys to provision unauthorized compute resources | -| Prompt Injection | External content hijacks agent behavior | Malicious webpage embeds hidden instructions that the agent follows | -| Supply Chain Compromise | AI is compromised through third-party dependencies | Malicious model weights or plugin code introduces persistent backdoors | - -## Why Traditional Security Is Insufficient - -Conventional security tools were designed to distinguish between trusted users and untrusted code. AI agents -fundamentally blur this distinction as they run with user-level permissions, making requests that are indistinguishable -from intentional human actions. A firewall can block connections to known malicious endpoints, but it cannot determine -whether an HTTP POST to a legitimate API represents the user pushing code or an agent exfiltrating private -repositories. The attack surface of an AI agent with shell access is functionally equivalent to the user's entire -environment: every readable file, every executable command, every authenticated service. Sandboxing addresses these -gaps by constraining what the AI can access in the first place, providing defense in depth for an era where the agent -is the user. - -## A Brief History of Sandboxing - -The concept of sandboxing has deep roots in computer science, evolving over decades as systems grew more complex and -security threats more sophisticated. Understanding this evolution provides essential context for modern AI sandboxing -approaches. - -- **Multi-User Systems (1960s-1990s):** The need for isolation originated with mainframe computing. IBM's System/360 - introduced memory protection to prevent one user's program from accessing another's memory space. As computing - transitioned to desktop and server architectures, multi-user operating systems like Unix carried this principle - forward through per-user home directories, file permissions, and process isolation. -- **The Virtualization Era (1970s-2000s):** IBM's VM/370 (1972) enabled multiple operating systems to run on a single - machine in complete isolation. This technology was commercialized for x86 systems by VMware in 1999, making full - OS-level isolation accessible to mainstream computing. Virtual machines remain one of the strongest isolation options - available today. -- **The Container Revolution (2008-2013):** Linux Containers (LXC) emerged in 2008, leveraging kernel features like - cgroups and namespaces to create lightweight containerized environments. Docker (2013) made containerization - accessible to mainstream developers. Containers provide faster startup and lower resource overhead than VMs but share - the host kernel, resulting in a thinner isolation boundary. -- **Browser Sandboxing (2008-Present):** Google Chrome's multi-process architecture (2008) introduced per-tab - sandboxing that became the industry standard. Modern browsers employ multiple isolation layers including site - isolation and WebAssembly sandboxing, which is why web-based AI tools benefit from meaningful isolation by default. -- **Microkernels and Lightweight VMs (2010s-Present):** Projects like gVisor (Google, 2018) and Firecracker (AWS, - 2018) represent the current state of the art: user-space kernels and lightweight virtual machines designed - specifically for running untrusted workloads with minimal overhead. These technologies power the isolation behind - services like AWS Lambda and Google Cloud Run, and are increasingly relevant for production AI workloads. - -## What Is an AI Sandbox? - -An AI sandbox is a controlled, containerized, and sometimes isolated environment designed to contain and monitor AI -system behavior. It creates boundaries that limit what an AI can access and modify, ensuring that even if a model is -compromised or produces unexpected behavior, the impact remains contained within the sandbox boundaries. Effective AI -sandboxes share four key characteristics: isolation (complete separation from production systems and sensitive data), -monitoring (comprehensive logging and observation of all AI actions), resource limits (controlled access to compute, -memory, and network resources), and reversibility (the ability to reset the environment to a known good state). - -## Types of AI Sandboxes - -- **Browser Sandboxes:** Web browsers already execute code in sandboxed environments. When using ChatGPT, Claude, or - other web-based AI tools, the browser isolates them from the rest of the system as they cannot access local files, - install software, or make changes outside the browser tab. File access operates on a whitelist model: users - explicitly upload documents they want the AI to process, which is the inverse of local AI agents that often have - default access to the entire filesystem. For most users, browser-based sandboxing provides sufficient isolation - without any additional configuration. -- **Container-Based Sandboxes:** Technologies like Docker and DevContainers partition AI systems at the operating - system level. Containers share the host kernel but maintain their own filesystem, process space, and network stack. - This provides meaningful isolation with faster startup and lower resource consumption than full virtualization, - making containers well-suited for development workflows and CI/CD pipeline integration. -- **Virtual Machine Sandboxes:** Full virtualization provides the strongest isolation available for local deployment. - Each VM runs its own complete operating system, ensuring that a compromised AI agent inside a VM has no direct path - to the host machine. The tradeoff is higher resource consumption and slower startup times, along with the operational - overhead of maintaining a separate operating system installation. - -## Selecting the Appropriate Sandbox Depth - -The appropriate depth of sandboxing should match your risk tolerance, technical capability, and the sensitivity of -systems the AI agent can access. The spectrum ranges from browser-based isolation requiring zero configuration to -production-grade microVM infrastructure designed for multi-tenant untrusted workloads. The key principle is that -isolation depth should scale with the consequences of a potential breach: AI tools that can only read uploaded -documents require less isolation than agents with shell access, which in turn require less isolation than agents that -can sign blockchain transactions or execute financial operations. - -- **Surface Level - Minimal Setup:** Browser sandboxes (web-based AI tools) and dedicated user accounts or machines. - These require minimal technical expertise and provide strong baseline isolation for casual AI usage. -- **Mid-Depth - Developer-Oriented:** Docker containers, DevContainers, local VMs (Parallels, VMware, VirtualBox, - UTM), and remote VMs (Modal, Sprites). These provide meaningful isolation for development workflows and agent - experimentation with moderate configuration overhead. -- **Deep Isolation - Production-Grade:** Firecracker, gVisor, Qubes OS, nsjail, and bubblewrap. These represent the - highest levels of isolation available and are appropriate for production infrastructure, multi-tenant deployments, - and environments where AI agents interact with high-value assets or irreversible operations. - -## Conclusion - -AI sandboxes represent a critical component in the responsible deployment of artificial intelligence systems. By -providing controlled environments that contain and constrain AI behavior, they bridge the gap between the expanding -capabilities of AI agents and the security requirements of production systems. As AI systems continue to gain autonomy -by executing code, managing infrastructure, and interacting with financial protocols, the necessary investment in -robust sandboxing infrastructure is not merely a best practice but a prerequisite for building AI systems that -organizations and users can trust. +Avoid using `pull_request_target` to run untrusted code with privileged context unless you fully understand and constrain checkout, permissions, and secret access behavior. + +## 3) Secrets and identity controls + +### Prefer short-lived credentials + +- Use OIDC federation to cloud providers instead of static cloud keys in CI secrets. +- Scope roles per workflow purpose (build-only, publish-only, deploy-only). +- Apply time-bound sessions and audience restrictions. + +### Secret exposure minimization + +- Inject secrets only into jobs that require them. +- Mask and redact logs. +- Mount secrets read-only and avoid writing them to workspace. +- Rotate credentials and invalidate on suspected leakage. + +### Segregate high-impact secrets + +Signing keys, registry publish credentials, and production deploy tokens should be available only in protected environments with approval gates. + +## 4) Network egress control + +Start from **deny all egress**, then open only required destinations. + +### Minimum egress policy structure + +- allow source control host (fetch) +- allow package mirrors/registries needed for build +- allow artifact store +- deny direct access to internal admin/control planes +- deny metadata endpoints unless explicitly required + +### Kubernetes example pattern + +- namespace-per-trust-zone +- default deny egress NetworkPolicy +- explicit allowlist policies per pipeline stage + +## 5) Resource and abuse controls + +Prevent runaway or abusive workloads: + +- CPU/memory/pids quotas per job +- max execution time per stage +- bounded log size and artifact size +- concurrency controls for expensive workflows +- filesystem quota for temporary storage + +These controls reduce denial-of-service risk and limit cost impact from malicious or broken tasks. + +## 6) Build integrity and provenance + +Sandboxing reduces runtime blast radius; integrity controls reduce supply-chain risk. + +Recommended: + +- Generate provenance attestations for build artifacts. +- Sign release artifacts. +- Enforce verification before deployment. +- Use reproducible/deterministic build settings where feasible. + +Use SLSA-aligned controls to define maturity targets over time. + +## 7) Policy gates (before and after execution) + +Implement policy-as-code checks at multiple points: + +- **Pre-execution:** validate workflow configuration (forbidden privileged flags, forbidden secret contexts). +- **Runtime:** enforce admission and sandbox policy (seccomp, allowed images, namespace constraints). +- **Post-execution:** verify provenance/signatures and deployment policy. + +## 8) Logging and incident readiness + +At minimum capture: + +- workflow identity (repo, ref, actor, workflow, runner) +- command/process telemetry (high-risk operations) +- network destinations contacted +- secret access events +- artifact hashes and provenance metadata + +Have a playbook for: + +1. revoke active tokens +2. quarantine runner pool +3. rotate secrets +4. invalidate suspicious artifacts +5. re-run trusted build from clean source + +## 30/60/90 day implementation plan + +### First 30 days + +- Split trusted vs untrusted runner pools. +- Enforce least-privilege CI token defaults. +- Disable secrets in untrusted PR workflows. +- Add job timeouts and resource limits. + +### By day 60 + +- Introduce default-deny egress with allowlists. +- Deploy seccomp/AppArmor (or equivalent) profiles. +- Migrate static cloud credentials to OIDC short-lived roles. + +### By day 90 + +- Add artifact signing and provenance checks. +- Enforce policy-as-code gates for workflow and runtime configuration. +- Run a tabletop exercise for CI compromise response. + +## Operational checklist + +- [ ] Untrusted PRs isolated from privileged runners +- [ ] Ephemeral runners enabled +- [ ] CI token defaults set to read-only +- [ ] No long-lived cloud keys in CI +- [ ] Egress deny-by-default + destination allowlists +- [ ] Seccomp/profile enforcement active +- [ ] Resource quotas and timeouts configured +- [ ] Artifact signing/provenance verified at release +- [ ] Incident response runbook tested ## References -- Firecracker: https://firecracker-microvm.github.io/ -- gVisor: https://gvisor.dev/docs/ -- nsjail: https://github.com/google/nsjail -- bubblewrap: https://github.com/containers/bubblewrap +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-204A, *Building Secure Microservices-based Applications Using Service-Mesh Architecture*: https://csrc.nist.gov/pubs/sp/800/204/a/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- GitHub Actions security hardening: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- SLSA specification: https://slsa.dev/spec/v1.0/overview --- diff --git a/docs/pages/devsecops/execution-sandboxing.mdx b/docs/pages/devsecops/execution-sandboxing.mdx index 292fd1d3..7f4b934f 100644 --- a/docs/pages/devsecops/execution-sandboxing.mdx +++ b/docs/pages/devsecops/execution-sandboxing.mdx @@ -1,6 +1,6 @@ --- title: "Execution Sandboxing | SEAL" -description: "How to sandbox and isolate execution (tools, code, builds) to reduce blast radius in DevSecOps workflows." +description: "How to sandbox execution across CI/CD, build tooling, and automation to reduce blast radius and prevent privilege abuse." tags: - Engineer/Developer - Security Specialist @@ -23,43 +23,88 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Execution sandboxing is the practice of running code, tools, and automation inside tightly constrained environments that limit blast radius, privilege, and side effects. +Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. In DevSecOps, this applies to: -- CI jobs and build steps (especially untrusted PRs and third-party actions) -- developer tooling and local scripts -- plugins/extensions and “tool calling” systems (including AI agents) that can trigger real side effects +- CI jobs and build/test pipelines +- package manager hooks and third-party actions +- deployment automation and release tooling +- developer scripts and internal bots +- AI-enabled automation (one category of tool execution) -Sandboxing should be treated as a primary security control rather than an optional safeguard. +## Core security properties -## Predefined Boundaries and Runtime Enforcement +A production-grade sandbox should provide: -Effective sandboxing ensures that even if an execution flow is manipulated (malicious input, compromised dependency, vulnerable plugin, or prompt injection in agentic systems), the resulting behavior cannot escape predefined boundaries. +1. **Isolation**: workload cannot freely access host resources or adjacent tenants. +2. **Least privilege**: runtime identity and tokens are scoped to minimum required actions. +3. **Constrained side effects**: filesystem, network, and API access are explicitly bounded. +4. **Ephemerality**: runtime is short-lived and reset between jobs. +5. **Auditability**: execution is logged with enough detail for incident response. -In production, sandboxes must be enforced at runtime and applied consistently across: +## Boundary design: what to isolate -- job runners / containers / microVMs -- filesystem and secret access -- network egress -- CPU/memory/time limits +Treat these as separate enforcement planes: -For Web3 operations, sandboxing is especially critical around wallet tooling, signing flows, and smart contract interfaces, where unintended actions can be irreversible. +| Plane | Typical risks | Required controls | +| --- | --- | --- | +| Process/syscall | container escape, host tampering | seccomp, no `--privileged`, capability drops, AppArmor/SELinux | +| Filesystem | credential theft, workspace poisoning | read-only rootfs, isolated workspace, explicit writable mounts | +| Identity | token abuse, cloud account takeover | short-lived credentials, OIDC federation, scoped IAM | +| Network | data exfiltration, lateral movement | default-deny egress, destination allowlist, proxy/inspection | +| Resources | denial of service, budget burn | CPU/memory/pids/time limits, quotas, max concurrency | -## Consider using +## Choosing the runtime isolation level -- Modal - cloud-based sandboxed execution environments for AI agent workloads -- Firecracker (AWS) - lightweight microVMs for untrusted workload isolation -- Docker sandbox patterns for fast development-stage containment -- Parallels, VMware, VirtualBox, UTM, or Qemu for VM-level isolation -- E2B - cloud sandboxes purpose-built for AI agents and code execution +| Runtime option | Isolation strength | Operational overhead | Typical fit | +| --- | --- | --- | --- | +| Standard containers | Moderate | Low | Low-risk build/test steps with strict hardening | +| Hardened containers (rootless + seccomp/AppArmor) | Moderate-strong | Medium | Most CI validation workflows | +| Sandboxed containers (gVisor/Kata) | Strong | Medium-high | Untrusted code in shared infrastructure | +| MicroVMs (Firecracker) | Strong | High | High-risk multi-tenant runners and privileged pipelines | +| Full VMs | Strongest boundary | High | Regulated workloads or high-impact deployment/signing paths | + +## CI/CD-specific patterns + +### 1) Split trust zones + +- **Zone A: Untrusted PR validation** (forks, external code) + - no long-lived secrets + - restricted CI token permissions + - no deploy/publish capability +- **Zone B: Trusted branch/release** + - controlled secret access + - protected environments and approvals + - provenance + signing requirements + +### 2) Use ephemeral runners + +Each job should run on fresh infrastructure and be destroyed after completion. Avoid shared mutable state and persistent credentials between jobs. + +### 3) Restrict privileged paths + +Build, sign, publish, and deploy should be distinct stages with explicit policy gates and auditable approvals. + +## Common failure modes + +- Treating “containerized” as automatically secure. +- Running untrusted PR code on persistent or privileged runners. +- Reusing static secrets in CI variables. +- Allowing unrestricted egress from build jobs. +- Granting broad default CI token permissions. ## References -- Firecracker: https://firecracker-microvm.github.io/ -- gVisor: https://gvisor.dev/docs/ -- Kata Containers: https://katacontainers.io/ -- Docker security: https://docs.docker.com/engine/security/ +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- gVisor documentation: https://gvisor.dev/docs/ +- Kata Containers documentation: https://github.com/kata-containers/documentation +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs --- diff --git a/docs/pages/devsecops/network-and-resource-isolation.mdx b/docs/pages/devsecops/network-and-resource-isolation.mdx index 84b60ebe..828a2b3e 100644 --- a/docs/pages/devsecops/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/network-and-resource-isolation.mdx @@ -1,6 +1,6 @@ --- title: "Network & Resource Isolation | SEAL" -description: "Deny-by-default network egress and strict resource limits for sandboxed workloads (CI, tooling, automation)." +description: "Deny-by-default network and strict resource governance for CI/CD jobs, runners, and sandboxed automation workloads." tags: - Engineer/Developer - Security Specialist @@ -24,23 +24,87 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Network access is one of the most powerful and dangerous capabilities granted to *any* automated workload (CI runners, build jobs, test harnesses, scripts, plugins, and agentic systems). Without isolation, compromised workloads can exfiltrate data, scan internal services, or interact with untrusted external endpoints. +Network and compute controls are critical containment layers for sandboxed execution. -Sandboxed workloads should enforce strict network policies that **default to deny** and explicitly allow only required destinations and protocols. Resource isolation (CPU, memory, disk, timeouts) is equally important to prevent denial-of-service conditions, runaway execution, or cost blowups. +Without them, a compromised build or tool can: -These controls should be applied based on workload risk (e.g., untrusted PRs vs trusted deployments) and context (e.g., jobs that touch secrets), not as a one-size-fits-all static default. +- exfiltrate source code and secrets +- scan internal services and pivot laterally +- abuse infrastructure through runaway jobs +- create cost spikes via unbounded resource usage -## Consider using +## Network isolation model -- Cloudflare - edge DLP and network policy controls for AI traffic -- AccuKnox - zero trust eBPF runtime enforcement for containerized AI workloads -- gVisor (Google) - user-space kernel for granular syscall and network mediation -- Operant AI - API discovery and runtime network access controls for agent ecosystems +### 1) Default deny egress + +Start with no outbound access. Add explicit allow rules only for required destinations (SCM host, package registries, artifact storage, approved APIs). + +### 2) Separate trust zones + +Use distinct network boundaries for: + +- untrusted PR validation +- internal trusted builds +- release/deploy pipelines + +Do not allow direct network paths from untrusted workloads to sensitive control planes. + +### 3) Constrain DNS and metadata access + +- Restrict DNS resolvers and block arbitrary external name resolution where feasible. +- Deny access to cloud metadata endpoints from untrusted jobs unless explicitly required. + +### 4) Centralize outbound controls + +For mature environments, route egress through policy-enforcing gateways/proxies to monitor and block prohibited destinations. + +## Resource isolation model + +Enforce limits at runner and workload level: + +- CPU and memory limits per job/container +- process count (`pids`) limits +- filesystem and artifact size limits +- execution timeout limits +- concurrency limits per workflow/repository + +These controls are both security and reliability controls. + +## CI/CD implementation checklist + +- [ ] Untrusted jobs run in isolated runner pool +- [ ] Default-deny egress applied to untrusted zone +- [ ] Destination allowlists documented per pipeline stage +- [ ] Metadata service access restricted +- [ ] CPU/memory/pids limits configured +- [ ] Job and step timeouts enforced +- [ ] Max artifact/log size capped + +## Example control matrix + +| Workload type | Egress policy | Resource policy | +| --- | --- | --- | +| Fork PR validation | deny-by-default, minimal allowlist | strict CPU/memory/time limits | +| Internal CI build | allow required registries/APIs only | moderate limits, queue controls | +| Release/deploy | highly specific allowlist to deployment targets | conservative limits + approval gates | + +## Common anti-patterns + +- “Allow all egress” for convenience in CI. +- Reusing a single runner network profile for all trust levels. +- Missing job timeouts (infinite loops become outages). +- Unlimited artifact uploads from untrusted workflows. ## References -- Kubernetes Network Policies (concepts): https://kubernetes.io/docs/concepts/services-networking/network-policies/ -- gVisor: https://gvisor.dev/docs/ +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5 (network and resource control families): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- Kubernetes, *Resource Management for Pods and Containers*: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- gVisor documentation: https://gvisor.dev/docs/ +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs --- diff --git a/docs/pages/devsecops/sandboxing-and-isolation.mdx b/docs/pages/devsecops/sandboxing-and-isolation.mdx index f83ea2e1..1112eadb 100644 --- a/docs/pages/devsecops/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/sandboxing-and-isolation.mdx @@ -1,6 +1,6 @@ --- title: "Sandboxing & Isolation | SEAL" -description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across builds, tooling, and execution environments." +description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across CI/CD, runners, tooling, and execution environments." tags: - Engineer/Developer - Security Specialist @@ -21,22 +21,86 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -This section is the **canonical home** for guidance on sandboxing, isolation, and containment as part of DevSecOps. +This section is the canonical DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). -Sandboxing and isolation are *implementation controls* used to reduce blast radius when running untrusted or semi-trusted code and workflows (CI steps, build tooling, plugins, scripts, AI tool calls, etc.). +The core objective is simple: **assume compromise can happen, then contain blast radius by design**. -## Pages in this section +## What to protect (threat model quickstart) -- [Execution Sandboxing](/devsecops/execution-sandboxing) -- [Capability-Based Isolation](/devsecops/capability-based-isolation) -- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) -- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) -- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) -- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) +Treat sandboxing decisions as a threat-modeling exercise across four dimensions: -## Notes +| Dimension | Questions to answer | +| --- | --- | +| Assets | What can be stolen or modified? (source code, signing keys, CI secrets, deployment credentials, artifacts, production APIs) | +| Entry points | What can trigger execution? (fork PRs, dependencies, build scripts, test fixtures, webhooks, external APIs) | +| Privileges | What authority does runtime hold? (filesystem write, network egress, cloud IAM, package publish, deployment rights) | +| Impact | What is worst-case outcome? (secret exfiltration, artifact tampering, lateral movement, production change, financial loss) | -AI Security pages that previously hosted this material now link here so that isolation guidance stays centralized and consistent. +**Default assumption:** code from external contributors, third-party actions, and newly introduced dependencies are untrusted until verified. + +## Decision tree: choose isolation depth + +Use this practical decision flow before assigning a runtime: + +1. **Does the workload process untrusted input or untrusted code?** + - If yes, run in an ephemeral sandbox (container with hardened profile at minimum; microVM/VM for higher assurance). +2. **Can the workload access secrets, signing keys, cloud credentials, or production systems?** + - If yes, enforce stronger isolation boundary, short-lived credentials, and explicit approval gates. +3. **Is outbound network required?** + - If no, deny all egress. + - If yes, allowlist destinations and force traffic through inspection/proxy controls. +4. **Can it modify persistent state (artifact repo, registry, infra, chain, database)?** + - If yes, require policy checks + attestation + auditable identity before execution. +5. **Is this multi-tenant shared runner infrastructure?** + - If yes, isolate per job with ephemeral workers and avoid secret reuse across jobs. + +If you answer “yes” to multiple high-risk questions, prefer **microVM/VM isolation plus strict policy enforcement**. + +## Layered control map (defense in depth) + +No single mechanism is sufficient. Apply multiple layers together: + +| Layer | Control objective | Typical controls | +| --- | --- | --- | +| Identity | Bind execution to least privilege identity | OIDC federation, short-lived tokens, scoped IAM roles | +| Execution boundary | Prevent host escape / cross-tenant impact | seccomp, AppArmor/SELinux, rootless containers, gVisor/Kata/Firecracker | +| Filesystem & secrets | Prevent sensitive data exposure | read-only rootfs, isolated workdir, mounted secret scopes, no long-lived credentials | +| Network | Prevent exfiltration and lateral movement | default-deny egress, DNS restrictions, NetworkPolicy, egress proxy | +| Resource governance | Prevent abuse and runaway cost | CPU/memory/pids/time limits, quotas, job timeout, concurrency caps | +| Integrity & provenance | Detect tampering and unauthorized changes | signed artifacts, provenance attestations, immutable logs, SLSA controls | +| Policy & response | Enforce and verify continuously | policy-as-code gates, runtime audit logs, alerting, incident playbooks | + +## Baseline controls for CI/CD and runners + +At minimum, enforce the following: + +- Separate **untrusted PR runners** from trusted build/deploy runners. +- Use **ephemeral runners** (fresh environment per job, no state reuse). +- Disable or heavily constrain secrets for forked PR jobs. +- Restrict CI token scopes to least privilege (`read` by default). +- Deny outbound network by default; allow only required hosts. +- Run with syscall and privilege restrictions (`seccomp`, no privileged mode, no host mounts unless strictly required). +- Sign and attest release artifacts before publish/deploy. + +## Start here (section map) + +- [Execution Sandboxing](/devsecops/execution-sandboxing) — principles and runtime design choices. +- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) — implementation blueprint for teams and platforms. +- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) — egress controls, quotas, and anti-exfiltration patterns. +- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) — controlling high-risk tool calls and side effects. +- [Capability-Based Isolation](/devsecops/capability-based-isolation) — breaking broad permissions into constrained capabilities. +- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) — integrating policy-as-code with runtime isolation. + +## References + +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview --- diff --git a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx index 84b5647d..7c6f5ecc 100644 --- a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx @@ -1,6 +1,6 @@ --- title: "Sandboxing & Policy Enforcement | SEAL" -description: "Defense-in-depth model combining execution-path policy controls with sandbox isolation boundaries." +description: "Defense-in-depth model that combines runtime isolation with policy-as-code across CI/CD and automation workflows." tags: - Engineer/Developer - Security Specialist @@ -23,22 +23,82 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -Sandboxing alone does not solve security, but it is a necessary complement to **policy enforcement**. While policy controls determine whether an action should occur, sandboxing constrains what happens if an action is allowed. +Sandboxing and policy enforcement solve different problems and must be used together: -Together, these mechanisms provide defense-in-depth by limiting the impact of mistakes, adversarial behavior, or unforeseen interactions between tools. +- **Policy** decides what should be allowed. +- **Sandboxing** limits damage when allowed actions fail, are abused, or are bypassed. -In production, sandboxing should be treated as an always-on control rather than a development-time feature, with continuous validation that isolation boundaries remain intact as systems evolve. +Using only one layer leaves material gaps. -## Consider using +## Three policy checkpoints -- Palo Alto Prisma AIRS + Firecracker - posture management plus runtime microVM guardrails -- Zenity + gVisor - agent-level execution monitoring plus kernel-level isolation -- Cisco AI Defense + E2B - MCP inspection plus isolated code execution sandboxes -- Operant AI + AccuKnox - application-level agent controls plus eBPF infrastructure enforcement +| Checkpoint | Purpose | Typical examples | +| --- | --- | --- | +| Pre-execution | block unsafe configuration before run starts | deny privileged runner flags, deny forbidden workflow triggers | +| Runtime | enforce constraints during execution | seccomp/AppArmor, pod security admission, network policy | +| Post-execution | verify integrity before promotion/deploy | signature verification, provenance checks, policy attestations | + +## CI/CD control stack + +A practical stack for pipelines: + +1. **Workflow policy** + - lint and validate pipeline definitions + - require least-privilege token settings +2. **Runner/runtime policy** + - enforce non-privileged execution + - require sandbox profile and resource limits +3. **Artifact/release policy** + - enforce signed artifacts and provenance before publish/deploy +4. **Environment policy** + - require approvals for production mutation paths + +## Threat-to-control mapping + +| Threat | Policy control | Sandbox control | +| --- | --- | --- | +| Secret exfiltration | deny secret injection into untrusted workflows | filesystem isolation + egress allowlist | +| Runner compromise | deny privileged execution configs | syscall filtering + ephemeral runner | +| Supply-chain tampering | require trusted source and attestation | isolated build runtime + immutable logs | +| Unauthorized deploy | branch/environment approvals | isolated deploy runner with scoped identity | + +## Maturity model + +### Level 1 (baseline) + +- static policy checks for CI configuration +- isolated runners for untrusted PRs +- least-privilege CI tokens + +### Level 2 (intermediate) + +- runtime admission/enforcement policies +- default-deny network egress +- short-lived credentials via federation + +### Level 3 (advanced) + +- signed provenance verification on promotion +- policy decision logging with centralized audit +- periodic control validation exercises (breakout tests/tabletops) + +## Common anti-patterns + +- Writing policy that is never enforced at runtime. +- Treating sandbox exceptions as permanent defaults. +- Failing open when policy engine is unavailable. +- Skipping auditability for policy decisions. ## References -- Defense in depth (CISA): https://www.cisa.gov/resources-tools/resources/defense-depth +- NIST SP 800-53 Rev. 5 (policy, audit, and access controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Kubernetes, *Admission Controllers*: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview --- diff --git a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx index c6978440..3aae08fa 100644 --- a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx @@ -1,6 +1,6 @@ --- title: "Sandboxing for Tool Execution | SEAL" -description: "High-risk tool invocation controls for AI agents with sandboxed execution and runtime policy checks." +description: "Controls for high-risk tool invocation in automation workflows: policy checks, constrained runtime, and auditable side effects." tags: - Engineer/Developer - Security Specialist @@ -23,29 +23,81 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -DevSecOps workflows increasingly rely on tools to perform real-world actions (database queries, API calls, signing, deployments, and system commands). Tool execution is often the highest-risk surface because it bridges automation output and external side effects. +Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. -Sandboxing for tool execution requires intercepting calls before execution and evaluating them within a controlled environment that enforces policy and resource limits. +This is often the highest-risk path in DevSecOps workflows. -## Restricting Escalation Vectors +## Design principle -Effective sandboxing restricts network access, -limits execution time, controls input and output size, and prevents chained or recursive tool invocation. -Production-grade sandboxing ensures that tools cannot be abused as escalation vectors even when invoked by a -compromised or misaligned model. For AI agents managing infrastructure, financial operations, or blockchain -interactions, sandboxed tool execution is essential to prevent cascading failures. +Treat every tool call as an untrusted request until it passes policy checks. -## Consider using +A secure flow is: -- E2B - dedicated cloud sandboxes for AI code execution with isolated filesystems and network controls -- Firecracker (AWS) - microVM isolation for ephemeral, resource-constrained tool execution -- Prompt Security - runtime policy enforcement before tool and MCP side effects -- Microsoft Defender for AI - policy evaluation of tool calls before execution +1. **Intent validation** (is this action allowed?) +2. **Capability check** (does this runtime identity hold required permission?) +3. **Sandboxed execution** (bounded filesystem/network/resources) +4. **Audit and verification** (what happened, by whom, with what result?) + +## Tool risk tiers + +| Tier | Example actions | Minimum controls | +| --- | --- | --- | +| Low | read repo files, query status APIs | read-only tokens, no secret access | +| Medium | create PR comments, upload artifacts | scoped write perms, output size limits | +| High | merge, deploy, publish package, modify infra | approval gates, protected environment, strong sandbox | +| Critical | key usage, signing, production data mutation | dedicated isolated runtime, multi-party approval, full audit trail | + +## Practical controls + +### Restrict execution context + +- run tool calls in ephemeral runtime +- use read-only root filesystem where feasible +- block host mounts unless explicitly required +- apply seccomp/AppArmor/SELinux enforcement + +### Restrict identity and credentials + +- issue short-lived, scoped credentials +- bind tokens to specific tool purpose and environment +- disable ambient credentials in untrusted workflows + +### Restrict network side effects + +- deny-by-default egress +- allowlist specific endpoints per tool +- block direct access to internal admin APIs from low-trust jobs + +### Restrict invocation behavior + +- maximum execution time +- command/input/output size limits +- prevent recursive tool chaining unless explicitly allowed +- require explicit confirmation for high-risk operations + +## Policy examples for CI/CD tooling + +- “Untrusted PR jobs may run read-only analysis tools but cannot trigger deployment tools.” +- “Release tooling may publish only signed artifacts generated in the same pipeline.” +- “Infrastructure mutation tools require protected branch + approval + provenance verification.” + +## Common anti-patterns + +- Directly mapping user input to shell execution without policy mediation. +- Reusing broad admin credentials across multiple tools. +- Allowing tool calls to inherit unrestricted network access. +- Missing audit logs for high-impact tool operations. ## References -- Firecracker: https://firecracker-microvm.github.io/ -- seccomp (Linux): https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- NIST SP 800-53 Rev. 5 (least privilege, audit, execution controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs +- gVisor documentation: https://gvisor.dev/docs/ --- From 33460e88d97617d70da7ee627b6e31dc429d0da2 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 05/14] docs(devsecops): add links to key DevSecOps pages (cherry picked from commit 0be5d0c7a979c49c78efc05dad1f1e804f53cb5b) --- docs/pages/devsecops/overview.mdx | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 2799fd18..2646c601 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -37,6 +37,21 @@ Some of the key areas to consider are: 4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. - See: [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) (canonical section) +## What’s inside DevSecOps + +- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. +- [Execution Sandboxing](/devsecops/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. +- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. +- [Capability-Based Isolation](/devsecops/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. +- [Network & Resource Isolation](/devsecops/network-and-resource-isolation): Enforce deny-by-default networking and strict CPU/memory/resource boundaries. +- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution): Secure high-risk tool invocation with constrained runtime and auditable effects. +- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement): Combine sandbox boundaries with policy-as-code for defense in depth. +- [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment): Build safer pipelines with testing, scanning, deterministic builds, and access controls. +- [Repository Hardening](/devsecops/repository-hardening): Protect repos with branch policies, signed commits, and hardened automation settings. +- [Security Testing](/devsecops/security-testing): Shift-left with SAST, DAST, IAST, and fuzzing to catch issues early. +- [Implementing Code Signing](/devsecops/code-signing): Strengthen integrity with signed commits/PRs and disciplined key management. +- [Securing Development Environments](/devsecops/integrated-development-environments): Reduce IDE and local environment risk with trusted tooling and isolation. + --- From a769ba28f1aba12a78e51bb73b50a2f00f6b9292 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 06/14] Reorganize DevSecOps isolation/sandboxing navigation (cherry picked from commit 6a4aecfb71ec4216ea97165b82d92c1d68fa65bf) --- docs/pages/devsecops/overview.mdx | 15 +++++++------- utils/fetched-tags.json | 33 ++++++++++++++++--------------- vocs.config.tsx | 20 ++++++++++++------- 3 files changed, 38 insertions(+), 30 deletions(-) diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 2646c601..5d3cef8a 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -39,13 +39,14 @@ Some of the key areas to consider are: ## What’s inside DevSecOps -- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. -- [Execution Sandboxing](/devsecops/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. -- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. -- [Capability-Based Isolation](/devsecops/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. -- [Network & Resource Isolation](/devsecops/network-and-resource-isolation): Enforce deny-by-default networking and strict CPU/memory/resource boundaries. -- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution): Secure high-risk tool invocation with constrained runtime and auditable effects. -- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement): Combine sandbox boundaries with policy-as-code for defense in depth. +- **Isolation & Sandboxing** + - [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. + - [Execution Sandboxing](/devsecops/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. + - [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. + - [Capability-Based Isolation](/devsecops/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. + - [Network & Resource Isolation](/devsecops/network-and-resource-isolation): Enforce deny-by-default networking and strict CPU/memory/resource boundaries. + - [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution): Secure high-risk tool invocation with constrained runtime and auditable effects. + - [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement): Combine sandbox boundaries with policy-as-code for defense in depth. - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment): Build safer pipelines with testing, scanning, deterministic builds, and access controls. - [Repository Hardening](/devsecops/repository-hardening): Protect repos with branch policies, signed commits, and hardened automation settings. - [Security Testing](/devsecops/security-testing): Shift-left with SAST, DAST, IAST, and fuzzing to catch issues early. diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 338c53c3..02d3a959 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -159,41 +159,41 @@ "/community-management/twitter": [ "Community & Marketing" ], - "/devsecops/ai-execution-sandboxing-practical-guide": [ + "/devsecops/capability-based-isolation": [ "Engineer/Developer", "Security Specialist", - "Operations & Strategy", - "Devops", - "SRE" + "Operations & Strategy" ], - "/devsecops/ai-execution-sandboxing": [ + "/devsecops/code-signing": [ "Engineer/Developer", "Security Specialist", - "Operations & Strategy", "Devops" ], - "/devsecops/capability-based-isolation-for-ai-agents": [ + "/devsecops/continuous-integration-continuous-deployment": [ "Engineer/Developer", "Security Specialist", - "Operations & Strategy" + "Devops", + "SRE" ], - "/devsecops/code-signing": [ + "/devsecops/execution-sandboxing-practical-guide": [ "Engineer/Developer", "Security Specialist", - "Devops" + "Operations & Strategy", + "Devops", + "SRE" ], - "/devsecops/continuous-integration-continuous-deployment": [ + "/devsecops/execution-sandboxing": [ "Engineer/Developer", "Security Specialist", - "Devops", - "SRE" + "Operations & Strategy", + "Devops" ], "/devsecops/integrated-development-environments": [ "Engineer/Developer", "Security Specialist", "Devops" ], - "/devsecops/network-and-resource-isolation-in-ai-sandboxes": [ + "/devsecops/network-and-resource-isolation": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", @@ -217,13 +217,13 @@ "Operations & Strategy", "Devops" ], - "/devsecops/sandboxing-as-a-complement-to-execution-path-enforcement": [ + "/devsecops/sandboxing-and-policy-enforcement": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", "Devops" ], - "/devsecops/sandboxing-for-tool-and-execution-calls": [ + "/devsecops/sandboxing-for-tool-execution": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", @@ -1118,6 +1118,7 @@ "DPRK IT Workers": "dprk-it-workers", "Governance": "governance", "DevSecOps": "devsecops", + "Isolation & Sandboxing": "devsecops", "Privacy": "privacy", "Supply Chain": "supply-chain", "Security Automation": "security-automation", diff --git a/vocs.config.tsx b/vocs.config.tsx index 3a6b9ae8..8309edd4 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -300,13 +300,19 @@ const config = { dev: true, items: [ { text: 'Overview', link: '/devsecops/overview', dev: true }, - { text: 'Sandboxing & Isolation', link: '/devsecops/sandboxing-and-isolation', dev: true }, - { text: 'Execution Sandboxing', link: '/devsecops/execution-sandboxing', dev: true }, - { text: 'Capability-Based Isolation', link: '/devsecops/capability-based-isolation', dev: true }, - { text: 'Sandboxing for Tool Execution', link: '/devsecops/sandboxing-for-tool-execution', dev: true }, - { text: 'Network & Resource Isolation', link: '/devsecops/network-and-resource-isolation', dev: true }, - { text: 'Sandboxing & Policy Enforcement', link: '/devsecops/sandboxing-and-policy-enforcement', dev: true }, - { text: 'Execution Sandboxing: A Practical Guide', link: '/devsecops/execution-sandboxing-practical-guide', dev: true }, + { + text: 'Isolation & Sandboxing', + collapsed: false, + items: [ + { text: 'Sandboxing & Isolation', link: '/devsecops/sandboxing-and-isolation', dev: true }, + { text: 'Execution Sandboxing', link: '/devsecops/execution-sandboxing', dev: true }, + { text: 'Capability-Based Isolation', link: '/devsecops/capability-based-isolation', dev: true }, + { text: 'Sandboxing for Tool Execution', link: '/devsecops/sandboxing-for-tool-execution', dev: true }, + { text: 'Network & Resource Isolation', link: '/devsecops/network-and-resource-isolation', dev: true }, + { text: 'Sandboxing & Policy Enforcement', link: '/devsecops/sandboxing-and-policy-enforcement', dev: true }, + { text: 'Execution Sandboxing: A Practical Guide', link: '/devsecops/execution-sandboxing-practical-guide', dev: true }, + ] + }, { text: 'Code Signing', link: '/devsecops/code-signing', dev: true }, { text: 'Continuous Integration and Deployment', link: '/devsecops/continuous-integration-continuous-deployment', dev: true }, { text: 'Integrated Development Environments', link: '/devsecops/integrated-development-environments', dev: true }, From 9ec7e3674276d77fab52e521d501ce6bf36efe49 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 07/14] docs(devsecops): group isolation guides under dedicated section --- docs/pages/ai-security/overview.mdx | 2 +- .../devsecops/capability-based-isolation.mdx | 106 +------- .../execution-sandboxing-practical-guide.mdx | 233 +---------------- docs/pages/devsecops/execution-sandboxing.mdx | 110 +------- docs/pages/devsecops/index.mdx | 15 +- .../isolation/capability-based-isolation.mdx | 108 ++++++++ .../execution-sandboxing-practical-guide.mdx | 235 ++++++++++++++++++ .../isolation/execution-sandboxing.mdx | 112 +++++++++ docs/pages/devsecops/isolation/index.mdx | 20 ++ .../network-and-resource-isolation.mdx | 112 +++++++++ .../isolation/sandboxing-and-isolation.mdx | 108 ++++++++ .../sandboxing-and-policy-enforcement.mdx | 106 ++++++++ .../sandboxing-for-tool-execution.mdx | 105 ++++++++ .../network-and-resource-isolation.mdx | 110 +------- docs/pages/devsecops/overview.mdx | 16 +- .../devsecops/sandboxing-and-isolation.mdx | 106 +------- .../sandboxing-and-policy-enforcement.mdx | 104 +------- .../sandboxing-for-tool-execution.mdx | 103 +------- utils/fetched-tags.json | 46 ++-- vocs.config.tsx | 16 +- 20 files changed, 982 insertions(+), 891 deletions(-) create mode 100644 docs/pages/devsecops/isolation/capability-based-isolation.mdx create mode 100644 docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx create mode 100644 docs/pages/devsecops/isolation/execution-sandboxing.mdx create mode 100644 docs/pages/devsecops/isolation/index.mdx create mode 100644 docs/pages/devsecops/isolation/network-and-resource-isolation.mdx create mode 100644 docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx create mode 100644 docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx create mode 100644 docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx diff --git a/docs/pages/ai-security/overview.mdx b/docs/pages/ai-security/overview.mdx index bff86a34..bf093cec 100644 --- a/docs/pages/ai-security/overview.mdx +++ b/docs/pages/ai-security/overview.mdx @@ -124,7 +124,7 @@ specific deployment models and risk tolerance. - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) -- [Sandboxing & Isolation (canonical)](/devsecops/sandboxing-and-isolation) +- [Sandboxing & Isolation (canonical)](/devsecops/isolation/sandboxing-and-isolation) --- diff --git a/docs/pages/devsecops/capability-based-isolation.mdx b/docs/pages/devsecops/capability-based-isolation.mdx index c3607049..a15dc20c 100644 --- a/docs/pages/devsecops/capability-based-isolation.mdx +++ b/docs/pages/devsecops/capability-based-isolation.mdx @@ -1,108 +1,10 @@ --- title: "Capability-Based Isolation | SEAL" -description: "Capability-scoped isolation patterns that replace broad runtime privileges with explicit, auditable permissions." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/capability-based-isolation." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Capability-Based Isolation - - - - -Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. - -In practice: do not give a job “admin” rights when it only needs “read dependency metadata” or “upload artifact to one path”. - -## Why this matters in DevSecOps - -Many incidents are privilege-shape failures, not code execution failures: compromised workflows succeed because credentials are too broad. - -Capability scoping reduces blast radius by ensuring that even successful compromise has constrained impact. - -## Capability model template - -Define capabilities as structured policy units: - -| Field | Example | -| --- | --- | -| Subject | `ci/workflow/build` | -| Action | `artifact.upload` | -| Resource | `registry.example.com/team/app/*` | -| Conditions | branch is protected, artifact has provenance, session < 15 min | -| Effect | allow / deny | - -## CI/CD capability tiers - -### Tier 1: Validate - -- read repository -- execute tests -- no deploy/publish -- no production secrets - -### Tier 2: Build - -- pull dependencies from approved registries -- upload intermediate artifacts -- no release signing keys - -### Tier 3: Release - -- publish signed artifact -- write release metadata -- deploy only to approved environment targets - -Map these tiers to separate identities/roles rather than toggling permissions in a single long-lived token. - -## Implementation patterns - -- Use workload identity federation (OIDC) for short-lived credentials. -- Create role-per-purpose identities (validate/build/release/deploy). -- Bind capabilities to both identity and runtime context (repo, branch, environment, workflow name). -- Deny by default; add narrow allow rules. - -## Audit and revocation requirements - -For each capability grant, log: - -- who/what requested it -- when it was issued and expired -- what resource/action it enabled -- whether execution succeeded or was denied - -Capability revocation should be immediate and automated for suspicious activity. - -## Common anti-patterns - -- “One token to rule them all” for all pipeline stages. -- Reusing static cloud credentials across repositories. -- Capability definitions without contextual conditions. -- Missing visibility into denied actions (blind spots hide attacks). - -## References - -- NIST SP 800-53 Rev. 5 (least privilege and access control): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final -- NIST glossary, *Least Privilege*: https://csrc.nist.gov/glossary/term/least_privilege -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- Kubernetes, *Role Based Access Control*: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview - ---- - - - +- New location: [/devsecops/isolation/capability-based-isolation](/devsecops/isolation/capability-based-isolation) diff --git a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx index bf050143..5f800117 100644 --- a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx @@ -1,235 +1,10 @@ --- title: "Execution Sandboxing: A Practical Guide | SEAL" -description: "Implementation-focused sandboxing guide for CI/CD, runners, untrusted PR workflows, secrets handling, and network egress control." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/execution-sandboxing-practical-guide." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Execution Sandboxing: A Practical Guide - - - - -This guide translates sandboxing principles into concrete controls for real CI/CD environments. - -Use it when you need to answer: **“What should we deploy this quarter to materially reduce risk from untrusted execution?”** - -## Scope and assumptions - -This playbook focuses on execution risks from: - -- untrusted pull requests and dependencies -- shared/self-hosted runners -- build and release tooling with write privileges -- secret exposure and token misuse -- unrestricted network egress - -It is applicable regardless of whether automation is triggered by scripts, bots, or AI-enabled systems. - -## 0) Define trust zones first - -Before implementing controls, classify workflows into trust zones: - -| Zone | Typical sources | Allowed outcomes | -| --- | --- | --- | -| Untrusted validation | fork PRs, external contributions, unknown dependencies | lint/test/build checks only | -| Internal trusted CI | protected branches, approved maintainers | artifact build + internal publish | -| Release/deploy | signed tags, release managers, protected environments | production deploy and signing | - -**Rule:** never run untrusted-zone jobs on release/deploy infrastructure. - -## 1) Runner isolation baseline - -### Required baseline - -- Ephemeral runner per job (destroy after completion). -- No privileged containers unless explicitly justified and isolated. -- No host docker socket mount for untrusted jobs. -- Read-only root filesystem where possible. -- Separate runner pools per trust zone. - -### Good defaults for containerized runners - -- Drop Linux capabilities by default (`cap-drop=ALL`). -- Use seccomp profile and AppArmor/SELinux policy. -- Set CPU/memory/pids limits. -- Set job timeout and process count limits. - -## 2) Safe handling for untrusted PRs - -Untrusted PR execution is the most common CI breach path. - -### Controls - -1. Trigger untrusted jobs with minimal token permissions. -2. Do not expose deployment credentials, signing keys, or production secrets. -3. Prevent write operations to protected branches/tags. -4. Restrict artifact publication from untrusted workflows. -5. Apply strict outbound network allowlist. - -### GitHub Actions example (least privilege token) - -```yaml -permissions: - contents: read - pull-requests: read -``` - -Only grant elevated scopes per job when required. - -### Important workflow safety note - -Avoid using `pull_request_target` to run untrusted code with privileged context unless you fully understand and constrain checkout, permissions, and secret access behavior. - -## 3) Secrets and identity controls - -### Prefer short-lived credentials - -- Use OIDC federation to cloud providers instead of static cloud keys in CI secrets. -- Scope roles per workflow purpose (build-only, publish-only, deploy-only). -- Apply time-bound sessions and audience restrictions. - -### Secret exposure minimization - -- Inject secrets only into jobs that require them. -- Mask and redact logs. -- Mount secrets read-only and avoid writing them to workspace. -- Rotate credentials and invalidate on suspected leakage. - -### Segregate high-impact secrets - -Signing keys, registry publish credentials, and production deploy tokens should be available only in protected environments with approval gates. - -## 4) Network egress control - -Start from **deny all egress**, then open only required destinations. - -### Minimum egress policy structure - -- allow source control host (fetch) -- allow package mirrors/registries needed for build -- allow artifact store -- deny direct access to internal admin/control planes -- deny metadata endpoints unless explicitly required - -### Kubernetes example pattern - -- namespace-per-trust-zone -- default deny egress NetworkPolicy -- explicit allowlist policies per pipeline stage - -## 5) Resource and abuse controls - -Prevent runaway or abusive workloads: - -- CPU/memory/pids quotas per job -- max execution time per stage -- bounded log size and artifact size -- concurrency controls for expensive workflows -- filesystem quota for temporary storage - -These controls reduce denial-of-service risk and limit cost impact from malicious or broken tasks. - -## 6) Build integrity and provenance - -Sandboxing reduces runtime blast radius; integrity controls reduce supply-chain risk. - -Recommended: - -- Generate provenance attestations for build artifacts. -- Sign release artifacts. -- Enforce verification before deployment. -- Use reproducible/deterministic build settings where feasible. - -Use SLSA-aligned controls to define maturity targets over time. - -## 7) Policy gates (before and after execution) - -Implement policy-as-code checks at multiple points: - -- **Pre-execution:** validate workflow configuration (forbidden privileged flags, forbidden secret contexts). -- **Runtime:** enforce admission and sandbox policy (seccomp, allowed images, namespace constraints). -- **Post-execution:** verify provenance/signatures and deployment policy. - -## 8) Logging and incident readiness - -At minimum capture: - -- workflow identity (repo, ref, actor, workflow, runner) -- command/process telemetry (high-risk operations) -- network destinations contacted -- secret access events -- artifact hashes and provenance metadata - -Have a playbook for: - -1. revoke active tokens -2. quarantine runner pool -3. rotate secrets -4. invalidate suspicious artifacts -5. re-run trusted build from clean source - -## 30/60/90 day implementation plan - -### First 30 days - -- Split trusted vs untrusted runner pools. -- Enforce least-privilege CI token defaults. -- Disable secrets in untrusted PR workflows. -- Add job timeouts and resource limits. - -### By day 60 - -- Introduce default-deny egress with allowlists. -- Deploy seccomp/AppArmor (or equivalent) profiles. -- Migrate static cloud credentials to OIDC short-lived roles. - -### By day 90 - -- Add artifact signing and provenance checks. -- Enforce policy-as-code gates for workflow and runtime configuration. -- Run a tabletop exercise for CI compromise response. - -## Operational checklist - -- [ ] Untrusted PRs isolated from privileged runners -- [ ] Ephemeral runners enabled -- [ ] CI token defaults set to read-only -- [ ] No long-lived cloud keys in CI -- [ ] Egress deny-by-default + destination allowlists -- [ ] Seccomp/profile enforcement active -- [ ] Resource quotas and timeouts configured -- [ ] Artifact signing/provenance verified at release -- [ ] Incident response runbook tested - -## References - -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- NIST SP 800-204A, *Building Secure Microservices-based Applications Using Service-Mesh Architecture*: https://csrc.nist.gov/pubs/sp/800/204/a/final -- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- GitHub Actions security hardening: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions -- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ -- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html -- SLSA specification: https://slsa.dev/spec/v1.0/overview - ---- - - - +- New location: [/devsecops/isolation/execution-sandboxing-practical-guide](/devsecops/isolation/execution-sandboxing-practical-guide) diff --git a/docs/pages/devsecops/execution-sandboxing.mdx b/docs/pages/devsecops/execution-sandboxing.mdx index 7f4b934f..bcf0c07d 100644 --- a/docs/pages/devsecops/execution-sandboxing.mdx +++ b/docs/pages/devsecops/execution-sandboxing.mdx @@ -1,112 +1,10 @@ --- title: "Execution Sandboxing | SEAL" -description: "How to sandbox execution across CI/CD, build tooling, and automation to reduce blast radius and prevent privilege abuse." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/execution-sandboxing." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Execution Sandboxing - - - - -Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. - -In DevSecOps, this applies to: - -- CI jobs and build/test pipelines -- package manager hooks and third-party actions -- deployment automation and release tooling -- developer scripts and internal bots -- AI-enabled automation (one category of tool execution) - -## Core security properties - -A production-grade sandbox should provide: - -1. **Isolation**: workload cannot freely access host resources or adjacent tenants. -2. **Least privilege**: runtime identity and tokens are scoped to minimum required actions. -3. **Constrained side effects**: filesystem, network, and API access are explicitly bounded. -4. **Ephemerality**: runtime is short-lived and reset between jobs. -5. **Auditability**: execution is logged with enough detail for incident response. - -## Boundary design: what to isolate - -Treat these as separate enforcement planes: - -| Plane | Typical risks | Required controls | -| --- | --- | --- | -| Process/syscall | container escape, host tampering | seccomp, no `--privileged`, capability drops, AppArmor/SELinux | -| Filesystem | credential theft, workspace poisoning | read-only rootfs, isolated workspace, explicit writable mounts | -| Identity | token abuse, cloud account takeover | short-lived credentials, OIDC federation, scoped IAM | -| Network | data exfiltration, lateral movement | default-deny egress, destination allowlist, proxy/inspection | -| Resources | denial of service, budget burn | CPU/memory/pids/time limits, quotas, max concurrency | - -## Choosing the runtime isolation level - -| Runtime option | Isolation strength | Operational overhead | Typical fit | -| --- | --- | --- | --- | -| Standard containers | Moderate | Low | Low-risk build/test steps with strict hardening | -| Hardened containers (rootless + seccomp/AppArmor) | Moderate-strong | Medium | Most CI validation workflows | -| Sandboxed containers (gVisor/Kata) | Strong | Medium-high | Untrusted code in shared infrastructure | -| MicroVMs (Firecracker) | Strong | High | High-risk multi-tenant runners and privileged pipelines | -| Full VMs | Strongest boundary | High | Regulated workloads or high-impact deployment/signing paths | - -## CI/CD-specific patterns - -### 1) Split trust zones - -- **Zone A: Untrusted PR validation** (forks, external code) - - no long-lived secrets - - restricted CI token permissions - - no deploy/publish capability -- **Zone B: Trusted branch/release** - - controlled secret access - - protected environments and approvals - - provenance + signing requirements - -### 2) Use ephemeral runners - -Each job should run on fresh infrastructure and be destroyed after completion. Avoid shared mutable state and persistent credentials between jobs. - -### 3) Restrict privileged paths - -Build, sign, publish, and deploy should be distinct stages with explicit policy gates and auditable approvals. - -## Common failure modes - -- Treating “containerized” as automatically secure. -- Running untrusted PR code on persistent or privileged runners. -- Reusing static secrets in CI variables. -- Allowing unrestricted egress from build jobs. -- Granting broad default CI token permissions. - -## References - -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html -- gVisor documentation: https://gvisor.dev/docs/ -- Kata Containers documentation: https://github.com/kata-containers/documentation -- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs - ---- - - - +- New location: [/devsecops/isolation/execution-sandboxing](/devsecops/isolation/execution-sandboxing) diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx index 3d318a96..8e6d9ce4 100644 --- a/docs/pages/devsecops/index.mdx +++ b/docs/pages/devsecops/index.mdx @@ -12,15 +12,16 @@ title: "Devsecops" ## Pages - [DevSecOps](/devsecops/overview) -- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) -- [Execution Sandboxing](/devsecops/execution-sandboxing) -- [Capability-Based Isolation](/devsecops/capability-based-isolation) -- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) -- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) -- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) -- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) - [Implementing Code Signing](/devsecops/code-signing) - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment) - [Securing Development Environments](/devsecops/integrated-development-environments) - [Repository Hardening](/devsecops/repository-hardening) - [Security Testing](/devsecops/security-testing) +- [Capability-Based Isolation](/devsecops/capability-based-isolation) +- [Execution Sandboxing](/devsecops/execution-sandboxing) +- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) +- [Isolation](/devsecops/isolation) +- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) +- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) +- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) +- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) diff --git a/docs/pages/devsecops/isolation/capability-based-isolation.mdx b/docs/pages/devsecops/isolation/capability-based-isolation.mdx new file mode 100644 index 00000000..04c35352 --- /dev/null +++ b/docs/pages/devsecops/isolation/capability-based-isolation.mdx @@ -0,0 +1,108 @@ +--- +title: "Capability-Based Isolation | SEAL" +description: "Capability-scoped isolation patterns that replace broad runtime privileges with explicit, auditable permissions." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Capability-Based Isolation + + + + +Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. + +In practice: do not give a job “admin” rights when it only needs “read dependency metadata” or “upload artifact to one path”. + +## Why this matters in DevSecOps + +Many incidents are privilege-shape failures, not code execution failures: compromised workflows succeed because credentials are too broad. + +Capability scoping reduces blast radius by ensuring that even successful compromise has constrained impact. + +## Capability model template + +Define capabilities as structured policy units: + +| Field | Example | +| --- | --- | +| Subject | `ci/workflow/build` | +| Action | `artifact.upload` | +| Resource | `registry.example.com/team/app/*` | +| Conditions | branch is protected, artifact has provenance, session < 15 min | +| Effect | allow / deny | + +## CI/CD capability tiers + +### Tier 1: Validate + +- read repository +- execute tests +- no deploy/publish +- no production secrets + +### Tier 2: Build + +- pull dependencies from approved registries +- upload intermediate artifacts +- no release signing keys + +### Tier 3: Release + +- publish signed artifact +- write release metadata +- deploy only to approved environment targets + +Map these tiers to separate identities/roles rather than toggling permissions in a single long-lived token. + +## Implementation patterns + +- Use workload identity federation (OIDC) for short-lived credentials. +- Create role-per-purpose identities (validate/build/release/deploy). +- Bind capabilities to both identity and runtime context (repo, branch, environment, workflow name). +- Deny by default; add narrow allow rules. + +## Audit and revocation requirements + +For each capability grant, log: + +- who/what requested it +- when it was issued and expired +- what resource/action it enabled +- whether execution succeeded or was denied + +Capability revocation should be immediate and automated for suspicious activity. + +## Common anti-patterns + +- “One token to rule them all” for all pipeline stages. +- Reusing static cloud credentials across repositories. +- Capability definitions without contextual conditions. +- Missing visibility into denied actions (blind spots hide attacks). + +## References + +- NIST SP 800-53 Rev. 5 (least privilege and access control): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- NIST glossary, *Least Privilege*: https://csrc.nist.gov/glossary/term/least_privilege +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Kubernetes, *Role Based Access Control*: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview + +--- + + + diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx new file mode 100644 index 00000000..f4a99535 --- /dev/null +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -0,0 +1,235 @@ +--- +title: "Execution Sandboxing: A Practical Guide | SEAL" +description: "Implementation-focused sandboxing guide for CI/CD, runners, untrusted PR workflows, secrets handling, and network egress control." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Execution Sandboxing: A Practical Guide + + + + +This guide translates sandboxing principles into concrete controls for real CI/CD environments. + +Use it when you need to answer: **“What should we deploy this quarter to materially reduce risk from untrusted execution?”** + +## Scope and assumptions + +This playbook focuses on execution risks from: + +- untrusted pull requests and dependencies +- shared/self-hosted runners +- build and release tooling with write privileges +- secret exposure and token misuse +- unrestricted network egress + +It is applicable regardless of whether automation is triggered by scripts, bots, or AI-enabled systems. + +## 0) Define trust zones first + +Before implementing controls, classify workflows into trust zones: + +| Zone | Typical sources | Allowed outcomes | +| --- | --- | --- | +| Untrusted validation | fork PRs, external contributions, unknown dependencies | lint/test/build checks only | +| Internal trusted CI | protected branches, approved maintainers | artifact build + internal publish | +| Release/deploy | signed tags, release managers, protected environments | production deploy and signing | + +**Rule:** never run untrusted-zone jobs on release/deploy infrastructure. + +## 1) Runner isolation baseline + +### Required baseline + +- Ephemeral runner per job (destroy after completion). +- No privileged containers unless explicitly justified and isolated. +- No host docker socket mount for untrusted jobs. +- Read-only root filesystem where possible. +- Separate runner pools per trust zone. + +### Good defaults for containerized runners + +- Drop Linux capabilities by default (`cap-drop=ALL`). +- Use seccomp profile and AppArmor/SELinux policy. +- Set CPU/memory/pids limits. +- Set job timeout and process count limits. + +## 2) Safe handling for untrusted PRs + +Untrusted PR execution is the most common CI breach path. + +### Controls + +1. Trigger untrusted jobs with minimal token permissions. +2. Do not expose deployment credentials, signing keys, or production secrets. +3. Prevent write operations to protected branches/tags. +4. Restrict artifact publication from untrusted workflows. +5. Apply strict outbound network allowlist. + +### GitHub Actions example (least privilege token) + +```yaml +permissions: + contents: read + pull-requests: read +``` + +Only grant elevated scopes per job when required. + +### Important workflow safety note + +Avoid using `pull_request_target` to run untrusted code with privileged context unless you fully understand and constrain checkout, permissions, and secret access behavior. + +## 3) Secrets and identity controls + +### Prefer short-lived credentials + +- Use OIDC federation to cloud providers instead of static cloud keys in CI secrets. +- Scope roles per workflow purpose (build-only, publish-only, deploy-only). +- Apply time-bound sessions and audience restrictions. + +### Secret exposure minimization + +- Inject secrets only into jobs that require them. +- Mask and redact logs. +- Mount secrets read-only and avoid writing them to workspace. +- Rotate credentials and invalidate on suspected leakage. + +### Segregate high-impact secrets + +Signing keys, registry publish credentials, and production deploy tokens should be available only in protected environments with approval gates. + +## 4) Network egress control + +Start from **deny all egress**, then open only required destinations. + +### Minimum egress policy structure + +- allow source control host (fetch) +- allow package mirrors/registries needed for build +- allow artifact store +- deny direct access to internal admin/control planes +- deny metadata endpoints unless explicitly required + +### Kubernetes example pattern + +- namespace-per-trust-zone +- default deny egress NetworkPolicy +- explicit allowlist policies per pipeline stage + +## 5) Resource and abuse controls + +Prevent runaway or abusive workloads: + +- CPU/memory/pids quotas per job +- max execution time per stage +- bounded log size and artifact size +- concurrency controls for expensive workflows +- filesystem quota for temporary storage + +These controls reduce denial-of-service risk and limit cost impact from malicious or broken tasks. + +## 6) Build integrity and provenance + +Sandboxing reduces runtime blast radius; integrity controls reduce supply-chain risk. + +Recommended: + +- Generate provenance attestations for build artifacts. +- Sign release artifacts. +- Enforce verification before deployment. +- Use reproducible/deterministic build settings where feasible. + +Use SLSA-aligned controls to define maturity targets over time. + +## 7) Policy gates (before and after execution) + +Implement policy-as-code checks at multiple points: + +- **Pre-execution:** validate workflow configuration (forbidden privileged flags, forbidden secret contexts). +- **Runtime:** enforce admission and sandbox policy (seccomp, allowed images, namespace constraints). +- **Post-execution:** verify provenance/signatures and deployment policy. + +## 8) Logging and incident readiness + +At minimum capture: + +- workflow identity (repo, ref, actor, workflow, runner) +- command/process telemetry (high-risk operations) +- network destinations contacted +- secret access events +- artifact hashes and provenance metadata + +Have a playbook for: + +1. revoke active tokens +2. quarantine runner pool +3. rotate secrets +4. invalidate suspicious artifacts +5. re-run trusted build from clean source + +## 30/60/90 day implementation plan + +### First 30 days + +- Split trusted vs untrusted runner pools. +- Enforce least-privilege CI token defaults. +- Disable secrets in untrusted PR workflows. +- Add job timeouts and resource limits. + +### By day 60 + +- Introduce default-deny egress with allowlists. +- Deploy seccomp/AppArmor (or equivalent) profiles. +- Migrate static cloud credentials to OIDC short-lived roles. + +### By day 90 + +- Add artifact signing and provenance checks. +- Enforce policy-as-code gates for workflow and runtime configuration. +- Run a tabletop exercise for CI compromise response. + +## Operational checklist + +- [ ] Untrusted PRs isolated from privileged runners +- [ ] Ephemeral runners enabled +- [ ] CI token defaults set to read-only +- [ ] No long-lived cloud keys in CI +- [ ] Egress deny-by-default + destination allowlists +- [ ] Seccomp/profile enforcement active +- [ ] Resource quotas and timeouts configured +- [ ] Artifact signing/provenance verified at release +- [ ] Incident response runbook tested + +## References + +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-204A, *Building Secure Microservices-based Applications Using Service-Mesh Architecture*: https://csrc.nist.gov/pubs/sp/800/204/a/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- GitHub Actions security hardening: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- SLSA specification: https://slsa.dev/spec/v1.0/overview + +--- + + + diff --git a/docs/pages/devsecops/isolation/execution-sandboxing.mdx b/docs/pages/devsecops/isolation/execution-sandboxing.mdx new file mode 100644 index 00000000..aca44036 --- /dev/null +++ b/docs/pages/devsecops/isolation/execution-sandboxing.mdx @@ -0,0 +1,112 @@ +--- +title: "Execution Sandboxing | SEAL" +description: "How to sandbox execution across CI/CD, build tooling, and automation to reduce blast radius and prevent privilege abuse." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Execution Sandboxing + + + + +Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. + +In DevSecOps, this applies to: + +- CI jobs and build/test pipelines +- package manager hooks and third-party actions +- deployment automation and release tooling +- developer scripts and internal bots +- AI-enabled automation (one category of tool execution) + +## Core security properties + +A production-grade sandbox should provide: + +1. **Isolation**: workload cannot freely access host resources or adjacent tenants. +2. **Least privilege**: runtime identity and tokens are scoped to minimum required actions. +3. **Constrained side effects**: filesystem, network, and API access are explicitly bounded. +4. **Ephemerality**: runtime is short-lived and reset between jobs. +5. **Auditability**: execution is logged with enough detail for incident response. + +## Boundary design: what to isolate + +Treat these as separate enforcement planes: + +| Plane | Typical risks | Required controls | +| --- | --- | --- | +| Process/syscall | container escape, host tampering | seccomp, no `--privileged`, capability drops, AppArmor/SELinux | +| Filesystem | credential theft, workspace poisoning | read-only rootfs, isolated workspace, explicit writable mounts | +| Identity | token abuse, cloud account takeover | short-lived credentials, OIDC federation, scoped IAM | +| Network | data exfiltration, lateral movement | default-deny egress, destination allowlist, proxy/inspection | +| Resources | denial of service, budget burn | CPU/memory/pids/time limits, quotas, max concurrency | + +## Choosing the runtime isolation level + +| Runtime option | Isolation strength | Operational overhead | Typical fit | +| --- | --- | --- | --- | +| Standard containers | Moderate | Low | Low-risk build/test steps with strict hardening | +| Hardened containers (rootless + seccomp/AppArmor) | Moderate-strong | Medium | Most CI validation workflows | +| Sandboxed containers (gVisor/Kata) | Strong | Medium-high | Untrusted code in shared infrastructure | +| MicroVMs (Firecracker) | Strong | High | High-risk multi-tenant runners and privileged pipelines | +| Full VMs | Strongest boundary | High | Regulated workloads or high-impact deployment/signing paths | + +## CI/CD-specific patterns + +### 1) Split trust zones + +- **Zone A: Untrusted PR validation** (forks, external code) + - no long-lived secrets + - restricted CI token permissions + - no deploy/publish capability +- **Zone B: Trusted branch/release** + - controlled secret access + - protected environments and approvals + - provenance + signing requirements + +### 2) Use ephemeral runners + +Each job should run on fresh infrastructure and be destroyed after completion. Avoid shared mutable state and persistent credentials between jobs. + +### 3) Restrict privileged paths + +Build, sign, publish, and deploy should be distinct stages with explicit policy gates and auditable approvals. + +## Common failure modes + +- Treating “containerized” as automatically secure. +- Running untrusted PR code on persistent or privileged runners. +- Reusing static secrets in CI variables. +- Allowing unrestricted egress from build jobs. +- Granting broad default CI token permissions. + +## References + +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- gVisor documentation: https://gvisor.dev/docs/ +- Kata Containers documentation: https://github.com/kata-containers/documentation +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs + +--- + + + diff --git a/docs/pages/devsecops/isolation/index.mdx b/docs/pages/devsecops/isolation/index.mdx new file mode 100644 index 00000000..1cf788de --- /dev/null +++ b/docs/pages/devsecops/isolation/index.mdx @@ -0,0 +1,20 @@ +--- +title: "Isolation" +--- + +{/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} + +# Isolation + +> _Note:_ This page is auto-generated. Please use the sidebar to explore the docs instead of +> navigating directory paths directly. + +## Pages + +- [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) +- [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) +- [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) +- [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) +- [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) +- [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) +- [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx new file mode 100644 index 00000000..0ea8be7a --- /dev/null +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -0,0 +1,112 @@ +--- +title: "Network & Resource Isolation | SEAL" +description: "Deny-by-default network and strict resource governance for CI/CD jobs, runners, and sandboxed automation workloads." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops + - SRE +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Network & Resource Isolation + + + + +Network and compute controls are critical containment layers for sandboxed execution. + +Without them, a compromised build or tool can: + +- exfiltrate source code and secrets +- scan internal services and pivot laterally +- abuse infrastructure through runaway jobs +- create cost spikes via unbounded resource usage + +## Network isolation model + +### 1) Default deny egress + +Start with no outbound access. Add explicit allow rules only for required destinations (SCM host, package registries, artifact storage, approved APIs). + +### 2) Separate trust zones + +Use distinct network boundaries for: + +- untrusted PR validation +- internal trusted builds +- release/deploy pipelines + +Do not allow direct network paths from untrusted workloads to sensitive control planes. + +### 3) Constrain DNS and metadata access + +- Restrict DNS resolvers and block arbitrary external name resolution where feasible. +- Deny access to cloud metadata endpoints from untrusted jobs unless explicitly required. + +### 4) Centralize outbound controls + +For mature environments, route egress through policy-enforcing gateways/proxies to monitor and block prohibited destinations. + +## Resource isolation model + +Enforce limits at runner and workload level: + +- CPU and memory limits per job/container +- process count (`pids`) limits +- filesystem and artifact size limits +- execution timeout limits +- concurrency limits per workflow/repository + +These controls are both security and reliability controls. + +## CI/CD implementation checklist + +- [ ] Untrusted jobs run in isolated runner pool +- [ ] Default-deny egress applied to untrusted zone +- [ ] Destination allowlists documented per pipeline stage +- [ ] Metadata service access restricted +- [ ] CPU/memory/pids limits configured +- [ ] Job and step timeouts enforced +- [ ] Max artifact/log size capped + +## Example control matrix + +| Workload type | Egress policy | Resource policy | +| --- | --- | --- | +| Fork PR validation | deny-by-default, minimal allowlist | strict CPU/memory/time limits | +| Internal CI build | allow required registries/APIs only | moderate limits, queue controls | +| Release/deploy | highly specific allowlist to deployment targets | conservative limits + approval gates | + +## Common anti-patterns + +- “Allow all egress” for convenience in CI. +- Reusing a single runner network profile for all trust levels. +- Missing job timeouts (infinite loops become outages). +- Unlimited artifact uploads from untrusted workflows. + +## References + +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5 (network and resource control families): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ +- Kubernetes, *Resource Management for Pods and Containers*: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- gVisor documentation: https://gvisor.dev/docs/ +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs + +--- + + + diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx new file mode 100644 index 00000000..10c64ef9 --- /dev/null +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -0,0 +1,108 @@ +--- +title: "Sandboxing & Isolation | SEAL" +description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across CI/CD, runners, tooling, and execution environments." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Sandboxing & Isolation + + + + +This section is the canonical DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). + +The core objective is simple: **assume compromise can happen, then contain blast radius by design**. + +## What to protect (threat model quickstart) + +Treat sandboxing decisions as a threat-modeling exercise across four dimensions: + +| Dimension | Questions to answer | +| --- | --- | +| Assets | What can be stolen or modified? (source code, signing keys, CI secrets, deployment credentials, artifacts, production APIs) | +| Entry points | What can trigger execution? (fork PRs, dependencies, build scripts, test fixtures, webhooks, external APIs) | +| Privileges | What authority does runtime hold? (filesystem write, network egress, cloud IAM, package publish, deployment rights) | +| Impact | What is worst-case outcome? (secret exfiltration, artifact tampering, lateral movement, production change, financial loss) | + +**Default assumption:** code from external contributors, third-party actions, and newly introduced dependencies are untrusted until verified. + +## Decision tree: choose isolation depth + +Use this practical decision flow before assigning a runtime: + +1. **Does the workload process untrusted input or untrusted code?** + - If yes, run in an ephemeral sandbox (container with hardened profile at minimum; microVM/VM for higher assurance). +2. **Can the workload access secrets, signing keys, cloud credentials, or production systems?** + - If yes, enforce stronger isolation boundary, short-lived credentials, and explicit approval gates. +3. **Is outbound network required?** + - If no, deny all egress. + - If yes, allowlist destinations and force traffic through inspection/proxy controls. +4. **Can it modify persistent state (artifact repo, registry, infra, chain, database)?** + - If yes, require policy checks + attestation + auditable identity before execution. +5. **Is this multi-tenant shared runner infrastructure?** + - If yes, isolate per job with ephemeral workers and avoid secret reuse across jobs. + +If you answer “yes” to multiple high-risk questions, prefer **microVM/VM isolation plus strict policy enforcement**. + +## Layered control map (defense in depth) + +No single mechanism is sufficient. Apply multiple layers together: + +| Layer | Control objective | Typical controls | +| --- | --- | --- | +| Identity | Bind execution to least privilege identity | OIDC federation, short-lived tokens, scoped IAM roles | +| Execution boundary | Prevent host escape / cross-tenant impact | seccomp, AppArmor/SELinux, rootless containers, gVisor/Kata/Firecracker | +| Filesystem & secrets | Prevent sensitive data exposure | read-only rootfs, isolated workdir, mounted secret scopes, no long-lived credentials | +| Network | Prevent exfiltration and lateral movement | default-deny egress, DNS restrictions, NetworkPolicy, egress proxy | +| Resource governance | Prevent abuse and runaway cost | CPU/memory/pids/time limits, quotas, job timeout, concurrency caps | +| Integrity & provenance | Detect tampering and unauthorized changes | signed artifacts, provenance attestations, immutable logs, SLSA controls | +| Policy & response | Enforce and verify continuously | policy-as-code gates, runtime audit logs, alerting, incident playbooks | + +## Baseline controls for CI/CD and runners + +At minimum, enforce the following: + +- Separate **untrusted PR runners** from trusted build/deploy runners. +- Use **ephemeral runners** (fresh environment per job, no state reuse). +- Disable or heavily constrain secrets for forked PR jobs. +- Restrict CI token scopes to least privilege (`read` by default). +- Deny outbound network by default; allow only required hosts. +- Run with syscall and privilege restrictions (`seccomp`, no privileged mode, no host mounts unless strictly required). +- Sign and attest release artifacts before publish/deploy. + +## Start here (section map) + +- [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) — principles and runtime design choices. +- [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) — implementation blueprint for teams and platforms. +- [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) — egress controls, quotas, and anti-exfiltration patterns. +- [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) — controlling high-risk tool calls and side effects. +- [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) — breaking broad permissions into constrained capabilities. +- [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) — integrating policy-as-code with runtime isolation. + +## References + +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview + +--- + + + diff --git a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx new file mode 100644 index 00000000..cc337090 --- /dev/null +++ b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx @@ -0,0 +1,106 @@ +--- +title: "Sandboxing & Policy Enforcement | SEAL" +description: "Defense-in-depth model that combines runtime isolation with policy-as-code across CI/CD and automation workflows." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Sandboxing & Policy Enforcement + + + + +Sandboxing and policy enforcement solve different problems and must be used together: + +- **Policy** decides what should be allowed. +- **Sandboxing** limits damage when allowed actions fail, are abused, or are bypassed. + +Using only one layer leaves material gaps. + +## Three policy checkpoints + +| Checkpoint | Purpose | Typical examples | +| --- | --- | --- | +| Pre-execution | block unsafe configuration before run starts | deny privileged runner flags, deny forbidden workflow triggers | +| Runtime | enforce constraints during execution | seccomp/AppArmor, pod security admission, network policy | +| Post-execution | verify integrity before promotion/deploy | signature verification, provenance checks, policy attestations | + +## CI/CD control stack + +A practical stack for pipelines: + +1. **Workflow policy** + - lint and validate pipeline definitions + - require least-privilege token settings +2. **Runner/runtime policy** + - enforce non-privileged execution + - require sandbox profile and resource limits +3. **Artifact/release policy** + - enforce signed artifacts and provenance before publish/deploy +4. **Environment policy** + - require approvals for production mutation paths + +## Threat-to-control mapping + +| Threat | Policy control | Sandbox control | +| --- | --- | --- | +| Secret exfiltration | deny secret injection into untrusted workflows | filesystem isolation + egress allowlist | +| Runner compromise | deny privileged execution configs | syscall filtering + ephemeral runner | +| Supply-chain tampering | require trusted source and attestation | isolated build runtime + immutable logs | +| Unauthorized deploy | branch/environment approvals | isolated deploy runner with scoped identity | + +## Maturity model + +### Level 1 (baseline) + +- static policy checks for CI configuration +- isolated runners for untrusted PRs +- least-privilege CI tokens + +### Level 2 (intermediate) + +- runtime admission/enforcement policies +- default-deny network egress +- short-lived credentials via federation + +### Level 3 (advanced) + +- signed provenance verification on promotion +- policy decision logging with centralized audit +- periodic control validation exercises (breakout tests/tabletops) + +## Common anti-patterns + +- Writing policy that is never enforced at runtime. +- Treating sandbox exceptions as permanent defaults. +- Failing open when policy engine is unavailable. +- Skipping auditability for policy decisions. + +## References + +- NIST SP 800-53 Rev. 5 (policy, audit, and access controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Kubernetes, *Admission Controllers*: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ +- SLSA specification: https://slsa.dev/spec/v1.0/overview + +--- + + + diff --git a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx new file mode 100644 index 00000000..f84d2871 --- /dev/null +++ b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx @@ -0,0 +1,105 @@ +--- +title: "Sandboxing for Tool Execution | SEAL" +description: "Controls for high-risk tool invocation in automation workflows: policy checks, constrained runtime, and auditable side effects." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [munamwasi, jubos, masterfung] + - role: reviewed + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Sandboxing for Tool Execution + + + + +Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. + +This is often the highest-risk path in DevSecOps workflows. + +## Design principle + +Treat every tool call as an untrusted request until it passes policy checks. + +A secure flow is: + +1. **Intent validation** (is this action allowed?) +2. **Capability check** (does this runtime identity hold required permission?) +3. **Sandboxed execution** (bounded filesystem/network/resources) +4. **Audit and verification** (what happened, by whom, with what result?) + +## Tool risk tiers + +| Tier | Example actions | Minimum controls | +| --- | --- | --- | +| Low | read repo files, query status APIs | read-only tokens, no secret access | +| Medium | create PR comments, upload artifacts | scoped write perms, output size limits | +| High | merge, deploy, publish package, modify infra | approval gates, protected environment, strong sandbox | +| Critical | key usage, signing, production data mutation | dedicated isolated runtime, multi-party approval, full audit trail | + +## Practical controls + +### Restrict execution context + +- run tool calls in ephemeral runtime +- use read-only root filesystem where feasible +- block host mounts unless explicitly required +- apply seccomp/AppArmor/SELinux enforcement + +### Restrict identity and credentials + +- issue short-lived, scoped credentials +- bind tokens to specific tool purpose and environment +- disable ambient credentials in untrusted workflows + +### Restrict network side effects + +- deny-by-default egress +- allowlist specific endpoints per tool +- block direct access to internal admin APIs from low-trust jobs + +### Restrict invocation behavior + +- maximum execution time +- command/input/output size limits +- prevent recursive tool chaining unless explicitly allowed +- require explicit confirmation for high-risk operations + +## Policy examples for CI/CD tooling + +- “Untrusted PR jobs may run read-only analysis tools but cannot trigger deployment tools.” +- “Release tooling may publish only signed artifacts generated in the same pipeline.” +- “Infrastructure mutation tools require protected branch + approval + provenance verification.” + +## Common anti-patterns + +- Directly mapping user input to shell execution without policy mediation. +- Reusing broad admin credentials across multiple tools. +- Allowing tool calls to inherit unrestricted network access. +- Missing audit logs for high-impact tool operations. + +## References + +- NIST SP 800-53 Rev. 5 (least privilege, audit, execution controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final +- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final +- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments +- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html +- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ +- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ +- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs +- gVisor documentation: https://gvisor.dev/docs/ + +--- + + + diff --git a/docs/pages/devsecops/network-and-resource-isolation.mdx b/docs/pages/devsecops/network-and-resource-isolation.mdx index 828a2b3e..853f84f2 100644 --- a/docs/pages/devsecops/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/network-and-resource-isolation.mdx @@ -1,112 +1,10 @@ --- title: "Network & Resource Isolation | SEAL" -description: "Deny-by-default network and strict resource governance for CI/CD jobs, runners, and sandboxed automation workloads." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops - - SRE -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/network-and-resource-isolation." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Network & Resource Isolation - - - - -Network and compute controls are critical containment layers for sandboxed execution. - -Without them, a compromised build or tool can: - -- exfiltrate source code and secrets -- scan internal services and pivot laterally -- abuse infrastructure through runaway jobs -- create cost spikes via unbounded resource usage - -## Network isolation model - -### 1) Default deny egress - -Start with no outbound access. Add explicit allow rules only for required destinations (SCM host, package registries, artifact storage, approved APIs). - -### 2) Separate trust zones - -Use distinct network boundaries for: - -- untrusted PR validation -- internal trusted builds -- release/deploy pipelines - -Do not allow direct network paths from untrusted workloads to sensitive control planes. - -### 3) Constrain DNS and metadata access - -- Restrict DNS resolvers and block arbitrary external name resolution where feasible. -- Deny access to cloud metadata endpoints from untrusted jobs unless explicitly required. - -### 4) Centralize outbound controls - -For mature environments, route egress through policy-enforcing gateways/proxies to monitor and block prohibited destinations. - -## Resource isolation model - -Enforce limits at runner and workload level: - -- CPU and memory limits per job/container -- process count (`pids`) limits -- filesystem and artifact size limits -- execution timeout limits -- concurrency limits per workflow/repository - -These controls are both security and reliability controls. - -## CI/CD implementation checklist - -- [ ] Untrusted jobs run in isolated runner pool -- [ ] Default-deny egress applied to untrusted zone -- [ ] Destination allowlists documented per pipeline stage -- [ ] Metadata service access restricted -- [ ] CPU/memory/pids limits configured -- [ ] Job and step timeouts enforced -- [ ] Max artifact/log size capped - -## Example control matrix - -| Workload type | Egress policy | Resource policy | -| --- | --- | --- | -| Fork PR validation | deny-by-default, minimal allowlist | strict CPU/memory/time limits | -| Internal CI build | allow required registries/APIs only | moderate limits, queue controls | -| Release/deploy | highly specific allowlist to deployment targets | conservative limits + approval gates | - -## Common anti-patterns - -- “Allow all egress” for convenience in CI. -- Reusing a single runner network profile for all trust levels. -- Missing job timeouts (infinite loops become outages). -- Unlimited artifact uploads from untrusted workflows. - -## References - -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- NIST SP 800-53 Rev. 5 (network and resource control families): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ -- Kubernetes, *Resource Management for Pods and Containers*: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ -- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ -- gVisor documentation: https://gvisor.dev/docs/ -- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs - ---- - - - +- New location: [/devsecops/isolation/network-and-resource-isolation](/devsecops/isolation/network-and-resource-isolation) diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 5d3cef8a..be083ef7 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -35,18 +35,18 @@ Some of the key areas to consider are: 2. Implement automated security testing and monitoring. 3. Development, Operations and Security teams should be aligned and work closely together. 4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. - - See: [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) (canonical section) + - See: [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) (canonical section) ## What’s inside DevSecOps - **Isolation & Sandboxing** - - [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. - - [Execution Sandboxing](/devsecops/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. - - [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. - - [Capability-Based Isolation](/devsecops/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. - - [Network & Resource Isolation](/devsecops/network-and-resource-isolation): Enforce deny-by-default networking and strict CPU/memory/resource boundaries. - - [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution): Secure high-risk tool invocation with constrained runtime and auditable effects. - - [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement): Combine sandbox boundaries with policy-as-code for defense in depth. + - [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. + - [Execution Sandboxing](/devsecops/isolation/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. + - [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. + - [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. + - [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation): Enforce deny-by-default networking and strict CPU/memory/resource boundaries. + - [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution): Secure high-risk tool invocation with constrained runtime and auditable effects. + - [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement): Combine sandbox boundaries with policy-as-code for defense in depth. - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment): Build safer pipelines with testing, scanning, deterministic builds, and access controls. - [Repository Hardening](/devsecops/repository-hardening): Protect repos with branch policies, signed commits, and hardened automation settings. - [Security Testing](/devsecops/security-testing): Shift-left with SAST, DAST, IAST, and fuzzing to catch issues early. diff --git a/docs/pages/devsecops/sandboxing-and-isolation.mdx b/docs/pages/devsecops/sandboxing-and-isolation.mdx index 1112eadb..e56dd0cb 100644 --- a/docs/pages/devsecops/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/sandboxing-and-isolation.mdx @@ -1,108 +1,10 @@ --- title: "Sandboxing & Isolation | SEAL" -description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across CI/CD, runners, tooling, and execution environments." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [mattaereal] +description: "This page moved to /devsecops/isolation/sandboxing-and-isolation." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Sandboxing & Isolation - - - - -This section is the canonical DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). - -The core objective is simple: **assume compromise can happen, then contain blast radius by design**. - -## What to protect (threat model quickstart) - -Treat sandboxing decisions as a threat-modeling exercise across four dimensions: - -| Dimension | Questions to answer | -| --- | --- | -| Assets | What can be stolen or modified? (source code, signing keys, CI secrets, deployment credentials, artifacts, production APIs) | -| Entry points | What can trigger execution? (fork PRs, dependencies, build scripts, test fixtures, webhooks, external APIs) | -| Privileges | What authority does runtime hold? (filesystem write, network egress, cloud IAM, package publish, deployment rights) | -| Impact | What is worst-case outcome? (secret exfiltration, artifact tampering, lateral movement, production change, financial loss) | - -**Default assumption:** code from external contributors, third-party actions, and newly introduced dependencies are untrusted until verified. - -## Decision tree: choose isolation depth - -Use this practical decision flow before assigning a runtime: - -1. **Does the workload process untrusted input or untrusted code?** - - If yes, run in an ephemeral sandbox (container with hardened profile at minimum; microVM/VM for higher assurance). -2. **Can the workload access secrets, signing keys, cloud credentials, or production systems?** - - If yes, enforce stronger isolation boundary, short-lived credentials, and explicit approval gates. -3. **Is outbound network required?** - - If no, deny all egress. - - If yes, allowlist destinations and force traffic through inspection/proxy controls. -4. **Can it modify persistent state (artifact repo, registry, infra, chain, database)?** - - If yes, require policy checks + attestation + auditable identity before execution. -5. **Is this multi-tenant shared runner infrastructure?** - - If yes, isolate per job with ephemeral workers and avoid secret reuse across jobs. - -If you answer “yes” to multiple high-risk questions, prefer **microVM/VM isolation plus strict policy enforcement**. - -## Layered control map (defense in depth) - -No single mechanism is sufficient. Apply multiple layers together: - -| Layer | Control objective | Typical controls | -| --- | --- | --- | -| Identity | Bind execution to least privilege identity | OIDC federation, short-lived tokens, scoped IAM roles | -| Execution boundary | Prevent host escape / cross-tenant impact | seccomp, AppArmor/SELinux, rootless containers, gVisor/Kata/Firecracker | -| Filesystem & secrets | Prevent sensitive data exposure | read-only rootfs, isolated workdir, mounted secret scopes, no long-lived credentials | -| Network | Prevent exfiltration and lateral movement | default-deny egress, DNS restrictions, NetworkPolicy, egress proxy | -| Resource governance | Prevent abuse and runaway cost | CPU/memory/pids/time limits, quotas, job timeout, concurrency caps | -| Integrity & provenance | Detect tampering and unauthorized changes | signed artifacts, provenance attestations, immutable logs, SLSA controls | -| Policy & response | Enforce and verify continuously | policy-as-code gates, runtime audit logs, alerting, incident playbooks | - -## Baseline controls for CI/CD and runners - -At minimum, enforce the following: - -- Separate **untrusted PR runners** from trusted build/deploy runners. -- Use **ephemeral runners** (fresh environment per job, no state reuse). -- Disable or heavily constrain secrets for forked PR jobs. -- Restrict CI token scopes to least privilege (`read` by default). -- Deny outbound network by default; allow only required hosts. -- Run with syscall and privilege restrictions (`seccomp`, no privileged mode, no host mounts unless strictly required). -- Sign and attest release artifacts before publish/deploy. - -## Start here (section map) - -- [Execution Sandboxing](/devsecops/execution-sandboxing) — principles and runtime design choices. -- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) — implementation blueprint for teams and platforms. -- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) — egress controls, quotas, and anti-exfiltration patterns. -- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) — controlling high-risk tool calls and side effects. -- [Capability-Based Isolation](/devsecops/capability-based-isolation) — breaking broad permissions into constrained capabilities. -- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) — integrating policy-as-code with runtime isolation. - -## References - -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth -- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html -- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview - ---- - - - +- New location: [/devsecops/isolation/sandboxing-and-isolation](/devsecops/isolation/sandboxing-and-isolation) diff --git a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx index 7c6f5ecc..5f869e39 100644 --- a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx @@ -1,106 +1,10 @@ --- title: "Sandboxing & Policy Enforcement | SEAL" -description: "Defense-in-depth model that combines runtime isolation with policy-as-code across CI/CD and automation workflows." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/sandboxing-and-policy-enforcement." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Sandboxing & Policy Enforcement - - - - -Sandboxing and policy enforcement solve different problems and must be used together: - -- **Policy** decides what should be allowed. -- **Sandboxing** limits damage when allowed actions fail, are abused, or are bypassed. - -Using only one layer leaves material gaps. - -## Three policy checkpoints - -| Checkpoint | Purpose | Typical examples | -| --- | --- | --- | -| Pre-execution | block unsafe configuration before run starts | deny privileged runner flags, deny forbidden workflow triggers | -| Runtime | enforce constraints during execution | seccomp/AppArmor, pod security admission, network policy | -| Post-execution | verify integrity before promotion/deploy | signature verification, provenance checks, policy attestations | - -## CI/CD control stack - -A practical stack for pipelines: - -1. **Workflow policy** - - lint and validate pipeline definitions - - require least-privilege token settings -2. **Runner/runtime policy** - - enforce non-privileged execution - - require sandbox profile and resource limits -3. **Artifact/release policy** - - enforce signed artifacts and provenance before publish/deploy -4. **Environment policy** - - require approvals for production mutation paths - -## Threat-to-control mapping - -| Threat | Policy control | Sandbox control | -| --- | --- | --- | -| Secret exfiltration | deny secret injection into untrusted workflows | filesystem isolation + egress allowlist | -| Runner compromise | deny privileged execution configs | syscall filtering + ephemeral runner | -| Supply-chain tampering | require trusted source and attestation | isolated build runtime + immutable logs | -| Unauthorized deploy | branch/environment approvals | isolated deploy runner with scoped identity | - -## Maturity model - -### Level 1 (baseline) - -- static policy checks for CI configuration -- isolated runners for untrusted PRs -- least-privilege CI tokens - -### Level 2 (intermediate) - -- runtime admission/enforcement policies -- default-deny network egress -- short-lived credentials via federation - -### Level 3 (advanced) - -- signed provenance verification on promotion -- policy decision logging with centralized audit -- periodic control validation exercises (breakout tests/tabletops) - -## Common anti-patterns - -- Writing policy that is never enforced at runtime. -- Treating sandbox exceptions as permanent defaults. -- Failing open when policy engine is unavailable. -- Skipping auditability for policy decisions. - -## References - -- NIST SP 800-53 Rev. 5 (policy, audit, and access controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- Kubernetes, *Admission Controllers*: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview - ---- - - - +- New location: [/devsecops/isolation/sandboxing-and-policy-enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) diff --git a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx index 3aae08fa..067fe7c0 100644 --- a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx @@ -1,105 +1,10 @@ --- title: "Sandboxing for Tool Execution | SEAL" -description: "Controls for high-risk tool invocation in automation workflows: policy checks, constrained runtime, and auditable side effects." -tags: - - Engineer/Developer - - Security Specialist - - Operations & Strategy - - Devops -contributors: - - role: wrote - users: [munamwasi, jubos, masterfung] - - role: reviewed - users: [mattaereal] +description: "This page moved to /devsecops/isolation/sandboxing-for-tool-execution." --- -import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' +# Page moved - - +This content now lives under the **Isolation & Sandboxing** section. -# Sandboxing for Tool Execution - - - - -Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. - -This is often the highest-risk path in DevSecOps workflows. - -## Design principle - -Treat every tool call as an untrusted request until it passes policy checks. - -A secure flow is: - -1. **Intent validation** (is this action allowed?) -2. **Capability check** (does this runtime identity hold required permission?) -3. **Sandboxed execution** (bounded filesystem/network/resources) -4. **Audit and verification** (what happened, by whom, with what result?) - -## Tool risk tiers - -| Tier | Example actions | Minimum controls | -| --- | --- | --- | -| Low | read repo files, query status APIs | read-only tokens, no secret access | -| Medium | create PR comments, upload artifacts | scoped write perms, output size limits | -| High | merge, deploy, publish package, modify infra | approval gates, protected environment, strong sandbox | -| Critical | key usage, signing, production data mutation | dedicated isolated runtime, multi-party approval, full audit trail | - -## Practical controls - -### Restrict execution context - -- run tool calls in ephemeral runtime -- use read-only root filesystem where feasible -- block host mounts unless explicitly required -- apply seccomp/AppArmor/SELinux enforcement - -### Restrict identity and credentials - -- issue short-lived, scoped credentials -- bind tokens to specific tool purpose and environment -- disable ambient credentials in untrusted workflows - -### Restrict network side effects - -- deny-by-default egress -- allowlist specific endpoints per tool -- block direct access to internal admin APIs from low-trust jobs - -### Restrict invocation behavior - -- maximum execution time -- command/input/output size limits -- prevent recursive tool chaining unless explicitly allowed -- require explicit confirmation for high-risk operations - -## Policy examples for CI/CD tooling - -- “Untrusted PR jobs may run read-only analysis tools but cannot trigger deployment tools.” -- “Release tooling may publish only signed artifacts generated in the same pipeline.” -- “Infrastructure mutation tools require protected branch + approval + provenance verification.” - -## Common anti-patterns - -- Directly mapping user input to shell execution without policy mediation. -- Reusing broad admin credentials across multiple tools. -- Allowing tool calls to inherit unrestricted network access. -- Missing audit logs for high-impact tool operations. - -## References - -- NIST SP 800-53 Rev. 5 (least privilege, audit, execution controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html -- Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ -- Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- Firecracker documentation: https://github.com/firecracker-microvm/firecracker/tree/main/docs -- gVisor documentation: https://gvisor.dev/docs/ - ---- - - - +- New location: [/devsecops/isolation/sandboxing-for-tool-execution](/devsecops/isolation/sandboxing-for-tool-execution) diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index 02d3a959..faecc53f 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -159,11 +159,6 @@ "/community-management/twitter": [ "Community & Marketing" ], - "/devsecops/capability-based-isolation": [ - "Engineer/Developer", - "Security Specialist", - "Operations & Strategy" - ], "/devsecops/code-signing": [ "Engineer/Developer", "Security Specialist", @@ -175,58 +170,63 @@ "Devops", "SRE" ], - "/devsecops/execution-sandboxing-practical-guide": [ - "Engineer/Developer", - "Security Specialist", - "Operations & Strategy", - "Devops", - "SRE" - ], - "/devsecops/execution-sandboxing": [ + "/devsecops/integrated-development-environments": [ "Engineer/Developer", "Security Specialist", - "Operations & Strategy", "Devops" ], - "/devsecops/integrated-development-environments": [ + "/devsecops/isolation/capability-based-isolation": [ "Engineer/Developer", "Security Specialist", - "Devops" + "Operations & Strategy" ], - "/devsecops/network-and-resource-isolation": [ + "/devsecops/isolation/execution-sandboxing-practical-guide": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", "Devops", "SRE" ], - "/devsecops/overview": [ + "/devsecops/isolation/execution-sandboxing": [ "Engineer/Developer", "Security Specialist", + "Operations & Strategy", + "Devops" + ], + "/devsecops/isolation/network-and-resource-isolation": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", "Devops", "SRE" ], - "/devsecops/repository-hardening": [ + "/devsecops/isolation/sandboxing-and-isolation": [ "Engineer/Developer", "Security Specialist", + "Operations & Strategy", "Devops" ], - "/devsecops/sandboxing-and-isolation": [ + "/devsecops/isolation/sandboxing-and-policy-enforcement": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", "Devops" ], - "/devsecops/sandboxing-and-policy-enforcement": [ + "/devsecops/isolation/sandboxing-for-tool-execution": [ "Engineer/Developer", "Security Specialist", "Operations & Strategy", "Devops" ], - "/devsecops/sandboxing-for-tool-execution": [ + "/devsecops/overview": [ + "Engineer/Developer", + "Security Specialist", + "Devops", + "SRE" + ], + "/devsecops/repository-hardening": [ "Engineer/Developer", "Security Specialist", - "Operations & Strategy", "Devops" ], "/devsecops/security-testing": [ diff --git a/vocs.config.tsx b/vocs.config.tsx index 8309edd4..29fd9ff8 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -304,13 +304,13 @@ const config = { text: 'Isolation & Sandboxing', collapsed: false, items: [ - { text: 'Sandboxing & Isolation', link: '/devsecops/sandboxing-and-isolation', dev: true }, - { text: 'Execution Sandboxing', link: '/devsecops/execution-sandboxing', dev: true }, - { text: 'Capability-Based Isolation', link: '/devsecops/capability-based-isolation', dev: true }, - { text: 'Sandboxing for Tool Execution', link: '/devsecops/sandboxing-for-tool-execution', dev: true }, - { text: 'Network & Resource Isolation', link: '/devsecops/network-and-resource-isolation', dev: true }, - { text: 'Sandboxing & Policy Enforcement', link: '/devsecops/sandboxing-and-policy-enforcement', dev: true }, - { text: 'Execution Sandboxing: A Practical Guide', link: '/devsecops/execution-sandboxing-practical-guide', dev: true }, + { text: 'Sandboxing & Isolation', link: '/devsecops/isolation/sandboxing-and-isolation', dev: true }, + { text: 'Execution Sandboxing', link: '/devsecops/isolation/execution-sandboxing', dev: true }, + { text: 'Capability-Based Isolation', link: '/devsecops/isolation/capability-based-isolation', dev: true }, + { text: 'Sandboxing for Tool Execution', link: '/devsecops/isolation/sandboxing-for-tool-execution', dev: true }, + { text: 'Network & Resource Isolation', link: '/devsecops/isolation/network-and-resource-isolation', dev: true }, + { text: 'Sandboxing & Policy Enforcement', link: '/devsecops/isolation/sandboxing-and-policy-enforcement', dev: true }, + { text: 'Execution Sandboxing: A Practical Guide', link: '/devsecops/isolation/execution-sandboxing-practical-guide', dev: true }, ] }, { text: 'Code Signing', link: '/devsecops/code-signing', dev: true }, @@ -403,7 +403,7 @@ const config = { { text: 'AI Workflows: Developers vs Non-Developers', link: '/ai-security/ai-workflows-developers-vs-non-developers', dev: true }, { text: 'Data Exfiltration via Generative Systems', link: '/ai-security/data-exfiltration-via-generative-systems', dev: true }, { text: 'Execution-Path Enforcement', link: '/ai-security/execution-path-enforcement', dev: true }, - { text: 'Sandboxing & Isolation (DevSecOps)', link: '/devsecops/sandboxing-and-isolation', dev: true }, + { text: 'Sandboxing & Isolation (DevSecOps)', link: '/devsecops/isolation/sandboxing-and-isolation', dev: true }, ] }, { From 8eab78e8f090073d369cd0c2c9fb97d6989faea5 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 08/14] docs(devsecops): add key takeaway callouts to overview and isolation pages --- .../devsecops/isolation/capability-based-isolation.mdx | 6 ++++++ .../isolation/execution-sandboxing-practical-guide.mdx | 6 ++++++ docs/pages/devsecops/isolation/execution-sandboxing.mdx | 6 ++++++ .../devsecops/isolation/network-and-resource-isolation.mdx | 6 ++++++ docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx | 6 ++++++ .../isolation/sandboxing-and-policy-enforcement.mdx | 6 ++++++ .../devsecops/isolation/sandboxing-for-tool-execution.mdx | 6 ++++++ docs/pages/devsecops/overview.mdx | 6 ++++++ 8 files changed, 48 insertions(+) diff --git a/docs/pages/devsecops/isolation/capability-based-isolation.mdx b/docs/pages/devsecops/isolation/capability-based-isolation.mdx index 04c35352..e8f5b5c8 100644 --- a/docs/pages/devsecops/isolation/capability-based-isolation.mdx +++ b/docs/pages/devsecops/isolation/capability-based-isolation.mdx @@ -22,6 +22,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Replace broad ambient permissions with explicit, task-scoped capabilities. +> - Map CI/CD stages to separate identities instead of reusing one powerful token everywhere. +> - Enforce policy conditions and short-lived credentials for sensitive actions. + Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. In practice: do not give a job “admin” rights when it only needs “read dependency metadata” or “upload artifact to one path”. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx index f4a99535..f75ac55a 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -24,6 +24,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Define trust zones first, then map controls to each zone. +> - Keep untrusted validation paths physically and logically separate from release/deploy paths. +> - Prioritize ephemeral runners, short-lived credentials, and deny-by-default egress. + This guide translates sandboxing principles into concrete controls for real CI/CD environments. Use it when you need to answer: **“What should we deploy this quarter to materially reduce risk from untrusted execution?”** diff --git a/docs/pages/devsecops/isolation/execution-sandboxing.mdx b/docs/pages/devsecops/isolation/execution-sandboxing.mdx index aca44036..cb86f8e3 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing.mdx @@ -23,6 +23,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Run jobs and automation in ephemeral, least-privilege environments by default. +> - Isolate process, filesystem, identity, and network together, not as separate optional controls. +> - Use stronger boundaries for untrusted or high-impact workflows. + Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. In DevSecOps, this applies to: diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx index 0ea8be7a..0e584279 100644 --- a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -24,6 +24,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Deny outbound network access by default and allowlist only required destinations. +> - Segment trust zones to block lateral movement from compromised workloads. +> - Enforce hard CPU, memory, process, timeout, and concurrency limits to contain abuse. + Network and compute controls are critical containment layers for sandboxed execution. Without them, a compromised build or tool can: diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx index 10c64ef9..95aebb73 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -21,6 +21,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Assume untrusted execution can fail or be compromised, then design containment by default. +> - Apply layered controls across identity, runtime, filesystem, network, and resources. +> - Increase isolation depth as risk increases (container hardening → sandboxed containers → microVM/VM). + This section is the canonical DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). The core objective is simple: **assume compromise can happen, then contain blast radius by design**. diff --git a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx index cc337090..d49c02e3 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx @@ -23,6 +23,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Policy determines what is allowed; sandboxing limits damage when allowed actions go wrong. +> - Enforce controls before execution, during runtime, and before promotion/deploy. +> - Use both layers together to close gaps that either control leaves on its own. + Sandboxing and policy enforcement solve different problems and must be used together: - **Policy** decides what should be allowed. diff --git a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx index f84d2871..08a32e9c 100644 --- a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx @@ -23,6 +23,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Treat every tool invocation as untrusted until policy checks approve it. +> - Add stronger gates and isolation for high-impact actions such as deploy, merge, and publish. +> - Require auditable identity plus execution logs for every side effect. + Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. This is often the highest-risk path in DevSecOps workflows. diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index be083ef7..d455c39b 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -18,6 +18,12 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr +> 🔑 **Key Takeaway** +> +> - Build security into delivery workflows from the start, not as a post-release patch. +> - Automate security checks early in CI/CD so issues are caught before production. +> - Use sandboxing and isolation to contain blast radius from untrusted execution. + Traditionally, rapid development and deployment is often prioritized at the expense of security considerations. This is generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into consideration too. To effectively address this without compromising on rapid development and deployment, it is essential From 2035cf92598729378412c41c926832032a4193c5 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 10:23:30 -0300 Subject: [PATCH 09/14] docs(ai-security): add brief DevSecOps isolation reference and remove canonical wording --- ...vsecops-isolation-sandboxing-reference.mdx | 43 +++++++++++++++++++ docs/pages/ai-security/index.mdx | 1 + docs/pages/ai-security/overview.mdx | 13 +++--- .../isolation/sandboxing-and-isolation.mdx | 4 +- docs/pages/devsecops/overview.mdx | 4 +- utils/fetched-tags.json | 6 +++ vocs.config.tsx | 2 +- 7 files changed, 62 insertions(+), 11 deletions(-) create mode 100644 docs/pages/ai-security/devsecops-isolation-sandboxing-reference.mdx diff --git a/docs/pages/ai-security/devsecops-isolation-sandboxing-reference.mdx b/docs/pages/ai-security/devsecops-isolation-sandboxing-reference.mdx new file mode 100644 index 00000000..fb3ed97c --- /dev/null +++ b/docs/pages/ai-security/devsecops-isolation-sandboxing-reference.mdx @@ -0,0 +1,43 @@ +--- +title: "DevSecOps Isolation & Sandboxing Reference | SEAL" +description: "Brief AI Security takeaway with direct links to DevSecOps isolation and sandboxing guidance." +tags: + - Engineer/Developer + - Security Specialist + - Operations & Strategy + - Devops +contributors: + - role: wrote + users: [mattaereal] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../components' + + + + +# DevSecOps Isolation & Sandboxing (Brief Reference) + + + + +For AI systems that execute tools, run code, or touch sensitive environments, +strong isolation is a runtime safety baseline. Keep AI Security focused on +threats and controls, and use the DevSecOps isolation pages below for detailed +containment patterns. + +## Go to DevSecOps isolation guidance + +- [Isolation folder index](/devsecops/isolation) +- [Sandboxing & Isolation overview](/devsecops/isolation/sandboxing-and-isolation) +- [Execution Sandboxing](/devsecops/isolation/execution-sandboxing) +- [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide) +- [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation) +- [Network & Resource Isolation](/devsecops/isolation/network-and-resource-isolation) +- [Sandboxing for Tool Execution](/devsecops/isolation/sandboxing-for-tool-execution) +- [Sandboxing & Policy Enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) + +--- + + + diff --git a/docs/pages/ai-security/index.mdx b/docs/pages/ai-security/index.mdx index c382d15e..97f3dd03 100644 --- a/docs/pages/ai-security/index.mdx +++ b/docs/pages/ai-security/index.mdx @@ -17,3 +17,4 @@ title: "Ai Security" - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) +- [DevSecOps Isolation & Sandboxing Reference](/ai-security/devsecops-isolation-sandboxing-reference) diff --git a/docs/pages/ai-security/overview.mdx b/docs/pages/ai-security/overview.mdx index bf093cec..3eade7ae 100644 --- a/docs/pages/ai-security/overview.mdx +++ b/docs/pages/ai-security/overview.mdx @@ -113,18 +113,19 @@ as token transfers, altered governance votes, or treasury losses. The sections that follow outline the major threat vectors facing AI-driven systems, including prompt injection, browser-based manipulation, data -exfiltration, execution path weaknesses, and sandbox escape scenarios. They also -highlight established security providers whose tools address each category. The -objective is to clarify the defensive landscape so that security teams, -developers, and protocol designers can build layered protections that fit their -specific deployment models and risk tolerance. +exfiltration, and execution path weaknesses. They also highlight established +security providers whose tools address each category. A short cross-reference +is included for DevSecOps isolation guidance. The objective is to clarify the +defensive landscape so that security teams, developers, and protocol designers +can build layered protections that fit their specific deployment models and +risk tolerance. - [Prompt Injection Defenses](/ai-security/prompt-injection-defenses) - [AI Browsers](/ai-security/ai-browsers) - [AI Workflows: Developers vs Non-Developers](/ai-security/ai-workflows-developers-vs-non-developers) - [Data Exfiltration via Generative Systems](/ai-security/data-exfiltration-via-generative-systems) - [Execution-Path Enforcement](/ai-security/execution-path-enforcement) -- [Sandboxing & Isolation (canonical)](/devsecops/isolation/sandboxing-and-isolation) +- [DevSecOps Isolation & Sandboxing (Brief Reference)](/ai-security/devsecops-isolation-sandboxing-reference) --- diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx index 95aebb73..db3832bb 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -1,6 +1,6 @@ --- title: "Sandboxing & Isolation | SEAL" -description: "Canonical DevSecOps guidance for sandboxing, isolation, and containment across CI/CD, runners, tooling, and execution environments." +description: "DevSecOps guidance for sandboxing, isolation, and containment across CI/CD, runners, tooling, and execution environments." tags: - Engineer/Developer - Security Specialist @@ -27,7 +27,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > - Apply layered controls across identity, runtime, filesystem, network, and resources. > - Increase isolation depth as risk increases (container hardening → sandboxed containers → microVM/VM). -This section is the canonical DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). +This section is the DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). The core objective is simple: **assume compromise can happen, then contain blast radius by design**. diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index d455c39b..002d36f7 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -41,12 +41,12 @@ Some of the key areas to consider are: 2. Implement automated security testing and monitoring. 3. Development, Operations and Security teams should be aligned and work closely together. 4. Use **sandboxing & isolation** to reduce blast radius when running tooling, builds, plugins, and other potentially risky execution. - - See: [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) (canonical section) + - See: [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation) ## What’s inside DevSecOps - **Isolation & Sandboxing** - - [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation): Canonical guidance for containment patterns across CI/CD and automation workflows. + - [Sandboxing & Isolation](/devsecops/isolation/sandboxing-and-isolation): Core guidance for containment patterns across CI/CD and automation workflows. - [Execution Sandboxing](/devsecops/isolation/execution-sandboxing): Core runtime isolation controls to limit blast radius and privilege abuse. - [Execution Sandboxing: A Practical Guide](/devsecops/isolation/execution-sandboxing-practical-guide): Implementation playbook for runners, untrusted PRs, secrets, and egress. - [Capability-Based Isolation](/devsecops/isolation/capability-based-isolation): Replace broad privileges with explicit, auditable capability grants. diff --git a/utils/fetched-tags.json b/utils/fetched-tags.json index faecc53f..dd4d6e4f 100644 --- a/utils/fetched-tags.json +++ b/utils/fetched-tags.json @@ -41,6 +41,12 @@ "Security Specialist", "Operations & Strategy" ], + "/ai-security/devsecops-isolation-sandboxing-reference": [ + "Engineer/Developer", + "Security Specialist", + "Operations & Strategy", + "Devops" + ], "/ai-security/execution-path-enforcement": [ "Engineer/Developer", "Security Specialist", diff --git a/vocs.config.tsx b/vocs.config.tsx index 29fd9ff8..101d533e 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -403,7 +403,7 @@ const config = { { text: 'AI Workflows: Developers vs Non-Developers', link: '/ai-security/ai-workflows-developers-vs-non-developers', dev: true }, { text: 'Data Exfiltration via Generative Systems', link: '/ai-security/data-exfiltration-via-generative-systems', dev: true }, { text: 'Execution-Path Enforcement', link: '/ai-security/execution-path-enforcement', dev: true }, - { text: 'Sandboxing & Isolation (DevSecOps)', link: '/devsecops/isolation/sandboxing-and-isolation', dev: true }, + { text: 'DevSecOps Isolation & Sandboxing (Brief Reference)', link: '/ai-security/devsecops-isolation-sandboxing-reference', dev: true }, ] }, { From 26f28c3b80dd687c822a7109333f3192ceef3913 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mat=C3=ADas=20Aereal=20Ae=C3=B3n?= <388605+mattaereal@users.noreply.github.com> Date: Tue, 10 Mar 2026 11:26:53 -0300 Subject: [PATCH 10/14] Delete docs/pages/config/index.mdx --- docs/pages/config/index.mdx | 15 --------------- 1 file changed, 15 deletions(-) delete mode 100644 docs/pages/config/index.mdx diff --git a/docs/pages/config/index.mdx b/docs/pages/config/index.mdx deleted file mode 100644 index 12ece8be..00000000 --- a/docs/pages/config/index.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Config" ---- - -{/* AUTOGENERATED: This file is generated by utils/generate-folder-indexes.js */} - -# Config - -> _Note:_ This page is auto-generated. Please use the sidebar to explore the docs instead of -> navigating directory paths directly. - -## Pages - -- [Template](/config/template) -- [Using Contributors](/config/using-contributors) From 77590d8b52d33925f286b5c6aefced1a18cbfbb3 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 11:35:38 -0300 Subject: [PATCH 11/14] docs(devsecops): remove legacy isolation moved-page stubs --- docs/pages/devsecops/capability-based-isolation.mdx | 10 ---------- .../devsecops/execution-sandboxing-practical-guide.mdx | 10 ---------- docs/pages/devsecops/execution-sandboxing.mdx | 10 ---------- docs/pages/devsecops/index.mdx | 7 ------- .../pages/devsecops/network-and-resource-isolation.mdx | 10 ---------- docs/pages/devsecops/sandboxing-and-isolation.mdx | 10 ---------- .../devsecops/sandboxing-and-policy-enforcement.mdx | 10 ---------- docs/pages/devsecops/sandboxing-for-tool-execution.mdx | 10 ---------- 8 files changed, 77 deletions(-) delete mode 100644 docs/pages/devsecops/capability-based-isolation.mdx delete mode 100644 docs/pages/devsecops/execution-sandboxing-practical-guide.mdx delete mode 100644 docs/pages/devsecops/execution-sandboxing.mdx delete mode 100644 docs/pages/devsecops/network-and-resource-isolation.mdx delete mode 100644 docs/pages/devsecops/sandboxing-and-isolation.mdx delete mode 100644 docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx delete mode 100644 docs/pages/devsecops/sandboxing-for-tool-execution.mdx diff --git a/docs/pages/devsecops/capability-based-isolation.mdx b/docs/pages/devsecops/capability-based-isolation.mdx deleted file mode 100644 index a15dc20c..00000000 --- a/docs/pages/devsecops/capability-based-isolation.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Capability-Based Isolation | SEAL" -description: "This page moved to /devsecops/isolation/capability-based-isolation." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/capability-based-isolation](/devsecops/isolation/capability-based-isolation) diff --git a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx deleted file mode 100644 index 5f800117..00000000 --- a/docs/pages/devsecops/execution-sandboxing-practical-guide.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Execution Sandboxing: A Practical Guide | SEAL" -description: "This page moved to /devsecops/isolation/execution-sandboxing-practical-guide." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/execution-sandboxing-practical-guide](/devsecops/isolation/execution-sandboxing-practical-guide) diff --git a/docs/pages/devsecops/execution-sandboxing.mdx b/docs/pages/devsecops/execution-sandboxing.mdx deleted file mode 100644 index bcf0c07d..00000000 --- a/docs/pages/devsecops/execution-sandboxing.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Execution Sandboxing | SEAL" -description: "This page moved to /devsecops/isolation/execution-sandboxing." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/execution-sandboxing](/devsecops/isolation/execution-sandboxing) diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx index 8e6d9ce4..b7892c25 100644 --- a/docs/pages/devsecops/index.mdx +++ b/docs/pages/devsecops/index.mdx @@ -17,11 +17,4 @@ title: "Devsecops" - [Securing Development Environments](/devsecops/integrated-development-environments) - [Repository Hardening](/devsecops/repository-hardening) - [Security Testing](/devsecops/security-testing) -- [Capability-Based Isolation](/devsecops/capability-based-isolation) -- [Execution Sandboxing](/devsecops/execution-sandboxing) -- [Execution Sandboxing: A Practical Guide](/devsecops/execution-sandboxing-practical-guide) - [Isolation](/devsecops/isolation) -- [Network & Resource Isolation](/devsecops/network-and-resource-isolation) -- [Sandboxing & Isolation](/devsecops/sandboxing-and-isolation) -- [Sandboxing & Policy Enforcement](/devsecops/sandboxing-and-policy-enforcement) -- [Sandboxing for Tool Execution](/devsecops/sandboxing-for-tool-execution) diff --git a/docs/pages/devsecops/network-and-resource-isolation.mdx b/docs/pages/devsecops/network-and-resource-isolation.mdx deleted file mode 100644 index 853f84f2..00000000 --- a/docs/pages/devsecops/network-and-resource-isolation.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Network & Resource Isolation | SEAL" -description: "This page moved to /devsecops/isolation/network-and-resource-isolation." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/network-and-resource-isolation](/devsecops/isolation/network-and-resource-isolation) diff --git a/docs/pages/devsecops/sandboxing-and-isolation.mdx b/docs/pages/devsecops/sandboxing-and-isolation.mdx deleted file mode 100644 index e56dd0cb..00000000 --- a/docs/pages/devsecops/sandboxing-and-isolation.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Sandboxing & Isolation | SEAL" -description: "This page moved to /devsecops/isolation/sandboxing-and-isolation." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/sandboxing-and-isolation](/devsecops/isolation/sandboxing-and-isolation) diff --git a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx deleted file mode 100644 index 5f869e39..00000000 --- a/docs/pages/devsecops/sandboxing-and-policy-enforcement.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Sandboxing & Policy Enforcement | SEAL" -description: "This page moved to /devsecops/isolation/sandboxing-and-policy-enforcement." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/sandboxing-and-policy-enforcement](/devsecops/isolation/sandboxing-and-policy-enforcement) diff --git a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/sandboxing-for-tool-execution.mdx deleted file mode 100644 index 067fe7c0..00000000 --- a/docs/pages/devsecops/sandboxing-for-tool-execution.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Sandboxing for Tool Execution | SEAL" -description: "This page moved to /devsecops/isolation/sandboxing-for-tool-execution." ---- - -# Page moved - -This content now lives under the **Isolation & Sandboxing** section. - -- New location: [/devsecops/isolation/sandboxing-for-tool-execution](/devsecops/isolation/sandboxing-for-tool-execution) From acd25e8079b6cab14f5ed0a7ee06f86b1e8a27d5 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 12:50:10 -0300 Subject: [PATCH 12/14] docs(devsecops): tighten key takeaway bullet callouts --- .../devsecops/isolation/capability-based-isolation.mdx | 2 +- .../isolation/execution-sandboxing-practical-guide.mdx | 2 +- docs/pages/devsecops/isolation/execution-sandboxing.mdx | 2 +- .../devsecops/isolation/network-and-resource-isolation.mdx | 2 +- docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx | 6 +++--- .../isolation/sandboxing-and-policy-enforcement.mdx | 4 ++-- .../devsecops/isolation/sandboxing-for-tool-execution.mdx | 4 ++-- docs/pages/devsecops/overview.mdx | 6 +++--- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/pages/devsecops/isolation/capability-based-isolation.mdx b/docs/pages/devsecops/isolation/capability-based-isolation.mdx index e8f5b5c8..9d5a653b 100644 --- a/docs/pages/devsecops/isolation/capability-based-isolation.mdx +++ b/docs/pages/devsecops/isolation/capability-based-isolation.mdx @@ -25,7 +25,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > > - Replace broad ambient permissions with explicit, task-scoped capabilities. -> - Map CI/CD stages to separate identities instead of reusing one powerful token everywhere. +> - Map CI/CD stages to separate identities instead of reusing powerful tokens. > - Enforce policy conditions and short-lived credentials for sensitive actions. Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx index f75ac55a..88ed3897 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -27,7 +27,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > > - Define trust zones first, then map controls to each zone. -> - Keep untrusted validation paths physically and logically separate from release/deploy paths. +> - Keep untrusted validation separate from release and deploy paths. > - Prioritize ephemeral runners, short-lived credentials, and deny-by-default egress. This guide translates sandboxing principles into concrete controls for real CI/CD environments. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing.mdx b/docs/pages/devsecops/isolation/execution-sandboxing.mdx index cb86f8e3..ce73d490 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing.mdx @@ -26,7 +26,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > > - Run jobs and automation in ephemeral, least-privilege environments by default. -> - Isolate process, filesystem, identity, and network together, not as separate optional controls. +> - Isolate process, filesystem, identity, and network together. > - Use stronger boundaries for untrusted or high-impact workflows. Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx index 0e584279..efe30308 100644 --- a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -28,7 +28,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > > - Deny outbound network access by default and allowlist only required destinations. > - Segment trust zones to block lateral movement from compromised workloads. -> - Enforce hard CPU, memory, process, timeout, and concurrency limits to contain abuse. +> - Enforce hard limits for CPU, memory, processes, timeouts, and concurrency. Network and compute controls are critical containment layers for sandboxed execution. diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx index db3832bb..bc55520c 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -23,9 +23,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > -> - Assume untrusted execution can fail or be compromised, then design containment by default. -> - Apply layered controls across identity, runtime, filesystem, network, and resources. -> - Increase isolation depth as risk increases (container hardening → sandboxed containers → microVM/VM). +> - Assume untrusted execution and design containment by default. +> - Layer controls across identity, runtime, filesystem, network, and resources. +> - Increase isolation depth with risk (hardened container → sandboxed container → microVM/VM). This section is the DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). diff --git a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx index d49c02e3..d6cd2618 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx @@ -26,8 +26,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > > - Policy determines what is allowed; sandboxing limits damage when allowed actions go wrong. -> - Enforce controls before execution, during runtime, and before promotion/deploy. -> - Use both layers together to close gaps that either control leaves on its own. +> - Enforce controls before execution, during runtime, and before promotion or deploy. +> - Use both layers together to close gaps either control leaves on its own. Sandboxing and policy enforcement solve different problems and must be used together: diff --git a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx index 08a32e9c..30833804 100644 --- a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx @@ -25,9 +25,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > -> - Treat every tool invocation as untrusted until policy checks approve it. +> - Treat tool invocations as untrusted until policy checks approve them. > - Add stronger gates and isolation for high-impact actions such as deploy, merge, and publish. -> - Require auditable identity plus execution logs for every side effect. +> - Require auditable identity and execution logs for every side effect. Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 002d36f7..02fd04b9 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -20,9 +20,9 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr > 🔑 **Key Takeaway** > -> - Build security into delivery workflows from the start, not as a post-release patch. -> - Automate security checks early in CI/CD so issues are caught before production. -> - Use sandboxing and isolation to contain blast radius from untrusted execution. +> - Shift security left into planning, coding, and delivery. +> - Automate CI/CD checks so issues fail fast before production. +> - Use sandboxing and isolation to contain untrusted execution. Traditionally, rapid development and deployment is often prioritized at the expense of security considerations. This is generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into From 42f4f259467e39aa29e99b54758fc5eaf12a3076 Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Tue, 10 Mar 2026 12:55:08 -0300 Subject: [PATCH 13/14] docs(devsecops): convert key takeaways to paragraph style --- .../devsecops/isolation/capability-based-isolation.mdx | 6 +----- .../isolation/execution-sandboxing-practical-guide.mdx | 6 +----- docs/pages/devsecops/isolation/execution-sandboxing.mdx | 6 +----- .../devsecops/isolation/network-and-resource-isolation.mdx | 6 +----- docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx | 6 +----- .../isolation/sandboxing-and-policy-enforcement.mdx | 6 +----- .../devsecops/isolation/sandboxing-for-tool-execution.mdx | 6 +----- docs/pages/devsecops/overview.mdx | 6 +----- 8 files changed, 8 insertions(+), 40 deletions(-) diff --git a/docs/pages/devsecops/isolation/capability-based-isolation.mdx b/docs/pages/devsecops/isolation/capability-based-isolation.mdx index 9d5a653b..ae1cbaff 100644 --- a/docs/pages/devsecops/isolation/capability-based-isolation.mdx +++ b/docs/pages/devsecops/isolation/capability-based-isolation.mdx @@ -22,11 +22,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Replace broad ambient permissions with explicit, task-scoped capabilities. -> - Map CI/CD stages to separate identities instead of reusing powerful tokens. -> - Enforce policy conditions and short-lived credentials for sensitive actions. +> 🔑 **Key Takeaway**: Capability-based isolation replaces broad ambient permissions with short-lived, task-scoped grants tied to context, so compromised workflows cannot exceed narrowly defined actions. Capability-based isolation limits what automation can do by granting **specific actions under explicit conditions**, instead of broad ambient privileges. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx index 88ed3897..9e64954d 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -24,11 +24,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Define trust zones first, then map controls to each zone. -> - Keep untrusted validation separate from release and deploy paths. -> - Prioritize ephemeral runners, short-lived credentials, and deny-by-default egress. +> 🔑 **Key Takeaway**: Start by defining trust zones, then apply matching controls that keep untrusted validation isolated from release paths while enforcing ephemeral runners, short-lived credentials, and deny-by-default egress. This guide translates sandboxing principles into concrete controls for real CI/CD environments. diff --git a/docs/pages/devsecops/isolation/execution-sandboxing.mdx b/docs/pages/devsecops/isolation/execution-sandboxing.mdx index ce73d490..40a3b881 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing.mdx @@ -23,11 +23,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Run jobs and automation in ephemeral, least-privilege environments by default. -> - Isolate process, filesystem, identity, and network together. -> - Use stronger boundaries for untrusted or high-impact workflows. +> 🔑 **Key Takeaway**: Execution sandboxing reduces blast radius by running automation in ephemeral least-privilege environments and enforcing isolation across process, filesystem, identity, and network, with stronger boundaries for higher-risk workflows. Execution sandboxing means running workloads inside controlled boundaries so that compromise of a job, script, or tool does **not** become compromise of your platform. diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx index efe30308..8e039cd9 100644 --- a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -24,11 +24,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Deny outbound network access by default and allowlist only required destinations. -> - Segment trust zones to block lateral movement from compromised workloads. -> - Enforce hard limits for CPU, memory, processes, timeouts, and concurrency. +> 🔑 **Key Takeaway**: Treat network and compute as hard containment boundaries: deny egress by default, segment trust zones to prevent lateral movement, and enforce strict resource limits to block abuse and runaway jobs. Network and compute controls are critical containment layers for sandboxed execution. diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx index bc55520c..6226532b 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -21,11 +21,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Assume untrusted execution and design containment by default. -> - Layer controls across identity, runtime, filesystem, network, and resources. -> - Increase isolation depth with risk (hardened container → sandboxed container → microVM/VM). +> 🔑 **Key Takeaway**: Assume execution can be untrusted and apply layered containment across identity, runtime, filesystem, network, and resources, increasing isolation strength with workload risk. This section is the DevSecOps guide for **running untrusted or semi-trusted execution safely**: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many). diff --git a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx index d6cd2618..8f47b02d 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx @@ -23,11 +23,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Policy determines what is allowed; sandboxing limits damage when allowed actions go wrong. -> - Enforce controls before execution, during runtime, and before promotion or deploy. -> - Use both layers together to close gaps either control leaves on its own. +> 🔑 **Key Takeaway**: Policy decides what may run and sandboxing limits damage if it fails, so both must be enforced before, during, and after execution to close control gaps. Sandboxing and policy enforcement solve different problems and must be used together: diff --git a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx index 30833804..cf0ec013 100644 --- a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx @@ -23,11 +23,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Treat tool invocations as untrusted until policy checks approve them. -> - Add stronger gates and isolation for high-impact actions such as deploy, merge, and publish. -> - Require auditable identity and execution logs for every side effect. +> 🔑 **Key Takeaway**: Every tool invocation should pass policy, run in a constrained sandbox, and leave auditable evidence, with stronger gates for high-impact actions like deploy, merge, and publish. Tool execution is where automation becomes real-world side effects: file changes, API mutations, infrastructure updates, deployments, or financial transactions. diff --git a/docs/pages/devsecops/overview.mdx b/docs/pages/devsecops/overview.mdx index 02fd04b9..1739e722 100644 --- a/docs/pages/devsecops/overview.mdx +++ b/docs/pages/devsecops/overview.mdx @@ -18,11 +18,7 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr -> 🔑 **Key Takeaway** -> -> - Shift security left into planning, coding, and delivery. -> - Automate CI/CD checks so issues fail fast before production. -> - Use sandboxing and isolation to contain untrusted execution. +> 🔑 **Key Takeaway**: DevSecOps works when security is embedded from planning through delivery, automated checks stop unsafe changes before production, and sandboxed execution contains risk when untrusted code or tooling runs. Traditionally, rapid development and deployment is often prioritized at the expense of security considerations. This is generally speaking no different in web3, but it is important to take integrity, confidentiality, and availability into From 4070e1e0943ca69115ae582fd8f7eca8063d9f6a Mon Sep 17 00:00:00 2001 From: Frameworks Volunteer Date: Wed, 11 Mar 2026 10:04:48 -0300 Subject: [PATCH 14/14] fix(devsecops): remove broken reference links --- .../pages/devsecops/isolation/capability-based-isolation.mdx | 3 +-- .../isolation/execution-sandboxing-practical-guide.mdx | 4 ++-- docs/pages/devsecops/isolation/execution-sandboxing.mdx | 2 +- .../devsecops/isolation/network-and-resource-isolation.mdx | 2 +- docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx | 4 +--- .../isolation/sandboxing-and-policy-enforcement.mdx | 5 ++--- .../devsecops/isolation/sandboxing-for-tool-execution.mdx | 2 +- 7 files changed, 9 insertions(+), 13 deletions(-) diff --git a/docs/pages/devsecops/isolation/capability-based-isolation.mdx b/docs/pages/devsecops/isolation/capability-based-isolation.mdx index ae1cbaff..1177e5bf 100644 --- a/docs/pages/devsecops/isolation/capability-based-isolation.mdx +++ b/docs/pages/devsecops/isolation/capability-based-isolation.mdx @@ -99,10 +99,9 @@ Capability revocation should be immediate and automated for suspicious activity. - NIST SP 800-53 Rev. 5 (least privilege and access control): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final - NIST glossary, *Least Privilege*: https://csrc.nist.gov/glossary/term/least_privilege -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments - Kubernetes, *Role Based Access Control*: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview +- SLSA specification: https://slsa.dev/spec/v1.0/ --- diff --git a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx index 9e64954d..7657443f 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing-practical-guide.mdx @@ -223,13 +223,13 @@ Have a playbook for: - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final - NIST SP 800-204A, *Building Secure Microservices-based Applications Using Service-Mesh Architecture*: https://csrc.nist.gov/pubs/sp/800/204/a/final - NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments + - GitHub Actions security hardening: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions - Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ - Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ - Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html -- SLSA specification: https://slsa.dev/spec/v1.0/overview +- SLSA specification: https://slsa.dev/spec/v1.0/ --- diff --git a/docs/pages/devsecops/isolation/execution-sandboxing.mdx b/docs/pages/devsecops/isolation/execution-sandboxing.mdx index 40a3b881..fa6a6923 100644 --- a/docs/pages/devsecops/isolation/execution-sandboxing.mdx +++ b/docs/pages/devsecops/isolation/execution-sandboxing.mdx @@ -100,7 +100,7 @@ Build, sign, publish, and deploy should be distinct stages with explicit policy - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final - NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments + - Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ - Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html diff --git a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx index 8e039cd9..fd5ad271 100644 --- a/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx +++ b/docs/pages/devsecops/isolation/network-and-resource-isolation.mdx @@ -101,7 +101,7 @@ These controls are both security and reliability controls. - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final - NIST SP 800-53 Rev. 5 (network and resource control families): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments + - Kubernetes, *Network Policies*: https://kubernetes.io/docs/concepts/services-networking/network-policies/ - Kubernetes, *Resource Management for Pods and Containers*: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ diff --git a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx index 6226532b..8039a9f7 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-isolation.mdx @@ -97,12 +97,10 @@ At minimum, enforce the following: - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final - NIST SP 800-53 Rev. 5, *Security and Privacy Controls*: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth - Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html - Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview +- SLSA specification: https://slsa.dev/spec/v1.0/ --- diff --git a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx index 8f47b02d..a9613508 100644 --- a/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-and-policy-enforcement.mdx @@ -96,11 +96,10 @@ A practical stack for pipelines: - NIST SP 800-53 Rev. 5 (policy, audit, and access controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final - NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments -- CISA, *Defense in Depth*: https://www.cisa.gov/resources-tools/resources/defense-depth + - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/ - Kubernetes, *Admission Controllers*: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ -- SLSA specification: https://slsa.dev/spec/v1.0/overview +- SLSA specification: https://slsa.dev/spec/v1.0/ --- diff --git a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx index cf0ec013..d4ee9cf0 100644 --- a/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx +++ b/docs/pages/devsecops/isolation/sandboxing-for-tool-execution.mdx @@ -94,7 +94,7 @@ A secure flow is: - NIST SP 800-53 Rev. 5 (least privilege, audit, execution controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - NIST SP 800-190, *Application Container Security Guide*: https://csrc.nist.gov/pubs/sp/800/190/final -- CISA, *Defending Continuous Integration/Continuous Delivery (CI/CD) Environments*: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments + - Linux kernel documentation, *Seccomp BPF*: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html - Docker, *Docker Engine Security*: https://docs.docker.com/engine/security/ - Kubernetes, *Pod Security Standards*: https://kubernetes.io/docs/concepts/security/pod-security-standards/