What are the signs that an attacker is moving laterally through a software delivery pipeline?

Warning signs include unexpected access to additional tools, use of valid credentials from unusual locations or accounts, changes to build artifacts or scripts, and access patterns that do not match normal development workflows. If attackers can reuse trusted identities across CI/CD, containers, and repositories, they can remain hidden long enough to deepen the breach and tamper with downstream systems.

How to recognise lateral movement in a software delivery pipeline

Lateral movement in a delivery pipeline is rarely a single noisy event. It usually looks like an attacker moving from one trusted system to another by reusing access, chaining tooling, and blending into normal CI/CD activity. The most useful indicators are deviations in tool use, identity reuse, artifact changes, and workflow access that do not match how the pipeline is normally operated.

A pipeline compromise often becomes visible only after the attacker expands from one foothold into adjacent systems such as source control, build runners, artifact stores, and deployment targets. That is why the warning signs matter: they reveal when a legitimate delivery path is being used as an internal attack path.

What the strongest warning patterns usually look like

Look for access that is valid but contextually wrong. Examples include a service identity suddenly reaching additional repositories, a build account appearing in places it never used before, or credentials being used from unusual hosts, regions, or automation jobs. Reuse of trusted identities across CI/CD, containers, and deployment tooling is especially important because it lets an attacker move without immediately tripping authentication controls.

Changes to build artifacts, scripts, pipeline definitions, or release metadata are another major signal. When those changes appear without the normal review pattern, approval chain, or commit history, the issue may be more than tampering with code. It may indicate the attacker has progressed from initial access into the delivery mechanism itself. Case studies such as CI/CD pipeline exploitation case study show how mismanaged pipeline secrets and configuration gaps can let an intruder deepen access and alter downstream systems.

Unexpected tool invocation is also meaningful. If a pipeline step starts using additional package managers, remote fetches, administrative commands, or secret-access routines that are not part of the normal workflow, treat that as a possible sign of movement rather than routine automation. Supply-chain incidents such as Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign illustrate how malicious code can pivot through delivery tooling and expose secrets during normal build activity.

Where detection gets hardest in practice

The hardest part is separating attacker activity from legitimate automation. Delivery pipelines are designed to be fast, distributed, and highly automated, so adversaries try to hide inside expected noise. If one identity is allowed to operate across source control, CI, artifact storage, and deployment, the same access can be reused to reach multiple layers without obvious privilege escalation.

That is why movement across boundaries matters more than any single event. A login from a strange location may be suspicious, but a strange login followed by artifact changes, secret access, and a deployment action is much stronger evidence of compromise. The strongest signal is a sequence that breaks the normal development workflow, especially when it includes both valid credentials and access to systems that should not normally be chained together.

Trusted identity reuse is the core enabler. If the same account, token, or secret can operate across environments, an attacker can use it to move laterally while looking like an approved process. The broader pattern is captured in The 52 NHI Breaches Report, which shows how credential theft, lateral movement, and secret abuse commonly combine once trusted identities are compromised.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1021 — Remote Services	Pipeline lateral movement often uses valid access to reach adjacent systems.
	T1552 — Unsecured Credentials	The question centers on credential reuse and secret abuse in delivery systems.
Recommendation — Map suspicious cross-system access to T1021 and hunt for movement beyond the initial foothold. Track exposed pipeline secrets as T1552 and rotate any credential that can traverse environments.
CIS Controls v8	CIS-5 — Account Management	Pipeline movement depends on reused accounts, stale access, and weak lifecycle control.
Recommendation — Review and remove nonessential pipeline access paths under CIS-5 before attackers reuse them.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Lateral movement is easier when delivery identities can reach too many systems.
Recommendation — Restrict pipeline identities to the minimum systems and actions needed under AC-6.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Trusted non-human identities can be reused to move through CI/CD and deployment stages.
	NHI-02 — Secret Leakage	Secret exposure is a common mechanism for moving from one delivery component to another.
Recommendation — Reduce pipeline identity privilege so a single compromise cannot traverse the delivery chain. Treat leaked pipeline secrets as movement enablers and rotate them immediately.

Practitioner Guidance

What to prioritise: Focus first on workflow breaks, not just authentication events. Anomalous access to secrets, runners, repositories, and artifact systems is more actionable than a single odd login when the attacker is moving laterally through the pipeline.

What to verify: Confirm whether the observed access matches the expected job, branch, environment, and operator. If the identity is valid but the context is wrong, treat it as a compromise candidate and check for artifact tampering, secret exposure, and unauthorized deployment actions.

What good looks like: Normal pipeline activity should have tight identity scoping, limited cross-system reuse, clear approval boundaries, and traceable changes from source through build to release. When those boundaries are blurred, lateral movement becomes much easier to conceal.

Practitioner takeaway: In a software delivery pipeline, lateral movement usually shows up as trusted access behaving in the wrong sequence, across the wrong systems, and with the wrong operational context, so the investigation should follow the workflow path, not just the login event.