What Is Baseline Creation? Definition & Examples

Baseline creation is the process of recording normal runner behavior so security teams can compare later executions against expected activity. In CI/CD, that usually includes outbound network calls, file writes, and spawned processes per job. The baseline becomes the reference point for spotting suspicious deviations and policy violations.

Why baseline creation matters

Baseline creation turns a one-off observation into a security reference point. By recording normal runner behavior, teams can tell the difference between expected CI/CD activity and a job that suddenly reaches out to an unusual host, writes to an unexpected path, or launches an extra process.

That distinction matters because build and test systems are high-trust execution environments. A baseline helps separate ordinary pipeline variation from behavior that may indicate injected code, misconfigured tooling, or policy drift. In practice, the baseline is only useful when it is specific enough to the job, runner image, and pipeline stage that deviations are meaningful rather than noisy.

What a useful baseline should capture

A baseline is strongest when it describes the normal shape of execution, not just a single allowed action. For CI/CD runners, that usually includes outbound network destinations, file and directory access, child processes, environment-dependent differences, and any repeatable build-time downloads or artifact writes.

The goal is not to freeze every job into a rigid pattern. Some variance is normal across branches, dependencies, and build targets. The practical challenge is defining a baseline that is stable enough to detect suspicious behavior while still tolerating legitimate changes. When the baseline is too broad, it misses abuse. When it is too narrow, it becomes unusable because every harmless change looks like an incident.

Baseline creation also becomes more reliable when it is tied to known-good pipeline stages. A compile job, a packaging job, and a deployment job should not share the same expected behavior unless they truly execute the same way. Treating them as one pattern usually hides the very differences you want to detect.

How baseline creation supports detection

Baseline creation gives security teams a reference for anomaly detection, policy validation, and later investigation. Once normal activity is recorded, alerts can focus on unexpected egress, unusual binary execution, unauthorized file modification, or behavior that does not fit the job’s usual sequence.

That makes the baseline useful for both prevention and triage. It can support allowlist-style controls, help confirm whether a pipeline change is legitimate, and give analysts a before-and-after view when something looks wrong. In environments with shared runners or rapidly changing pipelines, the baseline is often the only practical way to distinguish common platform noise from meaningful deviation.

If the organisation manages identity-bearing material in pipelines, the same reference point can also help surface misuse of secrets that should never appear in normal job output or process behavior. NHIMG research notes that secrets leaks are common and damaging, which makes baseline-driven detection especially valuable in build systems.

How to keep the baseline trustworthy over time

Baseline creation is not a one-time task. As build images, dependencies, tools, and runner configurations change, the baseline must be reviewed or it will either drift into irrelevance or keep flagging legitimate work as suspicious. The most common failure mode is stale baselines that no longer match current pipeline behavior.

A strong baseline should therefore be version-aware and tied to the context that produced it. When teams change compilers, add new scanners, or alter deployment steps, they should expect the baseline to move with the pipeline. Where possible, capture the reason for the change so later investigations can separate planned evolution from unexpected deviation.

For organisations that want a broader hardening reference for expected system behavior, CIS Benchmarks provide a useful companion model for hardening baselines, while NIST Cybersecurity Framework 2.0 helps place baseline-driven detection inside a wider govern, identify, protect, detect, respond, and recover program.

Risk and Threat Considerations

Baseline creation reduces uncertainty, but a weak or stale baseline can create blind spots instead of insight. If the normal profile is built from incomplete data, attackers may blend malicious behavior into accepted variance, especially in CI/CD systems where some network access and file activity is already expected.

Failure mechanism: Incomplete coverage, overly broad thresholds, or unreviewed drift can normalize suspicious execution and delay detection of tampering, injected steps, or unexpected tool use.

Impact: Security teams may miss compromised runners, malicious pipeline changes, or unauthorized access paths until later stages, when the resulting exposure is harder to contain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 4 — Secure Configuration of Enterprise Assets and Software	Baseline creation records normal behavior used to validate secure configuration drift.
	CIS 8 — Audit Log Management	Baselines depend on logged runtime activity to compare later executions against expected events.
Recommendation — Define and monitor approved runner configurations to detect drift from expected behavior. Collect and review runner logs so deviations from baseline behavior are visible.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Baseline creation supports ongoing comparison of observed activity against normal execution patterns.
	PR.DS — Data Security	Runner baselines help spot abnormal access to files, artifacts, and other sensitive build data.
Recommendation — Establish continuous monitoring for CI/CD runners to flag behavior that departs from baseline. Limit and monitor file and artifact access so unexpected writes or reads are detected.

Practitioner Guidance

Why practitioners should care: Baseline creation is only useful when it reflects the specific job, runner, and stage being monitored. Generic baselines tend to produce either noisy alerts or false confidence, neither of which helps in a live pipeline.

Common misunderstanding: A baseline is not the same as a static allowlist. It should describe normal behavior with enough context to account for legitimate change, while still making abnormal execution stand out.

Practitioner takeaway: Revisit the baseline whenever the pipeline changes materially, because the value of this control depends on keeping “normal” aligned with current reality.

Baseline Creation