# Baseline Baseline monitoring is the practice of establishing what normal external network calls your CI/CD workflows typically make, and then monitoring for deviations that might indicate a security breach. At its core, it helps answer the question: *“Is this job making expected and safe outbound network calls?”* ### Baseline Status Categories Each monitored resource, such as a job or repository, is evaluated for the predictability of its network activity. This evaluation helps uncover anomalies that could signal security issues. Each resource can be in one of the following baseline states: * Creating – The system is still collecting data to determine the resource’s baseline behavior. * Stable – The resource’s network activity is predictable and consistent. A resource is considered stable once it has completed 100 runs without baseline changes. {% hint style="info" %} **Note**: You can configure baseline thresholds based on either the [**number of runs**](/administration/admin-console/settings/anomaly-detection.md#run-based-detection) or the [**number of days**](/administration/admin-console/settings/anomaly-detection.md#time-based-detection). {% endhint %} * Unstable – The resource’s network activity is erratic and prone to triggering frequent alerts. If the baseline has changed within the last 50 runs, the resource is classified as unstable. ### Baseline Summary Every baseline view (GitHub Organization, ARC Clusters, Repositories, and Jobs) opens with a summary panel that gives you the at-a-glance health of the baseline before you dig into individual destinations.
The summary surfaces four metrics: * **Stability**: the current baseline state (Stable, Unstable, or Creating). See [Baseline Status Categories](#baseline-status-categories) for what each state means. * **Based on**: the number of job runs that contributed to the current baseline. * **Last changed**: how long ago the baseline last changed, with a count of runs that have completed since that change. * **Destinations**: the total number of external destinations on the baseline for the selected resource. ### Baseline Changelog The Baseline Changelog gives you a complete record of how a baseline has evolved over time. It opens as a side panel from the **View changelog** link on any baseline view. Each entry shows: * The destination that was added to the baseline * When the change occurred (e.g., *5 days ago*, *13 days ago*) * A **View Insights** link that takes you to the workflow run where the destination was first observed Use the changelog to investigate why a baseline became unstable, to confirm whether a recent addition is expected, and to trace any new destination back to the workflow run that introduced it.
### Filtering Baseline Destinations The GitHub Organization, ARC Clusters, and Repositories views share a sidebar with two groups of filters: **Worth a look** and **Browse by type**. These filters help you focus on destinations that are most likely to need investigation, or narrow the list to a specific category of destination. The Jobs view uses a different layout (a tree of repositories, workflow files, and jobs). On that view, use the **Destination Type** dropdown above the destinations table to filter by category. #### **Worth a look**
These filters surface destinations that are most likely to warrant attention. * **IOC matches**: Destinations that match an Indicator of Compromise (IOC) tracked by the StepSecurity SOC, including domains and IPs associated with active supply-chain attacks (for example, *Trivy C2 Domain*, *Axios C2 Domain*, *Mini Shai Hulud 2*). Each matched destination is labeled inline with the specific threat name. {% hint style="info" %} **IOC labels appear regardless of filter state.** If a destination matches a known IOC, the threat name is shown beneath the destination in every view, not just under the IOC matches filter. {% endhint %} * **New this week**: Destinations that were first observed on the baseline in the last 7 days. Useful for catching changes in workflow behavior right after they happen. * **Rare in fleet**: Destinations contacted by an unusually small share of jobs across the organization. Rarity is a signal worth reviewing because targeted attacks often touch destinations that the rest of the fleet does not. #### **Browse by type**
These filters group destinations by category so you can review the baseline one slice at a time. * **AI · MCP servers**: AI service endpoints and MCP (Model Context Protocol) servers contacted by your jobs. * **Public registries**: Public package registries, including npm, PyPI, Docker Hub, and GitHub Container Registry. * **Cloud infra**: Cloud provider infrastructure endpoints, including AWS, Azure, and Google Cloud APIs and services. * **Direct IP**: Destinations contacted by raw IP address rather than by hostname. These are worth reviewing because legitimate workflows usually resolve hostnames through DNS. ### Baseline Coverage at StepSecurity StepSecurity applies baseline monitoring to four distinct resource types within your CI/CD environment: #### **Jobs** The Jobs tab provides detailed insights into individual workflow jobs and their external network destinations. Repositories, workflow files, and jobs are organized as a tree on the left, and the right pane shows the Baseline Summary and observed destinations for the selected job. For the selected job you can: * View the job’s Baseline Status (Stable, Unstable, Creating) * See the number of job runs the baseline is based on * Track when the baseline last changed and how many runs have completed since * Filter destinations by category using the **Destination Type** dropdown * Access the underlying Workflow File, and jump directly to Workflow Runs or Log Samples for investigation * Generate a [policy](/github-actions/harden-runner/policy-store.md#from-the-baseline-page) directly from the endpoints observed in a specific job, or export those endpoints to a text file for further analysis.
**Network insights per job** For each destination contacted by a job, you can view: * The domain or IP * Port used (e.g., 443) * Whether the destination is allowed * First seen and Last contacted timestamps * Total number of calls * Links to the workflow runs that made those calls #### **Repositories** The Repositories tab aggregates baseline data across all jobs and workflows within a specific repository. Use the **Repository** selector at the top of the view to choose which repository’s baseline to inspect. The tab offers the same insights as the Jobs view, but from a repository-wide perspective, which helps identify broader behavioral patterns and anomalies.
#### **ARC Clusters** For environments that use ARC-managed self-hosted runners, the ARC Clusters view lets you monitor network behavior trends. Use the **Cluster** selector at the top of the view to pick which cluster’s baseline to inspect. You can see: * Which destinations self-hosted runners are contacting * Workflow runs that interacted with those destinations
#### **GitHub Organization** This view aggregates baseline data across all jobs and repositories in your GitHub organization. It enables organization-wide monitoring to detect systemic threats or changes. You can: * View all external destinations contacted by any job across the organization * See total call counts for each destination * Drill into specific workflow runs using the Sample Workflow Runs option * Detect organization-wide issues, such as unexpected domain access or behavioral shifts * Generate policies directly from the endpoints observed in the organization
### Creating Policies from a Baseline Every baseline view has a **Create Policy** button in the top right. Clicking it generates a workflow run policy from the destinations on the current baseline at the scope you are viewing (job, repository, ARC cluster, or organization). Policies created this way can be applied through the [Policy Store](/github-actions/harden-runner/policy-store.md) without modifying workflow files. {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.stepsecurity.io/github-actions/harden-runner/baseline.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.