# Pipeline Runs This page provides detailed runtime insights for your GitLab CI pipelines, helping you monitor pipeline activity and detect anomalies in real time. You can view the total number of pipeline runs observed for each project. * Navigate to **Pipeline Runs** in the sidebar. * Each project displays the total number of runs.

* Click **Pipeline Runs** next to a project to see detailed job history.

### Features Available in Harden-Runner * View outbound network traffic at the project level * Detect anomalous outbound network traffic * Filter outbound network traffic to allowed endpoints * Detect tampering of source code during build * View baseline status at project level * View process name and arguments #### View outbound network traffic at the job level Harden-Runner monitors all outbound traffic from each project at the DNS and network layers * To access this feature switch to the `Network Events` tab on your Project Insights page * On this page you can see: * The process * PID * Destination * Port * Status * Timestamp

* You can click the PID to view 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.

#### Detect anomalous outbound network traffic Harden-Runner applies machine learning to historical workflow data to detect anomalies. * Baseline requires 100 pipeline runs to be created. * After the baseline is set, any outbound traffic to unknown destinations will be flagged. * Alerts appear in the **Insights** and **Detections** pages.

* You can view the list of all anomalous outbound network traffic in the `Detections` page on the dashboard

For more details, refer to [Anomalous Outbound Call Detection Using Machine Learning](https://www.stepsecurity.io/blog/announcing-anomalous-outbound-call-detection-using-machine-learning) #### Filter outbound network traffic to allowed endpoints You can specify an allowlist in your `.gitlab-ci.yml` file for self-hosted runners. Any endpoint not on the list will be blocked.

When this pipeline is run attacker.com will be blocked because it is not part of the allowlist

#### Detect tampering of source code during build Harden-Runner monitors file writes and detects if any source code files are overwritten during a build. **Why is this important?** * 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. **How to Detect Source Code Overwrites** * 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.

* 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. #### View baseline status at the project level To assess the stability of a project network behavior, you can use the Baseline feature A Baseline is created after 100 pipeline runs **How to Access** Navigate to the `Baseline` tab under the Pipeline runs

The baseline stability status indicates whether a job is making predictable or unpredictable network calls. This is crucial for determining the reliability of detections from that job. **Baseline Status Categories** 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. You can view the changelog to see when last the baseline changed and what made it to change

#### View process name and arguments 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 **How it Works** * 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.