Review connections in a job summary
Find the table Bullfrog writes after a job finishes, and interpret what it says about each outbound connection.
Before you begin
- A completed run of a job that uses the Bullfrog GitHub Action
Step 1: Open the summary
- Open your repository's Actions tab and select the workflow run.
- Select Summary in the left sidebar.
- Scroll to the Bullfrog section for the job you care about.
Bullfrog writes one section per job. A workflow with three jobs running Bullfrog produces three sections on the same summary page.
The heading tells you whether the job reported to the Bullfrog platform. Bullfrog Results means it ran standalone. Bullfrog Control Plane, followed by a View detailed results link, means the job had an api-token and its results were submitted.
If the job made no outbound connections, the section reads No outbound connections detected. instead of a table.
Step 2: Read the status column
Every row carries one of three statuses:
| Status | Meaning |
|---|---|
| ✅ Authorized | The destination matched allowed-domains or allowed-ips, or a default the action permits. |
| ⚠️ Unauthorized | The destination matched nothing, and audit mode let it through anyway. |
| 🚫 Blocked | The destination matched nothing and block mode dropped it. |
Unauthorized rows are the ones to act on. In audit mode they're a preview of what block mode would drop. See Switch a job to block mode.
Step 3: Read the remaining columns
| Column | Contents |
|---|---|
| Timestamp | When the connection was attempted, in ISO 8601. |
| Domain | The hostname, when Bullfrog saw the name resolve. - when the step connected to an address directly. |
| IP | The destination address. |
| Port | The destination port. |
| Protocol | The transport or application protocol Bullfrog identified. |
| Reason | Why Bullfrog decided as it did. See the table below. |
| Status | Authorized, Unauthorized, or Blocked. |
| Process | The name of the process that opened the connection. |
| Container | image:name when the connection came from a container, otherwise -. |
| Exe Path | The full path to that process's executable. |
| Command Line | The arguments the process was invoked with. |
The Process, Exe Path, Command Line, and Container columns are populated only while collect-process-info is true, which is the default. With it set to false they read -.
Reason values:
| Reason | Meaning |
|---|---|
| Domain allowed | The hostname matched an entry in allowed-domains. |
| Domain not allowed | The hostname matched no entry in allowed-domains. |
| IP allowed | The address matched an entry in allowed-ips. |
| IP not allowed | The address matched no entry in allowed-ips. |
| Untrusted DNS server | The query went to a resolver that isn't in allowed-ips. |
| No network layer | The packet carried no network layer Bullfrog could inspect. |
| Unknown network layer | The packet's network layer wasn't one Bullfrog parses. |
Step 4: Find the process behind a connection
When a row surprises you, read Exe Path and Command Line together. They name the binary and the exact invocation, which usually identifies the step: a package manager fetching a dependency, a language toolchain phoning home for telemetry, or an action downloading a release asset.