Without a baseline, teams have no practical reference point for deciding whether a pipeline run is normal or compromised. That makes it harder to spot injected processes, altered artifacts, or unexpected network activity during the build. A baseline turns runtime monitoring into a detection control that can flag drift, trigger review, and support faster containment.
When a CI/CD run has no workload baseline, what changes?
A baseline gives you a reference for what normal build and deploy activity looks like: process trees, file writes, outbound connections, signing steps, and artifact handling. Without it, a pipeline run may still complete, but the team loses the ability to judge whether the run behaved as expected or quietly introduced compromise indicators that deserve investigation.
That gap matters because CI/CD environments are high-trust execution paths. Build jobs often have access to source code, signing material, publishing credentials, and internal services. When expected behavior is undefined, suspicious activity can blend into ordinary automation, especially during fast-moving releases.
A useful way to think about the baseline is as a detection boundary. It does not replace secure pipeline design, but it makes runtime monitoring meaningful by turning anomalies into something the team can compare, triage, and escalate.
What kinds of abnormal behavior become harder to see?
Three classes of drift are especially important. First is process and execution drift, such as an unexpected child process, shell invocation, or tooling chain that was not part of the approved build flow. Second is artifact drift, where the job produces, modifies, or signs something that does not match the usual build profile. Third is connectivity drift, where the pipeline talks to an unusual host, pulls from an unapproved source, or reaches a destination that the build should never need.
These are not abstract concerns. Supply-chain intrusions often succeed by hiding in the narrow window where developers expect the pipeline to do work on their behalf. The more automated the environment, the easier it is for malicious activity to look like a normal step unless the team has a known-good behavioral baseline.
That is why baseline design should capture both approved execution paths and the expected boundaries of variation. A good baseline is not “everything we have ever seen”, it is the set of normal behaviors narrow enough to make drift visible but broad enough to tolerate legitimate release differences.
How should teams use the baseline operationally?
A baseline should support detection, review, and containment, not just reporting. If a pipeline run deviates from expected workload behavior, the first question is whether the deviation was intentional and documented. If not, the event should be treated as a security signal, especially when it touches artifact integrity, credential use, or external network activity.
The baseline also helps separate noisy alerts from meaningful ones. If every build emits different process trees or network paths, then monitoring becomes easy to ignore. If the team defines a stable reference, then exceptions can be investigated faster and can drive stronger controls such as tighter runner isolation, dependency pinning, signed artifacts, or approval gates.
When the pipeline is already sensitive enough to publish software or reach production systems, baseline monitoring should be paired with immutable logging and evidence retention so that analysts can reconstruct what changed, when it changed, and which step introduced the deviation.
Risk and Threat Considerations
Without a workload baseline, CI/CD monitoring loses much of its detection value and abnormal behavior can hide inside legitimate automation. The main risk is not just missed alerts, but delayed recognition of tampered builds, compromised runners, or unexpected outbound access that may already have affected artifacts or secrets.
Failure mechanism: A malicious or unintended step blends into the normal pipeline flow because there is no reference profile for process behavior, artifact handling, or network activity. That allows injected commands, altered dependencies, or unauthorized transfers to escape immediate notice.
Impact: Teams may ship compromised artifacts, leak secrets, or approve a build that has already been influenced by attacker-controlled activity, which increases containment cost and reduces trust in release integrity.
Framework Alignment
CI/CD Pipeline Identity Security Guide helps teams secure the identities and trust paths that make pipeline behavior meaningful to monitor.
CI/CD pipeline exploitation case study shows how mismanaged pipeline access and configuration can lead to server takeover.
Reviewdog GitHub Action supply chain attack illustrates how pipeline compromise can expose secrets through trusted automation.
Shai Hulud npm malware campaign provides a real-world example of supply-chain abuse surfacing in developer and pipeline ecosystems.
SPIFFE workload identity specification is relevant where pipeline workloads need strong, attestable identity instead of static trust.
SLSA aligns with the need to preserve build integrity and provenance when pipeline behavior is under scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Baseline detection depends on reliable pipeline logs and event records. |
| Recommendation — Centralize and review pipeline logs to spot abnormal execution and data movement quickly. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | CI/CD baselines rely on knowing which jobs, runners, and endpoints are expected. |
| Recommendation — Inventory pipeline assets and endpoints so unexpected behavior stands out fast. | ||
| SLSA | Supply-chain Levels for Software Artifacts | A baseline supports build integrity and provenance checks across the release pipeline. |
| Recommendation — Adopt SLSA-aligned provenance and integrity checks for build outputs. | ||
| NIST CSF 2.0 | DE.CM-01 — The environment is monitored to detect potential cybersecurity events | Workload baselines make continuous monitoring effective for pipeline drift. |
| Recommendation — Monitor CI/CD workloads against expected behavior to detect anomalies. | ||
Practitioner Guidance
What to prioritise: Baseline the highest-trust jobs first, especially release, signing, and deployment pipelines, because those runs have the most damaging failure modes if drift is missed.
What to verify: Confirm that the baseline covers process lineage, outbound destinations, artifact generation, and any step that can touch credentials or signing material. If those elements are absent, the baseline is too weak to support real detection.
Common mistake: Treating a baseline as a one-time setup task. Pipelines evolve, so the reference must be reviewed when build tooling, dependencies, runners, or deployment targets change, otherwise the control will either miss drift or generate noise.
Practitioner takeaway: A CI/CD baseline is only useful if it is specific enough to expose abnormal behavior and current enough to reflect the way the pipeline actually runs today.
Related resources from NHI Mgmt Group
- What happens when CI/CD pipelines are built without PAM controls?
- What happens when CI/CD is extended to AI and ML deployment pipelines without stronger security controls?
- What happens when open-source repositories harden CI/CD pipelines without coordinated governance?
- How should security teams add application security testing into Azure DevOps CI/CD pipelines without slowing delivery?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
