How do organisations decide whether to import existing CI/CD resources before rebuilding them?

Why This Matters for Security Teams

Deciding whether to import or rebuild CI/CD resources is really a decision about control, continuity, and blast radius. Importing lets teams bring an existing pipeline, runner, or secret store under governance without breaking delivery, which matters when production traffic already depends on it. Rebuilding can improve hygiene, but it also risks hidden dependencies, missed permissions, and avoidable outages. For security leaders, the question is not simply technical cleanup. It is whether the current state can be observed, constrained, and audited fast enough to reduce exposure.

The stakes are higher because CI/CD environments are frequent targets for credential theft and lateral movement. NHIMG research in the Guide to the Secret Sprawl Challenge highlights how quickly exposed secrets persist when they are not revoked, while the CI/CD pipeline exploitation case study shows how compromised delivery tooling can become an enterprise-wide foothold. NIST Cybersecurity Framework 2.0 reinforces the need to identify, protect, detect, respond, and recover in a way that matches operational risk, not idealised design.

In practice, many security teams discover the cost of rebuilding only after a fragile pipeline has already been taken offline or quietly bypassed by developers.

How It Works in Practice

The first step is to classify the resource by operational maturity. If the pipeline, repository integration, runner, artifact store, or secret backend is actively supporting production and behaves consistently enough to model, import is usually the safer path. The purpose is to capture the real configuration as code, then tighten it through policy, review, and drift detection. If the resource is deeply inconsistent, undocumented, or stitched together from one-off exceptions, rebuilding may be faster than trying to codify technical debt.

A practical import decision usually follows this sequence:

• Inventory the resource and identify its dependencies, especially credentials, webhooks, service accounts, and runner privileges.
• Determine whether the current state can be represented faithfully in code without introducing guesswork.
• Check whether importing will preserve service continuity while reducing standing risk.
• Confirm that secrets and tokens can be rotated or reissued after import.
• Use policy-as-code to enforce least privilege, approval gates, and change tracking after the resource is under management.

This is where current guidance suggests treating CI/CD as a security boundary, not just an engineering convenience. The NIST Cybersecurity Framework 2.0 provides the governance backbone, while the Guide to the Secret Sprawl Challenge is a useful reminder that secrets embedded in delivery tooling often outlive the original system owners. One relevant data point from GitGuardian's The State of Secrets Sprawl 2026 notes that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why import without rotation is only partial remediation.

These controls tend to break down when the pipeline is already entangled with unmanaged manual steps, hard-coded credentials, or undocumented cross-team approvals because the imported state cannot be trusted as a clean source of truth.

Common Variations and Edge Cases

Tighter import controls often increase short-term effort, requiring organisations to balance delivery continuity against the cost of normalising legacy infrastructure. That tradeoff is most visible in older pipelines where every release path is slightly different, or where security tooling has been layered on top of inconsistent permissions. In those cases, import can still work, but only if the team accepts that the first objective is governance coverage, not perfection.

Best practice is evolving for environments that use ephemeral runners, shared templates, or infrastructure-as-code across multiple teams. A pipeline may be worth importing even when parts of it will later be rebuilt, because importing the current state lets the team establish a controlled baseline. Rebuild is more defensible when the resource has unclear ownership, repeated drift, or evidence of secret leakage that cannot be cleaned up safely in place. That is especially true in environments exposed to supply chain compromise, as seen in NHIMG coverage such as the Reviewdog GitHub Action supply chain attack and the JetBrains GitHub plugin token exposure.

There is no universal standard for this yet, but the safest rule is simple: import when continuity and observability matter more than redesign speed, and rebuild when the current state cannot be trusted as a secure baseline.

Related resources from NHI Mgmt Group

• How do organisations decide whether to import existing cache resources or recreate them under Terraform?
• How do organisations decide whether to prioritise certificate automation before the next validity reduction?
• How do organisations decide whether privileged access management should replace or complement existing IAM tools?
• How do organisations decide whether to add authorization before scaling AI applications?