Baseline Anomaly Detection

A detection method that compares current behaviour to an established normal pattern and alerts when activity deviates. In CI/CD, this often means tracking network destinations, process execution, and credential use so malicious package behaviour stands out quickly.

Expanded Definition

Baseline anomaly detection is a comparison method: it learns what “normal” looks like for a system, user, workload, or pipeline, then flags behaviour that falls outside that expected pattern. In security operations, the baseline may include login timing, command sequences, network destinations, API calls, build artefacts, or credential usage. The term is widely used across SOC analytics, cloud security, and software supply chain monitoring, but definitions vary across vendors on how much drift is tolerated before something is considered anomalous.

In practice, the baseline is not a fixed rule set. It is a model that changes as environments change, which means tuning and governance matter as much as the detection logic itself. For example, a CI/CD pipeline may appear “normal” during routine package retrieval, yet the same pattern can become suspicious if a build agent suddenly starts reaching unfamiliar registries or attempting to read secrets outside its usual scope. NIST’s NIST Cybersecurity Framework 2.0 supports this kind of continuous detection thinking through ongoing monitoring and response outcomes.

The most common misapplication is treating any deviation as malicious, which occurs when teams fail to account for approved change windows, seasonal workload shifts, or newly deployed automation.

Examples and Use Cases

Implementing baseline anomaly detection rigorously often introduces alert tuning overhead, requiring organisations to weigh early detection against the cost of investigating benign change.

• Detecting a CI runner that begins contacting new external domains during a package install, especially when that behaviour does not match its historical profile.
• Identifying a service account that suddenly requests secrets far outside its usual workflow, which can indicate credential abuse or agent compromise.
• Spotting unusual process execution on build hosts, such as a compiler spawning shell commands that the pipeline normally never uses.
• Monitoring cloud workloads for abnormal data egress patterns that diverge from established deployment or release behaviour.
• Comparing current activity against known-good build telemetry so a malicious dependency or tampered artifact stands out quickly, aligning with continuous monitoring practices described by NIST and related detection guidance.

For identity-heavy environments, baseline logic becomes especially useful when non-human identities, service principals, and automation agents are involved. Their activity is often more repetitive than human activity, which makes unexpected shifts easier to spot, but only if the baseline is built from trustworthy telemetry and reviewed for drift. Guidance from OWASP’s AI security guidance and broader monitoring practices can be helpful where agentic workflows or LLM-integrated pipelines are part of the environment.

Why It Matters for Security Teams

Baseline anomaly detection matters because it is one of the few scalable ways to notice subtle compromise before damage spreads. When an attacker uses stolen credentials, a compromised build agent, or an abused API key, the activity often looks legitimate at the individual action level. The signal emerges only when behaviour is compared against the established norm. That is why baseline quality, data coverage, and exception handling are critical controls, not just detection hygiene.

Security teams also need to remember that baselines can become brittle. Overfitted models generate noise, while overly broad baselines hide real abuse. In environments that rely on agents, CI/CD automation, or non-human identities, this becomes a governance issue: who approves normality, how often it is recalculated, and which events reset the expected pattern. The NIST Cybersecurity Framework 2.0 reinforces the operational need to detect, respond, and learn continuously rather than rely on static thresholds.

Organisations typically encounter the limits of baseline anomaly detection only after an account takeover, pipeline tampering, or unexpected data exfiltration, at which point the baseline itself becomes operationally unavoidable to reconstruct what changed.

Related resources from NHI Mgmt Group

• How do you know if anomaly detection is actually improving security operations?
• Why do AI-orchestrated attacks break traditional anomaly detection?
• What do teams get wrong about anomaly detection in operations?
• How do security teams know whether traffic anomaly detection is working?