Workflow Runs
Last updated
Was this helpful?
Last updated
Was this helpful?
The Workflow Run Details page provides an in-depth view of each CI/CD job execution, including network activity, file modifications, and security detections. It highlights key security metrics, outbound destinations, and policy recommendations, helping you monitor and secure your workflows effectively.
Empty/No Tag: No detections were found; Harden-Runner is functioning as expected.
Harden-Runner Not Enabled: Harden-Runner is not active in your workflow.
Overwritten File: A file in the workflow has been overwritten.
Jobs Without Harden-Runner: At least one job in the workflow lacks Harden-Runner coverage.
Blocked Call: An endpoint has been blocked.
New Endpoint: A network call deviated from the baseline, indicating potential anomalies.
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
✅
❌
✅
❌
✅
❌
✅
❌
✅
Harden-Runner monitors all outbound traffic from each job at the DNS and network layers
After the workflow completes, each outbound call is correlated with each step of the job, and shown in the insights page
For self-hosted runners, no changes are needed to workflow files to monitor egress traffic
A filtering (block) egress policy is suggested in the insights page based on the current and past job runs
To access this feature switch to the Network Events tab on your Insights page
For the Enterprise Tier, the PID is available, and you can click on it to view the process arguments
You can detect suspicious/ anomalous traffic using this feature even in egress-policy:audit mode.
To access this feature switch to the Recommendations tab on your Insights page
Anomaly detection feature creates a machine learning model of outbound network calls by analyzing the historical data of the same workflow in previous runs
Once the baseline is established, any anomalous outbound destinations are flagged on the insights page, triggering real-time alerts
You can view the list of all anomalous outbound network traffic in the All Detections page on the dashboard
You can see recommended egress block policy in the Recommendations tab for each job. This is based on observed traffic across multiple runs of the job.
Harden-Runner blocks egress traffic at the DNS (Layer 7) and network layers (Layers 3 and 4)
It blocks DNS exfiltration, where attacker tries to send data out using DNS resolution
Wildcard domains are supported, e.g. you can add *.data.mcr.microsoft.com:443 to the allowed list, and egress traffic will be allowed to eastus.data.mcr.microsoft.com:443 and westus.data.mcr.microsoft.com:443
Harden Runner sends telemetry related to egress traffic to the StepSecurity API, e.g.
Domain names resolved,
IP addresses called, and
Processes that made these calls
When you use egress-policy: block mode, and if you do not want this telemetry to be sent anymore, you can set disable-telemetry: true.
When this is done, telemetry will no longer be sent to StepSecurity API.
Here is an example of how to use disable-telemetry: true
Harden-Runner monitors file writes and detects if any source code files are overwritten during a build.
Source code overwrites are unexpected in a release build.
All source code files are monitored, including infrastructure-as-code (IaC) files such as Kubernetes manifests and Terraform configurations.
Notifications can be enabled to receive alerts when source code modifications occur.
No additional changes are needed for self-hosted runners to enable file monitoring.
Step 1: Access the Workflow Runs
Navigate to Latest Workflow Runs under the Harden-Runner menu in your StepSecurity dashboard. If any files were overwritten, you’ll see an alert similar to this:
Step 2: View File Write Events
Click on the workflow insights
Go to the File Write Events tab
You’ll see a list of overwritten files, including their paths and timestamps.
Enterprise-tier users get additional details such as:
The process that wrote to the file.
The arguments passed during the write operation.
Step 3: Investigate the Overwrite
Identify the file and its path.
Review the detection timestamp for when the overwrite occurred.
If unexpected, trigger a security review or rollback to a safe commit.
GitHub-hosted runner uses passwordless sudo for running jobs.
This means compromised build tools or dependencies can install attack tools
When you set disable-sudo-and-containers to true, the job steps run without sudo access to the GitHub-hosted Ubuntu VM. You can only use this option if you do not use docker in your job. If a job attempts to use the sudo command, the CI will fail.
Here is an example of how to use this option:
To assess the stability of a job’s network behavior, you can use the Baseline feature under the Network Events tab.
Navigate to the Network Events tab, then click on Baseline to view the job-level baseline status.
The baseline status indicates whether a job is making predictable or unpredictable network calls. This is crucial for determining the reliability of detections from that job.
Stable Jobs: If a job is stable, it consistently makes predictable network calls. In such cases, detections should be investigated promptly, and GitHub checks should be enabled.
Unstable Jobs: If a job is unstable, it may generate noisy alerts due to unpredictable network activity. This can lead to frequent false positives. To address this, create suppression rules for specific endpoints that consistently trigger alerts or disable detections from the job altogether
Each job can be in one of the following baseline states:
Creating – The system is still collecting data to determine the job’s baseline behavior.
Stable – The job’s network activity is predictable and consistent.
Unstable – The job’s network activity is erratic and prone to triggering frequent alerts.
Available for Enterprise Tier Users only
This feature provides visibility into outbound GitHub API calls made during a job execution. It logs details such as HTTP methods and request paths, helping detect any unauthorized data exfiltration attempts through GitHub.com .
Clicking on any Destination in the Network Events tab reveals detailed information about the process that initiated the event, along with its process arguments.
This allows you to:
Identify which processes are making outbound requests.
Inspect HTTP methods and API endpoints used.
Monitor network activity for potential security concerns.
For example, in the screenshot below, clicking on ghcr.io under the Destination column reveals detailed API call logs, including HTTP methods such as GET, POST, HEAD, PATCH, and PUT. This visibility helps track and analyze API interactions effectively.
Available for Enterprise Tier users only
Harden-Runner monitors outbound HTTPS requests using eBPF and uses the PATHs and VERBs of these HTTPS calls to recommend the minimum GITHUB_TOKEN permissions for each job in your workflow.
GITHUB_TOKEN is an automatically generated secret used to authenticate to GitHub APIs from GitHub Actions workflows.
Harden-Runner can monitor the VERBs (e.g., GET, POST) and PATHs (e.g., /repos/owner/repo/issues) for calls made to the GitHub APIs from the runner.
Each GitHub Actions API call requires a corresponding GITHUB_TOKEN permission. For instance, a GET request to the /repos/org/repo/info/refs?service=git-upload-pack endpoint requires the contents: read permission.
The recommendation for the minimum GITHUB_TOKEN permissions are show in the Recommendations tab.
Available for Enterprise Tier users only
View the name and path of every file that was written during the build process.
Harden-Runner tracks every file written to the GitHub Actions working directory during the build process.
In the insights page in the File Write Events tab you can see a file explorer view of each file that was written to.
Clicking on any file reveals a list of processes that wrote to it, providing complete transparency.
Available for Enterprise Tier Users only
Get deeper visibility into your CI/CD workflows by viewing all executed process names, Process IDs (PIDs), and process arguments within your environment. This capability is especially useful for forensics and incident response, allowing you to understand what ran and why.
To access this feature switch to the Process Events tab on your Insights page
Harden-Runner tracks every process that is run during the build process.
Clicking on any process ID (PID) in the process events shows the process that caused the event, along with the process arguments.
You can walk up the process tree to analyze parent-child relationships, helping you detect suspicious activity and understand how processes interact.
For more details, refer to
Once you set these allowed endpoints in the workflow file, or in the and switch to using egress-policy:block :
This telemetry is used to render the page.
For more details, refer to
