Baseline detection records the normal behavior of a job so teams can spot unusual network calls, processes, or file writes. Blocking policies go further by preventing specific actions altogether when they violate approved behavior. Detection helps teams observe and investigate, while blocking reduces blast radius in the moment. Mature runner security usually needs both, because visibility alone does not stop abuse.
Why Baseline Detection and Blocking Policies Play Different Security Roles
Baseline detection and blocking policies solve different parts of the same runner-security problem. Baselines describe what “normal” looks like, which makes deviations visible during routine builds and suspicious jobs. Blocking policies enforce a hard boundary, stopping actions that violate approved behavior even if the job is otherwise able to run. In CI/CD, that distinction matters because abuse often happens quickly and at scale.
Detection is strongest when teams need observability into runner behavior without interrupting delivery. It helps answer whether a job suddenly reaches out to an unusual domain, starts spawning unexpected processes, or writes to paths it normally does not touch. Blocking is stronger when the action itself is unacceptable, such as a runner trying to reach unauthorised destinations or execute disallowed tooling. The practical difference is whether the control informs response or directly constrains the action.
For supply-chain and pipeline integrity, the contrast is especially important. A baseline can reveal patterns that indicate compromise, but it does not stop the first malicious step. Blocking policies reduce the blast radius by refusing the action in real time, which is why runner hardening often pairs policy enforcement with telemetry. CI/CD pipeline exploitation case study shows how mismanaged pipeline exposure can turn a runner into a foothold for broader compromise.
How Teams Should Think About Visibility, Enforcement, and Blast Radius
Baseline detection is essentially a measurement and investigation control. It gives security and platform teams a reference point for anomaly triage, tuning, and post-incident review. Blocking policies are a preventive control, so their design must be narrower and more explicit, because overly broad blocking can break legitimate builds while too little blocking leaves risky behavior untouched. The right choice depends on whether the priority is observing drift or preventing a known-dangerous class of action.
In mature environments, the two controls are complementary rather than interchangeable. Detection helps you understand whether the runner is behaving outside its expected envelope, while blocking helps ensure that some classes of activity never happen at all. That combination is particularly valuable when runners have access to secrets, repositories, package registries, or other sensitive build-time assets. Ultimate Guide to NHIs, Key Challenges and Risks is useful context for why visibility gaps and overprivilege are so dangerous in CI/CD-adjacent environments.
When policy design is weak, the failure mode is predictable: teams either overtrust detection and learn about abuse too late, or they overblock and create operational pressure to disable controls. Good runner security avoids both extremes by using baselines to understand normal behavior and blocking to enforce only the actions that are genuinely out of bounds. Top 10 NHI Issues is relevant here because excessive privilege and poor visibility are common enablers of abuse across automated execution environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 Control 6 — Access Control Management | Runner policies need explicit access enforcement and least privilege. |
| CIS Control 8 — Audit Log Management | Baseline detection depends on logging normal and anomalous runner behavior. | |
| CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Blocking policies are configuration guardrails for approved runner behavior. | |
| Recommendation — Restrict runner actions and revoke any unnecessary execution or network access paths. Collect and review runner telemetry so deviations can be detected and investigated. Harden runner configurations to prevent disallowed processes, file writes, and network actions. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Baseline detection is a continuous monitoring pattern for runner behavior. |
| PR.AC — Identity Management, Authentication and Access Control | Blocking policies enforce what the runner is allowed to do. | |
| PR.PS — Platform Security | Runner hardening requires preventive control over execution and platform behavior. | |
| Recommendation — Monitor runner activity continuously for deviations from expected behavior. Apply access controls that limit runner actions to approved behavior. Harden runner platforms so unsafe execution paths are blocked by design. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Exposure | CI/CD runners often handle secrets, making blocking and monitoring material. |
| NHI-03 — Excessive Privileges | Blocking policies reduce the blast radius of overprivileged automation. | |
| NHI-07 — Detection and Visibility Gaps | Baseline detection directly addresses whether runner behavior is observable. | |
| Recommendation — Store and access runner secrets only through controlled, auditable mechanisms. Remove unnecessary permissions from runners and restrict high-risk actions. Instrument runners so abnormal execution, egress, and file activity are visible. | ||
Practitioner Guidance
What to verify: Treat the baseline as a living profile of runner behavior, not a one-time tuning exercise. If your builds frequently change dependencies, containers, or network destinations, the baseline must be reviewed often enough that it still reflects expected job behavior instead of yesterday’s assumptions.
Decision rule: Use detection for unknowns and blocking for known-bad classes of activity. If the action would meaningfully expand blast radius, such as unsanctioned egress or execution paths that should never be present in that runner class, enforce it with policy rather than depending on alert handling alone.
What practitioners underestimate: The hardest part is not writing either control, it is keeping them aligned with pipeline change. A stale baseline becomes noise, and an overbroad blocking rule becomes a deployment outage, so the real operational test is whether the controls stay precise as your CI/CD system evolves.
Practitioner takeaway: Detection tells you a runner is drifting, but blocking is what prevents the drift from becoming compromise, so the best programs use both and tune them to different decisions.
Related resources from NHI Mgmt Group
- What is the difference between monitoring CI/CD runners and monitoring traditional endpoints?
- What is the difference between traditional IOC monitoring and IOC detection for CI/CD pipelines?
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- What is the difference between workflow hardening and CI/CD identity governance?
