SDLC infrastructure threats expose gaps in developer and CI/CD controls

At a glance

What this is: This is StepSecurity’s analysis of SDLC infrastructure threat coverage, arguing that supply chain attackers exploit gaps across developer endpoints, VCS, CI/CD, registries, and production.

Why it matters: It matters to IAM and NHI practitioners because development pipelines now depend on privileged human, service, and agentic identities whose credentials, policies, and runtime access all need coordinated governance.

👉 Read StepSecurity's analysis of SDLC infrastructure threats and supply chain protection

Context

Software supply chain security fails when teams treat developer machines, code hosting, build systems, and registries as separate problems. The article argues that attackers exploit the seams between these layers, which makes identity governance relevant wherever credentials, tokens, service accounts, and AI coding agents can act inside the software delivery chain.

For IAM and NHI teams, the important issue is not only code integrity but who or what can modify, sign, publish, or execute software at each stage. That includes developer credentials, CI/CD secrets, third-party automation, and machine identities that can move from one pipeline step to the next if controls are fragmented.

Key questions

Q: What breaks when SDLC security is split across separate tools?

A: Attackers use the seams. If developer endpoints, repositories, CI/CD, registries, and production are protected in isolation, a blocked intrusion can pivot into the next layer using inherited trust, stale credentials, or excessive workflow permissions. Effective defence requires policy and visibility across the whole delivery chain, not a series of disconnected point controls.

Q: Why do privileged developer and pipeline identities increase supply chain risk?

A: Because they can write code, approve changes, publish artefacts, or trigger deployments with minimal friction. When those identities keep standing access, an attacker only needs one compromise to move from initial access to software distribution. Short-lived, task-scoped permissions reduce the blast radius and make abuse easier to detect.

Q: How do security teams know whether CI/CD risk gates are actually working?

A: Look for enforced outcomes, not just alert volume. A working gate blocks critical issues, records every exception, identifies the approver, and preserves release evidence that can be audited later. If findings do not change release behaviour, the gate is advisory, not controlling.

Q: Should organisations treat AI coding agents like privileged software identities?

A: Yes. If an AI agent can install code, access secrets, or modify repositories, it is functionally acting as a privileged non-human identity and should be governed that way. That means task-scoped access, explicit boundaries, and monitoring of its downstream actions, especially when it can touch build and release systems.

Technical breakdown

Why SDLC attacks move across developer endpoints and CI/CD

Modern supply chain attacks rarely stay in one control plane. An attacker may begin on a developer endpoint through a malicious package, compromised plugin, or abused AI coding assistant, then use stolen tokens or workflow permissions to reach source control and build systems. The technical pattern is cross-stage propagation: once a trusted identity is abused, the attacker pivots into the next SDLC layer where secrets, signing steps, or deployment permissions are available. This is why isolated tooling often fails. The threat is not only malware, but trusted automation operating with excessive privileges across the delivery chain.

Practical implication: map identities and secrets across every SDLC stage so a compromise in one layer cannot automatically authorise the next.

How package registries and workflow policies become control points

Package registries and CI/CD workflow definitions are enforcement points because they decide what enters builds and what actions a pipeline may take. Cooldown logic, provenance checks, and compromised package databases reduce exposure to newly published or known malicious dependencies. Workflow governance matters for the same reason: a permissive GitHub Actions or similar pipeline can let untrusted third-party automation execute with broad access. In identity terms, these systems are doing authorisation on behalf of code, services, and sometimes AI-assisted tooling. If policy is weak, the pipeline itself becomes a privilege amplifier.

Practical implication: apply policy to package age, provenance, and workflow permissions before code reaches build and deploy stages.

What continuous runtime monitoring adds to software factory defence

Runtime monitoring in CI/CD is useful because many supply chain attacks only become visible once the build job starts making unusual network calls, spawning unexpected processes, or reading files outside baseline behaviour. This is analogous to endpoint detection, but applied to build infrastructure. The value is not just alerting after compromise. It is building a behavioural baseline for privileged automation so the system can spot when a pipeline or agent identity starts acting outside its intended task scope. That is especially important as AI coding agents and other software entities participate directly in development workflows.

Practical implication: instrument builds for process, network, and file-access anomalies so privileged automation can be constrained at runtime.

Threat narrative

Attacker objective: The attacker wants to turn trusted SDLC infrastructure into a distribution mechanism for malicious code, secrets theft, and downstream compromise.

1. Entry occurs when attackers compromise a developer endpoint, malicious package, or workflow-linked identity that already has trusted access into the SDLC.
2. Escalation happens when stolen tokens, CI/CD permissions, or publishing rights let the attacker move from code access to build and release control.
3. Impact follows when compromised pipelines or registries distribute malicious artifacts into downstream environments and production systems.

NHI Mgmt Group analysis

SDLC security is now an identity governance problem as much as a software integrity problem. The article’s core point is that modern supply chain attacks travel on trusted identities, not just on vulnerable code. Developer accounts, build tokens, registry permissions, and automation credentials all become security boundaries when attackers target the software factory. Practitioners should treat every SDLC control plane as an identity boundary with its own lifecycle, privilege, and audit requirements.

Cross-stage attack paths create a new form of control fragmentation. The article shows why a tool that protects only repositories, or only CI/CD, leaves attackers room to pivot. That fragmentation mirrors the governance gap that identity teams already know from NHI sprawl. The relevant concept here is software factory privilege drift: privileges accumulate across development, build, and release systems faster than teams can review them. Practitioners should reduce standing access and align permissions to task scope across the entire delivery chain.

AI coding agents widen the SDLC identity surface. StepSecurity explicitly references AI coding agent security and MCP server monitoring, which matters because agentic systems can act inside development workflows with delegated access. That makes software delivery not just a human-to-machine problem but a machine-to-machine governance problem. The boundary issue is whether the agent is operating under tightly bounded, observable authority or has inherited broad developer trust. Practitioners should govern agent permissions with the same seriousness as human developer access.

Continuous enforcement matters more than static framework mapping. SITF-style models help teams visualise where supply chain threats live, but the article’s real claim is that security must be enforced where code is written, built, published, and deployed. That aligns with a Zero Trust reading of the software factory: trust should be explicit, narrow, and continuously checked. Practitioners should use framework mapping to prioritise controls, then verify that enforcement exists at runtime rather than on paper only.

What this signals

Software delivery pipelines are becoming identity-rich attack surfaces. That means practitioners should expect more governance pressure on developer credentials, build tokens, and automated release identities, especially where AI-assisted tooling is now embedded in daily engineering work. If the software factory can write, build, sign, or publish, it needs identity controls that are as explicit as those used for production systems.

The next control gap is likely to be between policy design and runtime enforcement. Teams that only document supply chain controls will still be vulnerable if build jobs, registries, and agent-driven workflows can execute with broad inherited privileges; the practical answer is to connect policy, logging, and conditional trust across the delivery chain.

Software factory privilege drift: the longer release systems retain standing access, the more likely attackers can reuse trusted paths for distribution. That is why practitioner programmes should pair least privilege with continuous monitoring and revocation, and anchor the control model in references such as the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10.

For practitioners

• Inventory identities across the software factory Map human users, service accounts, CI/CD tokens, signing credentials, package publishing rights, and AI coding agent permissions across developer endpoints, version control, build systems, registries, and production.
• Enforce policy before code can progress Block newly published or untrusted packages, require provenance checks, and restrict workflow permissions so unreviewed code and third-party automation cannot reach build or deploy stages.
• Add runtime detection to build infrastructure Monitor CI/CD processes, file access, and network egress for anomalous behaviour so compromised jobs can be detected while they are executing, not only after artefacts ship.
• Reduce standing privilege in release systems Apply least privilege to repositories, registries, and deployment workflows, and rotate or revoke credentials tied to outdated pipelines, inactive maintainers, or unused publishing paths.

Key takeaways

• Supply chain compromise is increasingly an identity problem because attackers abuse trusted developer, build, and release credentials to move across the SDLC.
• The scale of the risk comes from gaps between controls, where point solutions fail to stop attackers from pivoting from code access to pipeline control.
• Practitioners should govern the software factory as a chain of identity boundaries, with scoped access, runtime detection, and rapid revocation at every stage.

Key terms

• Software Factory: The end-to-end delivery environment that turns source code into released software, including repositories, CI/CD systems, build runners, signing services, and deployment automation. In security terms, it is a high-trust identity zone that needs strong lifecycle and privilege boundaries.
• CI/CD Pipeline: The automated systems that build, test, and deploy software, often holding privileged credentials for source control, cloud access, and release automation. When these pipelines leak secrets, they can turn a software delivery function into a high-trust compromise path.
• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.

What's in the full article

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• Dev Machine Guard behaviour for endpoint monitoring, AI coding agent security, and MCP server monitoring in real developer environments.
• Cooldown and compromised-package checks that gate dependency adoption before a pull request is merged.
• Harden-Runner runtime monitoring patterns for CI/CD process, file, and network controls.
• Artifact and registry monitoring details for preventing compromised packages from entering the supply chain.

👉 The full StepSecurity post covers implementation details across developer endpoints, CI/CD, registries, and runtime controls.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It helps practitioners build the identity controls that software delivery and automation now depend on.