CodeCargo logo

Core Concepts

CargoWall

What is CargoWall?

CargoWall is CodeCargo's eBPF-based Layer 4 firewall that controls network egress from your GitHub Actions workflow runs. It monitors and enforces network access policies on every outbound connection made during workflow execution, helping prevent data exfiltration and ensuring workflows only communicate with approved destinations.

Plan Availability

CargoWall audit mode is included on all plans. Enforce mode, custom network policies, baselines, and advanced firewall features require a Team or Enterprise plan. See pricing for details.

Key Capabilities

  • Enforce Mode: Block unauthorized outbound connections in real time
  • Audit Mode: Monitor and log all network activity without blocking — ideal for rollout and assessment
  • Policy-Based Rules: Define allowed destinations by hostname, IP address, subnet, or port
  • Workflow Visualization: View security overlays on workflow run graphs showing per-job and per-step network activity
  • Multi-Level Assignment: Apply policies at the organization, repository, or individual workflow level

Overview Dashboard

The CargoWall hub is accessible from the organization sidebar under CargoWall. The landing page provides five switchable dashboard views, each with summary statistics and trend charts. Use the period selector (30, 60, or 90 days) to adjust the reporting window.

CargoWall overview dashboard

Enforcement

The default view focuses on policy enforcement outcomes:

  • Denied Connections — connections blocked by enforce-mode policies
  • Denial Rate (%) — percentage of total connections that were denied
  • Allowed Connections — connections that matched an allow rule
  • Runs Impacted — workflow runs where at least one connection was denied

Charts display Connections Over Time (allowed, denied, and would-deny trends) and Denial Rate Over Time. A Top Denied Destinations card shows the most frequently blocked hostnames.

  • Auto-Allowed Connections — connections that matched default allowed host rules

Coverage

Shows how broadly CargoWall is deployed across your workflows:

  • Enforcement Coverage (%) — workflows running in enforce mode
  • Audit Coverage (%) — workflows running in audit mode
  • Unprotected Workflows — workflows with no CargoWall policy assigned
  • Policy Assignment (%) — repositories with at least one policy
  • Active Policies — total active policies in the organization

Activity

A general traffic overview for the selected period:

  • Total Runs — workflow runs analyzed

  • Total Connections — outbound network connections observed

  • Unique Destinations — distinct hostnames contacted

  • New Destinations — hostnames seen for the first time in this period

  • Connections per Run — average outbound connections per workflow run

  • Auto-Allowed Connections — connections permitted by default allowed host rules

Audit Readiness

Helps you evaluate the impact of switching audit-mode policies to enforce:

  • Would-Deny Connections — connections that would be blocked if audit switched to enforce
  • Would-Deny Rate (%) — percentage of audit connections that would be blocked
  • Projected Impact — additional connections blocked if all audit policies moved to enforce

A High-Risk Audit Workflows table lists workflows ranked by would-deny count so you can prioritize enforce rollout.

Longer-term trend charts for Denial Rate, Enforcement Coverage, New Destinations, and Would-Block counts over time. Useful for tracking security posture improvements.


Time Range Filtering

The CargoWall dashboard includes time range controls that respect your organization's data retention settings:

  • Period Selector: Choose from 30, 60, or 90-day reporting windows
  • Retention Limits: Available time ranges are automatically filtered based on your plan's CargoWall log retention entitlements
  • Smart Defaults: When retention limits apply, the maximum available period is highlighted as the default selection

The time range selector appears throughout CargoWall views including the overview dashboard, activity pages, and run analysis screens.

Data Retention

Time range options are limited by your organization's CargoWall log retention entitlements. Higher-tier plans include longer retention periods for historical analysis.

Runs

The Runs tab lists all workflow runs that CargoWall has analyzed. You can filter by repository, workflow name, actor (GitHub user), and time range, and sort by any column.

CargoWall runs list

Run Detail

Click a run to open the detail view, which has two tabs:

Jobs Tab

  • Left sidebar: lists each job in the run with a status icon
  • Main panel: shows the selected job's network events

For each job you see summary stats — Destinations, Allowed, Denied (or Would Deny in audit mode), and Total connections. An events table lists every outbound connection with columns for Step, Process, Destination, Port, Status, and Timestamp. Use the search bar or "Show denied only" toggle to focus on policy violations.

CargoWall run detail with events

Visualizer Tab

A React Flow–based graph renders the workflow structure with a security overlay:

  • API-Driven Expansion: Matrix jobs are expanded using actual run data from the GitHub API, showing the exact job variants that executed
  • Security Indicators: Each job and step node displays network activity badges and policy enforcement status
  • Security Panel: Click any job or step to open a side panel showing its network events, unique destinations, and allow/deny breakdown
Workflow visualizer with CargoWall security overlay

Public Run Pages

CargoWall supports viewing workflow runs from public GitHub repositories that don't have a linked CodeCargo organization. These public run pages are accessible at:

/cargowall/github/{orgAlias}/{repoName}/actions/runs/{runId}

Public run pages provide the same detailed analysis as organization runs, including:

  • Job-level network event analysis
  • Workflow visualization with security overlays
  • Connection status and policy evaluation results
  • Step-by-step network activity breakdown

Public repositories are allowed to report CargoWall data when their repository_visibility is set to "public", even without a linked organization. This enables open-source projects and public repositories to benefit from CargoWall's network security analysis. Run data is stored for 7 days for organizations that don't have a linked CodeCargo organization.

Public Repository Access

Public run pages are only available for repositories with public visibility. Private repositories require a linked CodeCargo organization to view CargoWall analysis.

IP-Only Destinations

CargoWall automatically handles network connections that don't resolve to hostnames. When workflows connect directly to IP addresses (such as internal services or infrastructure endpoints), these appear in the destinations list using the IP address as the identifier.

IP-only destinations are treated the same as hostname destinations in all CargoWall features:

  • Policy matching: IP addresses can be matched against CIDR rules in your policies
  • Filtering and search: You can search for specific IP addresses in the destination views
  • Run analysis: IP connections appear in job and step network events alongside hostname connections
  • Visualization: IP addresses display in the workflow visualizer security overlay

IP Address Display

When a connection has no hostname, CargoWall displays the raw IP address (e.g., 192.168.1.100) in all destination lists and network event tables. This helps you identify direct IP connections that may need policy coverage.

Destinations

The Destinations tab provides a comprehensive view of all network destinations contacted by your workflows. This view helps you understand your organization's network traffic patterns and manage policy coverage.

CargoWall destinations list

Destination Overview

The destinations table shows:

ColumnDescription
DestinationHostname or IP address contacted by workflows
ConnectionsBreakdown of allowed (green), denied (red), and would-deny (yellow) connections
Applied PoliciesPolicy badges showing which policies match this destination
RunsNumber of workflow runs that contacted this destination
Last SeenWhen this destination was last contacted

Filtering Destinations

Use the filter controls to focus on specific destinations:

  • Action Filter: Show all destinations, or filter by "Would Deny", "Denied", or "Allowed" status
  • Hostname Search: Search for specific hostnames or IP addresses
  • Time Range: Filter destinations by when they were first or last seen

Auto-Allowed Filter

Use the Auto-Allowed Filter to control visibility of connections that were automatically allowed by default host filtering:

  • All: Show all destinations regardless of auto-allowed status
  • Only: Show only destinations that were auto-allowed
  • Exclude: Hide destinations that were auto-allowed

Auto-allowed connections are those that matched default allowed hosts configured in your CargoWall policies, helping you distinguish between explicitly allowed destinations and those permitted by default rules.

Adding Destinations to Policies

For destinations that need policy coverage, you can quickly add them to existing policies or create new ones:

  1. Click the Add to Policy button next to any destination
  2. Choose to add to an existing policy or create a new one
  3. Optionally specify port restrictions for the rule
  4. The destination is automatically added as an allow rule

IP Address Handling

Destinations that are IP addresses (rather than hostnames) are automatically handled with CIDR notation when added to policies. IPv4 addresses are converted to /32 CIDR blocks for precise matching.

Auto-Allowed Events

The Add to Policy button only appears for workflow runs that contain events requiring explicit policy rules. Runs with only auto-allowed connections (those permitted by default host filtering) do not show this button since no additional policy configuration is needed.

Editing Destination Hostnames

When adding a destination to a policy, you can modify the hostname before creating the rule. This is useful when you want to create a more general rule or correct the destination value:

  1. In the Add to Policy dialog, click the pencil icon next to the destination hostname
  2. Edit the hostname in the input field that appears
  3. Press Enter to confirm your changes or Escape to cancel
  4. The policy rule will be created using your modified hostname instead of the original

This feature allows you to:

  • Generalize specific hostnames (e.g., change api-v2.example.com to *.example.com)
  • Correct misidentified hostnames
  • Create broader rules that cover multiple related destinations

Rule Validation

The modified hostname is validated when creating the policy rule. IP addresses are automatically converted to CIDR notation (/32 for IPv4) when added to policies.

Destination Detail

Click on any destination to view detailed information including:

  • Connection history and patterns
  • Which workflows and jobs contacted this destination
  • Current policy coverage status
  • Recommended policy actions

Repository and Workflow CargoWall Views

CargoWall provides dedicated views for individual repositories and workflows, accessible from their respective detail pages. These focused views offer the same CargoWall functionality but scoped to a specific context.

Repository CargoWall

Access repository-specific CargoWall data by navigating to a repository and clicking the CargoWall tab. This view includes:

  • Runs — workflow runs from this repository only
  • Policy Assignment — policies applied to workflows in this repository
  • Baselines — network baselines specific to this repository

The view uses a tabbed interface to switch between these three sections, with the repository context automatically filtering all data.

Workflow CargoWall

Access workflow-specific CargoWall data by navigating to a repository, clicking on the CargoWall tab, and then clicking on an individual workflow. This view includes:

  • Runs — executions of this specific workflow only
  • Policy Assignment — policies applied to this workflow and its jobs
  • Baselines — network baselines for this workflow's execution patterns

The workflow view provides the most granular CargoWall analysis, showing exactly how network policies affect a single workflow's behavior.

Consistent Interface

Repository and workflow CargoWall views use the same tabbed interface as the organization-level CargoWall dashboard, ensuring a consistent experience across all levels of analysis.

Policies

Policies define which network destinations are allowed during workflow execution. Any connection that does not match a rule is denied by default.

CargoWall policy list with rules

Creating a Policy

  1. Click Create Policy on the Policies tab
  2. Enter a policy name
  3. Add rules to the policy

Policy Rules

Each rule specifies an allowed destination using one of these types:

Rule TypeDescriptionExample
HostnameDomain match (subdomains automatically included)github.com (also allows *.github.com)
IPSpecific IP address192.168.1.100
SubnetCIDR range10.0.0.0/8
PortOptional port restriction per rule443, 8080

Rules define allow actions. The implicit default is deny all — connections that don't match any rule are blocked (in enforce mode) or flagged (in audit mode).

Port Protocol Specification

When adding port restrictions to rules, you can specify the protocol for more granular control:

ProtocolDescriptionExample Use Case
AllBoth TCP and UDP traffic (default)General web services
TCPTCP traffic onlyHTTP/HTTPS, database connections
UDPUDP traffic onlyDNS queries, streaming protocols
ICMPICMP traffic onlyNetwork diagnostics, ping tests

This allows you to create more precise rules, such as allowing DNS queries on port 53 UDP while blocking TCP connections to the same port.

ICMP Port Restrictions

ICMP rules must use port 0 since ICMP is a network layer protocol that doesn't use traditional port numbers. Non-zero ports are invalid for ICMP rules.

Policy Groups

You can group multiple policies together into a Policy Group for easier bulk assignment. Create a group, then add one or more policies to it. Policy groups can be assigned to repositories or workflows just like individual policies.


Default Policies

CargoWall supports default policies that are automatically created and managed for each entity in your hierarchy. Default policies provide baseline network rules without requiring manual policy creation.

Creating Default Policies

  1. Navigate to CargoWall → Policies
  2. Click Get or Create Default Policy
  3. Select the entity type (Organization, Repository, Workflow, or Workflow Job)
  4. Choose the specific entity
  5. The system creates a default policy if one doesn't exist

Default policies are automatically linked to their owning entity and inherit through the hierarchy.

Policy Inheritance Chain

CargoWall policies follow a hierarchical inheritance model:

  • Organization Level — base policies that apply to all repositories and workflows
  • Repository Level — overrides organization settings for specific repositories
  • Workflow Level — overrides repository settings for individual workflows
  • Workflow Job Level — most specific level, overrides all parent settings

Each level can have both a default policy (automatically managed) and assigned policies (manually configured). Child entities inherit settings from their parents unless explicitly overridden.

Viewing Policy Chains

Use the Get Entity Policy Chain feature to see the complete inheritance hierarchy for any workflow or job:

  1. Navigate to a specific workflow or job
  2. Click View Policy Chain
  3. Review the inheritance from organization → repository → workflow → job
  4. See which policies are active at each level
  5. Identify where inheritance is overridden

This helps you understand exactly which policies will be applied during workflow execution.

Baselines

CargoWall baselines automatically learn and manage expected network traffic patterns for your workflows. Instead of manually creating policies for every destination, baselines observe your workflow behavior and establish approved connection patterns that can be enforced or used as templates for new policies.

How Baselines Work

Baselines operate in three phases:

  1. Learning Phase - Baselines start in learning mode, observing network connections from workflow runs and building a profile of expected destinations
  2. Stable Phase - After collecting sufficient data (configurable run count), baselines transition to stable status with a complete traffic profile
  3. Enforcement - Stable baselines can be converted to enforcement policies or used as templates for manual policy creation

Baseline Types

CargoWall creates baselines at three levels of granularity:

TypeScopeDescription
RepositoryAll workflows in a repositoryLearns traffic patterns across all workflows in the repository
WorkflowSingle workflow fileLearns patterns specific to one workflow across all its jobs
Workflow JobIndividual job within a workflowLearns patterns for a specific job within a workflow

Automatic Baseline Creation

CargoWall automatically creates learning baselines when workflows run:

  • Repository baselines are created when any workflow in the repository executes
  • Workflow baselines are created when a specific workflow runs
  • Job baselines are created for individual jobs within workflows
  • All baselines start in learning mode with a default target of observing multiple runs
  • Baselines automatically transition to stable when they have adequate coverage

Managing Baselines

Access baseline management from the Baselines tab in the CargoWall section:

  • View all baselines across your organization with status indicators
  • Filter by entity type (Repository, Workflow, or Job) and status (Learning or Stable)
  • Convert baselines to policies when you're ready to enforce the learned patterns
  • Recompute baselines to refresh the learned traffic patterns with recent data
  • Manual baseline creation from historical workflow run data

Baseline Status

StatusDescription
LearningActively observing workflow runs and building traffic patterns
StableHas observed sufficient runs and established a complete traffic profile

Managing Baseline Actions

Baselines include management actions accessible through dropdown menus on each baseline entry. Available actions depend on your permissions and the baseline's current status:

ActionDescriptionRequirements
RenameChange the baseline nameUpdate permissions
RecomputeRecalculate baseline using recent runsRecompute permissions
Convert to PolicyCreate enforcement policy from stable baselineConvert permissions, stable status
DeleteRemove the baseline permanentlyDelete permissions

Actions are contextually shown based on baseline status and your role permissions. For example, the "Convert to Policy" option only appears for baselines in stable status.

Baseline Recompute

You can recompute baselines to refresh their learned traffic patterns using recent workflow run data:

  1. Click the Recompute action from a baseline's dropdown menu
  2. Specify the number of recent runs to analyze
  3. Review the recompute settings and confirm
  4. The baseline updates with new traffic patterns based on the selected runs

Recomputing is useful when workflow network requirements change or when you want to incorporate recent traffic patterns into an existing baseline.

Converting to Policies

Stable baselines can be converted into enforcement policies:

  1. Select a stable baseline from the baselines list
  2. Click Convert to Policy
  3. Review the learned destinations and rules
  4. Optionally modify the policy before creation
  5. Assign the new policy to repositories or workflows

This workflow allows you to move from observation to enforcement with confidence that your policies reflect actual workflow needs.

Learning Period

Baselines require multiple workflow runs to establish reliable patterns. The learning period ensures policies are based on comprehensive traffic analysis rather than single-run observations.

Key Terminology

TermMeaning
EnforceDenied connections are blocked in real time
AuditDenied connections are logged but not blocked (test/assessment mode)
Would DenyConnections flagged in audit mode that would be blocked under enforce
CoveragePercentage of workflows with a CargoWall policy assigned
Denial RatePercentage of all observed connections that were denied
PolicyA set of allow rules; unmatched traffic is denied by default
Policy GroupA collection of policies for bulk assignment

Using CargoWall in Your Workflows

To integrate CargoWall into your GitHub Actions workflows, add the CargoWall action:

- uses: code-cargo/cargowall-action@v1.0.0
  with:
    mode: enforce
    api-url: https://app.codecargo.com

Configuration options:

  • mode: enforce to block unauthorized connections, or audit to monitor without blocking
  • api-url: CodeCargo API endpoint for policy management
  • allowed-hosts (optional): Comma-separated list of permitted domains for inline policy — only needed if you are not using a SaaS-managed policy

Action Repository

The CargoWall GitHub Action is maintained in the code-cargo/cargowall-action repository. Use @v1.0.0 or @latest for the most up-to-date stable version.


Organization Linking Requirement

CargoWall requires your repository to be linked to a CodeCargo organization to receive SaaS-managed policies. If your repository is not linked to an organization:

  • The CargoWall action will return a 404 error when attempting to fetch policies
  • The action will fall back to using local configuration (action inputs or environment variables)
  • You can still use CargoWall with inline policies by specifying allowed-hosts in your workflow

Repository Linking

To use SaaS-managed CargoWall policies, ensure your repository is connected to a CodeCargo organization through the GitHub App installation.

CargoWall Checks

CargoWall can automatically create GitHub PR checks that report on network policy violations during workflow execution. When enabled, CargoWall analyzes workflow runs and creates check runs that:

  • Show ❌ (failure) status when denied connections are detected
  • Show ✅ (success) status when no policy violations occur
  • Link back to the CargoWall run details page for full analysis
  • Appear directly on pull requests alongside other status checks

This integration provides immediate feedback to developers about network policy compliance without requiring them to navigate to the CargoWall interface.

Enabling CargoWall Checks

CargoWall checks can be configured at the organization and repository levels:

  • Organization setting: Controls the default check behavior for all repositories
  • Repository override: Allows individual repositories to override the organization default
  • Options: Enabled, Disabled, or Inherit (from parent level)

When enabled, checks are automatically created for workflow runs that include CargoWall analysis, providing seamless integration with your existing PR review process.

Check Details

CargoWall checks include a details URL that links directly to the workflow run's CargoWall analysis page, making it easy to investigate policy violations and understand network activity patterns.

Workflow Run URLs

When the CargoWall action completes, it returns a workflow run URL that links directly to the appropriate CargoWall interface:

  • Private repositories: Links to the organization's CargoWall activity page for the specific run
  • Public repositories: Links to the public CargoWall view for GitHub repository runs

This URL can be used in subsequent workflow steps or displayed in job summaries to provide quick access to CargoWall analysis and network activity details.

Run URL Access

The workflow run URL respects repository visibility settings and provides the most appropriate CargoWall interface for viewing network analysis results.

Installing CargoWall Action

CodeCargo can automatically install the CargoWall action in your workflows that don't currently have network protection. This feature helps you quickly add CargoWall to existing workflows without manual editing.

Automatic Installation

  1. Navigate to CargoWall → Activity in your organization
  2. Click Install CargoWall Action to see workflows without CargoWall protection
  3. Select the workflows where you want to add CargoWall
  4. Choose your target version and configuration options
  5. Click Install to create pull requests with the CargoWall action added

The installation process:

  • Automatically detects workflows that don't reference the CargoWall action
  • Adds the action to appropriate jobs in your workflow
  • Creates pull requests for review before merging changes
  • Preserves your existing workflow structure and configuration

Workflow Detection

Only workflows on the default branch that don't already reference code-cargo/cargowall-action are shown as candidates for installation.

Mode Change Tracking

CargoWall automatically tracks when enforcement modes change across your organization hierarchy. This tracking provides visibility into policy evolution and supports audit reporting.

Change Attribution

When organization administrators modify CargoWall modes (switching between Audit and Enforce), the system records:

  • Who made the change — the organization user who updated the mode
  • When it occurred — timestamp of the mode change
  • What changed — old mode and new mode values
  • Cascade effects — automatic mode changes to inheriting child entities

Audit Timeline

Mode changes create an audit trail that helps you understand:

  • How long entities spent in audit mode before enforcement
  • Which users are making policy changes
  • The progression from audit to enforce across your organization

Inheritance Tracking

When you change a mode at the organization or repository level, CargoWall automatically logs cascading changes to all inheriting child entities (those with "Unspecified" mode). This provides complete visibility into policy propagation.

Mean Time in Audit

The audit readiness dashboard includes a "Mean Time in Audit" metric that calculates the average time entities spend in audit mode before transitioning to enforce. This metric:

  • Helps you understand rollout velocity
  • Identifies entities that may need additional audit time
  • Supports compliance reporting on policy maturation

The calculation uses mode change events to track audit periods and provides organization-wide averages for planning future policy rollouts.

CargoWall Repository

CargoWall is maintained as a separate open-source project at github.com/code-cargo/cargowall. The CargoWall components are distributed as:

  • Go modules for integration with other Go applications
  • Container images for deployment in Kubernetes environments
  • GitHub Action for workflow integration

This separation allows CargoWall to be used independently of the CodeCargo platform while maintaining tight integration when used together.

Independent Usage

While CargoWall integrates seamlessly with CodeCargo for policy management and visualization, it can also be used as a standalone eBPF firewall solution in other environments.

Public CargoWall Interface

For public repositories, CargoWall provides a public interface that allows anyone to view workflow run network analysis without requiring authentication. This public view includes:

  • Complete workflow run details and network events
  • Job-by-job breakdown of network connections
  • Policy enforcement status and connection outcomes
  • Workflow visualizer with security overlay

The public interface respects repository visibility settings — only runs from public repositories are accessible through the public CargoWall view. Private repository runs require authentication and organization membership.

Public Access

Public CargoWall runs are accessible to anyone with the direct URL, making it easy to share network analysis results for open source projects and public workflows.

IP-Only Destinations

CargoWall automatically handles network connections that don't resolve to hostnames. When workflows connect directly to IP addresses (such as internal services or infrastructure endpoints), these appear in the destinations list using the IP address as the identifier.

IP-only destinations are treated the same as hostname destinations in all CargoWall features:

  • Policy matching: IP addresses can be matched against CIDR rules in your policies
  • Filtering and search: You can search for specific IP addresses in the destination views
  • Run analysis: IP connections appear in job and step network events alongside hostname connections
  • Visualization: IP addresses display in the workflow visualizer security overlay

Sudo Lockdown

Policies can include sudo lockdown configuration to restrict privileged command execution within workflows:

  • Enabled: When enabled, workflows can only execute sudo commands that are explicitly allowed
  • Allow Commands: Specify full paths to commands that are permitted (e.g., /usr/bin/apt-get, /bin/systemctl)

Sudo lockdown settings are inherited and merged across the policy hierarchy — if any level enables sudo lockdown, it remains enabled, and allow commands accumulate from all levels.

Command Paths

Allow commands must specify full paths to executables. Relative paths or command names without paths are not permitted for security reasons.


Policy Assignments

Policy assignments control where and how policies are applied across your organization. CargoWall uses a simplified assignment model where multiple policies can be assigned to any entity.

Assignment Levels

Policies can be assigned at four levels:

Organization Level

Set default policies for your entire organization. All repositories and workflows inherit these assignments unless overridden at a lower level.

Repository Level

Assign policies to specific repositories. Repository assignments override organization defaults and apply to all workflows in the repository.

Workflow Level

Assign policies to individual workflows within a repository. Workflow assignments override both organization and repository settings.

Workflow Job Level

Assign policies to specific jobs within a workflow. Job-level assignments provide the most granular control and override all parent assignments.

Multiple Policy Assignment

Unlike the previous model, you can now assign multiple policies to the same entity:

  • Additive Rules — rules from all assigned policies are combined
  • Default Actions — the most restrictive default action takes precedence
  • Policy Precedence — explicitly assigned policies take precedence over default policies

Managing Assignments

Assign policies through the entity-specific CargoWall pages:

  1. Navigate to the organization, repository, or workflow CargoWall view
  2. Go to the Policy Assignment tab
  3. Click Assign Policy to add policies
  4. Select from available policies or policy groups
  5. Configure enforcement mode (Inherit, Enforce, or Audit)

Assignments show the complete policy chain and inheritance relationships for easy troubleshooting.

Previous
Workflow Compliance
CargoWall - Docs