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.

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.

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.

Trends

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

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.

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.

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

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.

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

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.

Destination Overview

The destinations table shows:

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

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

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.

Policies

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

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:

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:

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.

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.

Assignments

The Assignments tab controls where and how policies are applied, using a three-level hierarchy:

Organization Level

Set a default mode (Enforce or Audit) and policy for the entire organization. All repositories and workflows inherit these settings unless overridden.

Repository Level

Override the organization defaults for specific repositories. Each repository can have its own mode and policy assignment. The assignments page shows aggregate statistics: percentage of workflows in enforce mode, audit mode, and unspecified.

Workflow Level

Override repository settings for individual workflows. This gives you fine-grained control — for example, enforce mode on production deployment workflows while keeping new workflows in audit mode.

At each level you can:

• Select a mode: Inherit (from parent), Enforce, or Audit
• Assign a policy or policy group
• Enable or disable CargoWall for that entity

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:

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

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.

Using CargoWall in Your Workflows

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

- uses: code-cargo/cargowall-action@latest
  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

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

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.

Key Terminology

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

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.

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.

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.