They should do both, but the first priority is whichever path gives an attacker usable reach into production. If build roles can alter artefacts, secure the pipeline first. If runtime identities already have excessive access to data or control planes, tighten live permissions and logging first. The right sequence follows blast radius.
Which side should come first in practice?
Start with the path that can already reach production. If CI/CD roles can change artefacts, inject code, or mint deploy credentials, the pipeline is the faster route to widespread compromise. If live cloud identities already have broad control-plane or data-plane access, runtime monitoring alone will not contain the blast radius, so permission tightening comes first.
The real sequencing question is not “build versus runtime” in the abstract. It is whether attackers can use either path to obtain trusted execution, secret access, or destructive control. That is why mature teams treat CI/CD hardening and runtime visibility as linked controls, then prioritise the one that most directly shrinks immediate production reach.
For build security, the highest-value work is usually artefact integrity, secret containment, and preventing untrusted pipeline steps from gaining publish authority. For runtime security, the highest-value work is reducing standing privilege, improving logging, and detecting unexpected use of control-plane permissions or service credentials. Both reduce risk, but they reduce different attack paths.
How to choose based on blast radius
Use a simple decision rule: if a compromise of the pipeline lets an attacker ship code, tamper with releases, or steal deployment secrets, prioritise CI/CD security first. If a compromise of cloud identities lets an attacker read sensitive data, alter infrastructure, or disable protections in production, prioritise runtime monitoring and access reduction first. The first fix should target the path with the shortest route to impact.
That also means the answer can differ by environment. A heavily automated software delivery estate with weak token handling has a different first move from a cloud estate where overprivileged roles and weak detection already expose the production plane. Good sequencing follows the dominant trust boundary, not the team’s organisational chart.
In many environments, the most dangerous condition is the overlap between the two: a build compromise that can issue cloud credentials, or a runtime identity that can reach the pipeline. That is where a compromise of one layer becomes a launch point for the other, so the security programme should map trust flows end to end rather than treat delivery and runtime as separate worlds.
What practitioners should watch for when deciding order
Pipeline first is usually the right call when you see long-lived publishing tokens, self-hosted runners with broad access, mutable build scripts, or weak artefact provenance. Runtime first is usually the right call when cloud roles are shared, permissive, or poorly logged, and when existing detections cannot distinguish normal automation from abuse. In both cases, the practical question is whether the attacker can act with legitimate-looking authority after initial access.
Documentation and dashboards often hide the real priority. A clean deployment process does not matter if a runtime role can still exfiltrate data or turn off guardrails. Likewise, broad cloud monitoring is not enough if the build system can still produce trusted artefacts that carry attacker-controlled logic into production. The control that should move first is the one that closes the easiest abuse path, not the one that is easiest to measure.
Risk and Threat Considerations
CI/CD and runtime cloud access both create high-leverage failure modes because each can be used to translate a small foothold into broad production impact. The main risk is not just compromise, but trust inheritance: once an attacker controls a pipeline or a privileged runtime identity, they can often reuse that trust to reach secrets, artefacts, infrastructure, and downstream services.
Failure mechanism: A build compromise can poison artefacts, inject backdoors, or expose deployment secrets, while a runtime identity compromise can enable direct data theft, privilege escalation, or infrastructure sabotage. In both cases, the attacker benefits from legitimate automation and trusted permissions.
Impact: The likely outcome is expanded blast radius, because the attacker can move from a single account, token, or job into production systems, sensitive data, or release channels before defenders notice.
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 addresses the attack and risk surface, while CIS Controls v8, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD and runtime paths both fail through exposed credentials and tokens. |
| NHI-05 — Overprivileged NHI | The question centers on excessive production access from pipeline or runtime identities. | |
| NHI-07 — Long-Lived Secrets | Pipeline and runtime reach often persists through durable tokens and keys. | |
| Recommendation — Restrict secret exposure and rotate any credential that can reach production. Reduce standing privilege for build and runtime identities to the minimum required. Replace long-lived deployment and cloud secrets with short-lived credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Prioritisation depends on which accounts can change builds or production access. |
| CIS-8 — Audit Log Management | Runtime-first decisions depend on whether production abuse would be visible. | |
| Recommendation — Inventory and remove accounts that can alter releases or control production. Centralise and retain logs for cloud identities, deploy actions, and secret use. | ||
| SLSA | Supply-chain integrity | CI/CD security here is fundamentally about preserving build and artefact integrity. |
| Recommendation — Enforce provenance and integrity checks before release artifacts reach production. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Runtime monitoring priority depends on the ability to detect malicious production use. |
| IA-5 — Authenticator Management | Both build and runtime paths often fail through unmanaged tokens and keys. | |
| Recommendation — Review alerts and logs that expose suspicious use of production identities. Rotate, expire, and govern authenticators that can reach CI/CD or cloud control planes. | ||
Practitioner Guidance
What to prioritise: Rank the first control by the shortest credible path to production abuse. If a build actor can change what gets deployed, secure the pipeline before expanding runtime analytics; if live identities can already read or mutate production assets, reduce those permissions and improve logging first.
What to verify: Confirm which identities can publish, deploy, approve, assume roles, or access secrets, and whether those actions are attributable and revocable. The right sequence usually becomes obvious once you trace who can actually cause production change today, not who merely appears risky on paper.
Practitioner takeaway: Do not ask whether CI/CD security or runtime monitoring is “better” in general, ask which one most quickly removes attacker reach into production, then fix that layer first.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- Should organisations prioritise external exposure or internal credential governance first?
- How do organisations decide whether to prioritise data discovery, access governance, or runtime monitoring first?
- What breaks when cloud native security is not integrated into CI/CD and runtime controls?