Detections

Available for Enterprise Tier only

Harden-Runner can monitor outbound runtime detections to help you stay informed about security risks in your GitHub Actions workflows. You can review all past runtime detections on the Detections page under the Harden-Runner menu.

Harden-Runner detects compromised npm packages at runtime. For PR-level prevention, see NPM Supply Chain Security → Prevent

Types of Detections

The Detections page covers ten critical areas:

1. Secrets in Build Logs

2. Secrets in Artifacts

3. Outbound Calls Blocked

4. Anomalous Outbound Network Calls

5. Suspicious Outbound Network Calls

6. Source Code Overwritten

7. HTTPS Outbound Network Calls

8. Action Uses Imposter Commit

9. Suspicious Process Events

10. Agent Tampered

Each detection is linked to the relevant GitHub Actions workflow and run and includes direct links to the run and the insights URL that indicates where the detection happened.

Secrets in Build Logs

When it triggers: A line in the workflow's build log contains a value matching a known secret pattern (API keys, cloud credentials, OAuth tokens, and similar). Each detection includes a masked preview and a link to the offending log line.

Why it matters: Build logs are visible to anyone with read access to the workflow run, which on public repos includes external contributors. Anything written to a log is effectively permanent because logs and forks may be archived long after the secret is rotated. Tools like the Azure, AWS, and Google Cloud CLIs occasionally print credentials by accident, and catching these at runtime lets you rotate the value before it is harvested.

Secrets in Artifacts

When it triggers: An artifact uploaded by the workflow (via actions/upload-artifact or similar) contains an embedded value matching a known secret pattern.

Why it matters: Artifacts are downloadable by anyone with access to the workflow run and are often retained for weeks. A .env file, config bundle, or compiled binary that accidentally embeds a credential becomes a long-lived public exposure. Detecting it at publish time lets you delete the artifact and rotate the secret before it is downloaded.

Outbound Calls Blocked

When it triggers: A workflow running with egress-policy: block attempts to reach a destination that is not on its allowlist, and Harden-Runner blocks the call.

Why it matters: Egress blocks are the enforcement layer that stops exfiltration in real time, but reviewing them is what closes the loop. A legitimate block means the allowlist needs updating; a malicious block means the runner was actively compromised and the secrets it had access to should be rotated. Calls blocked specifically because they hit a Global Block List IOC are labeled Attack Blocked so you can tell them apart from routine policy blocks.

Anomalous Outbound Network Calls

When it triggers: A workflow contacts a destination that is new or unusual relative to the baseline Harden-Runner has built for that workflow's outbound traffic. The baseline must be stable; runs against an unstable or still-forming baseline do not generate this alert.

Why it matters: Most CI/CD supply chain attacks rely on exfiltrating data to a previously-unseen attacker domain. Baseline comparison catches that first-time call even when the workflow is running in audit mode. This is the detection that surfaced the tj-actions/changed-files compromise (CVE-2025-30066).

Suspicious Outbound Network Calls

When it triggers: A workflow contacts a domain or IP that StepSecurity's 24×7 SOC has identified as an indicator of compromise (IOC) and added to the Global Block List. The call is blocked automatically, even in audit mode.

Why it matters: Anomalous-call detection needs a baseline; suspicious-call detection does not. As soon as StepSecurity confirms an IOC during an active investigation, every protected workflow gains protection without a config change or an action version bump. The pgserve npm compromise was blocked this way in real time. Allowlisting an IOC in your own policy does not override the Global Block List, so a compromised action cannot grant itself access to known-malicious infrastructure.

HTTPS Outbound Network Calls

When it triggers: Every HTTPS request a workflow makes is logged with its HTTP method, host, and path. Unlike the other detections on this page, this surface is populated continuously rather than triggered by an anomaly.

Why it matters: Network-layer logs only show that the runner contacted api.github.com. HTTPS-level visibility shows what it did there: which APIs were called, which repos were touched, which content was uploaded. That is what surfaces abuse of GITHUB_TOKEN itself, for example a compromised action creating issues, pushing branches, or copying repository content to an attacker-controlled fork. It is also the data Harden-Runner uses to recommend minimum GITHUB_TOKEN permissions for each job.

Source Code Overwritten

When it triggers: A file inside the checked-out source tree is modified during the build. Harden-Runner records the modifying executable and the syscall details, using the Linux Audit Framework on Ubuntu runners.

Why it matters: Source-code tampering during the build is the SolarWinds and XZ Utils attack class: a backdoor is injected at compile time so the source on disk and the binary that ships no longer match. Branch protection, code review, and code signing all run before or after the build, so none of them can catch this. File-write monitoring is what closes that gap. Infrastructure-as-code files (Terraform, Kubernetes manifests, and so on) are monitored alongside application source for the same reason.

Action Uses Imposter Commit

When it triggers: A workflow references a GitHub Action by a tag or commit SHA that does not exist on the action repository's default branch. The pinned commit lives outside the action's normal release history, often in a fork.

Why it matters: Updating a tag to point at a commit outside the default branch is a known supply-chain attack pattern, used in the tj-actions and reviewdog incidents. Because the malicious commit never lands on the default branch, it bypasses PR review entirely, which is what makes the attack easy to miss. Some legitimate actions also trigger this signal: projects that build release artifacts on a short-lived branch and then delete it after tagging produce the same warning sign without anything malicious happening. Triage each detection before treating it as an attack.

Suspicious Process Events

Harden-Runner monitors process activity on the runner and flags behaviors that match known supply-chain attack techniques. Three subtypes are surfaced today: Privileged Container, Reverse Shell, and Runner.Worker Memory Read. Each is a high-confidence signal, and each can be configured to terminate the affected job automatically via Lockdown Mode.

Privileged Container

When it triggers: A workflow launches a privileged container, for example via docker run --privileged, by mounting the host filesystem into a container, or by starting a container directly through the Docker or containerd socket.

Why it matters: Privileged containers can break out of container isolation and gain root on the runner host.

Reverse Shell

When it triggers: A process spawned during the workflow combines a shell with an outbound network connection in a way that suggests an interactive shell is being proxied to a remote host. Two patterns are flagged: a nc, ncat, or netcat invocation that pairs -e with bash or /bin/bash, and a bash or sh invocation whose arguments reference /dev/tcp/<host>/<port> where the host is not a loopback address.

Why it matters: A reverse shell gives an attacker live, interactive control of the runner. From that position they can read the workflow's environment (including GITHUB_TOKEN and injected secrets), exfiltrate source code and build artifacts, and pivot to other systems reachable from the runner.

Runner.Worker Memory Read

When it triggers: Another process on the runner reads the memory of the GitHub Actions Runner.Worker process, typically via /proc/<pid>/mem or ptrace on Linux, or ReadProcessMemory on Windows.

Why it matters: GitHub Actions secrets are decrypted into the Runner.Worker process at job runtime. Anything that can read that memory can extract those secrets in plaintext, regardless of how they are masked in logs. This is the technique used in the tj-actions/changed-files compromise (CVE-2025-30066). Legitimate workflows have no reason to read this memory, so the signal has a very low false-positive rate.

Agent Tampered

Detects when the Harden-Runner agent has been tampered with during workflow execution.

How to Suppress a Detection

Suppressing a detection hides it from your active list without marking it as fixed. Use suppression when the detection is a false positive, not relevant, or represents an acceptable risk. Suppressed detections remain available under the “Suppressed” tab for future review, and can be unsuppressed if needed

Step 1: Click the three dots next to the item you want to suppress, then select “Suppress Detection.”

Step 2: Select a reason for suppressing the detection.

Step 3: Click "Suppress"

Step 4: Go to the “Suppressed” tab to view all suppressed detections

How to Resolve a Detection

Resolving a detection indicates that you have addressed the underlying issue. Use this option after taking corrective action, such as updating a workflow, fixing a configuration, or applying a patch. Resolved detections move out of the active list but remain in the system for audit and traceability.

Step 1: Click the three dots next to the item you want to resolve, then select “Resolve Detection.”

Step 2: Give a reason for resolving the detection.

Step 3: Click "Resolve"

Step 4: Go to the “Resolved” tab to view all resolved detections

Real-Time Security Alerts

StepSecurity delivers real-time alerts for runtime detections, ensuring you stay informed about potential security threats as they happen.

To minimize alert fatigue, notifications are sent only once per event, covering all repositories in your GitHub organization. This approach maintains visibility into security events without overwhelming your team.

Follow the instructions in Notification Settings to configure your alerts.