Security Policies

Security Policies

Overview

Security policies define the runtime behavior permitted for your CI/CD pipelines and deployments. The Runtime Sensor enforces these policies at the kernel level using eBPF technology, intercepting and validating security-relevant operations before they execute.

What Are Security Policies?

A security policy is a JSON document that specifies:

  • Allowed operations: Which processes can execute, what files can be accessed, which network connections are permitted
  • Enforcement mode: Whether to observe, enforce, or derive policy rules
  • Security boundaries: Constraints on containers, kernel operations, memory access, and inter-process communication

Policies follow a deny-by-default model—operations not explicitly permitted are blocked when enforcement is enabled.

Key Concepts

Policy Domains

Security policies cover multiple security domains:

DomainDescriptionExamples
File SystemFile and directory operationsProcess execution, file reads/writes, path creation/deletion
NetworkingTCP/IP, Unix sockets, raw socketsOutbound connections, listening ports, packet sniffing
ContainersContainer runtime operationsImage execution, socket access
MemoryMemory-related operationsMemory mapping, W+X protection
ProcessProcess managementProcess termination, resource limits, scheduling
KernelKernel-level operationseBPF programs, kernel modules, direct memory access
IPCInter-process communicationUnix sockets, System V shared memory, message queues

Enforcement Modes

Policies operate in one of three modes:

ModeBehaviorUse Case
deriveMonitor all behavior and generate policy rulesInitial setup—run your pipeline to capture baseline behavior
observeLog violations without blocking operationsTesting and refinement—validate policy before enforcement
enforceBlock unauthorized operations and fail buildsProduction—active protection against policy violations

Rule Format

Most policy rules follow a pipe-delimited format that specifies actors and targets:

actor|target
actor|target|additional_context

For example, an IP connection rule:

/usr/bin/curl|api.example.com|443

This permits the curl binary to connect to api.example.com on port 443.

Wildcards and Patterns

Policies support several pattern matching features:

PatternDescriptionExample
allMatches any value"all" permits all values for that field
{a,b,c}Brace expansion{80,443} matches port 80 or 443
%workspace%Job workspace directory%workspace%/build/output for build artifacts

Policy Lifecycle

The recommended workflow for creating and deploying security policies:

1. Derive

Start with a policy in derive mode and run your pipeline:

{
    "mode": "derive"
}

After the build completes, the Runtime Sensor outputs a derived policy containing rules for all observed behavior.

2. Refine

Review the derived policy and refine it:

  • Consolidate paths using brace expansion
  • Remove overly specific rules for ephemeral files
  • Group similar operations where appropriate

3. Observe

Deploy the refined policy in observe mode:

{
    "mode": "observe"
}

Run several builds and review any violations in Team Server. Adjust the policy as needed.

4. Enforce

Once builds run cleanly in observe mode, switch to enforce:

{
    "mode": "enforce"
}

The Runtime Sensor now actively blocks unauthorized operations.

Policy Management

Security policies are managed through Team Server:

  • Create policies: Define policies using the built-in editor with JSON schema validation
  • Assign policies: Link policies to pipelines for enforcement
  • Monitor violations: View and investigate policy violations
  • Version history: Track policy changes with audit logging

To create a policy in Team Server:

  1. Navigate to Policies in the main menu
  2. Click Create
  3. Enter a Name, Description, and Version
  4. Write or paste your policy JSON
  5. Click Create

To assign a policy to a pipeline:

  1. Navigate to Policies
  2. Click the Assign Policy (link icon) for your policy
  3. Search and select the pipeline(s) to protect
  4. Click Assign

Next Steps