How should security teams secure CI/CD pipelines against man-in-the-middle attacks when dependencies and scripts are fetched dynamically?

Security teams should require TLS for every fetch, validate checksums before execution, and sign artifacts so provenance can be verified end to end. They should also isolate runners, remove unnecessary shell access, and block unauthenticated downloads. The main goal is to prevent attackers from modifying dependencies, build scripts, or artifacts while they are in transit.

Why This Matters for Security Teams

Dynamic fetching turns the build path into a live trust boundary. Every dependency pull, script download, package install, and bootstrap action becomes a point where an attacker can tamper with code before it is compiled, tested, or deployed. That is why supply chain controls are as important here as network controls, especially when pipelines pull from public registries, transient mirrors, or developer-maintained endpoints.

The practical risk is not limited to classic packet interception. A man-in-the-middle attack can also abuse compromised proxies, poisoned DNS resolution, malicious redirects, or a weakened internal artifact service. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for integrity checks, secure transport, and controlled software provenance, which are all central when build systems fetch code dynamically.

Security teams often get this wrong by focusing only on secret storage or runner hardening while treating package retrieval as routine plumbing. In practice, many security teams encounter pipeline compromise only after a trusted build has already promoted tampered code into downstream environments, rather than through intentional provenance verification.

How It Works in Practice

The strongest pattern is to assume that every external fetch is untrusted until it is authenticated, verified, and recorded. TLS is necessary, but it is not sufficient on its own because a valid transport session does not prove that the content is the intended content. Teams should combine transport protection with artifact signing, checksum validation, pinned versions, and trusted repository policies so that build steps can detect tampering even if a network path is intercepted.

At a minimum, security teams should implement:

• Verified package sources with allowlisted registries, repositories, and script origins.
• Checksum or signature validation before execution, not after install.
• Immutable or reproducible builds where possible, so a later rebuild can confirm the same output.
• Isolated runners with no interactive shell access unless explicitly required.
• Outbound egress restrictions to reduce the chance of silent fetches during build time.
• Logging that records what was fetched, from where, by which pipeline, and under which identity.

That last point matters because pipeline identity is often the control plane for trust decisions. If a CI job can impersonate another job, reuse overly broad tokens, or call internal artifact services without least privilege, an attacker can pivot from one build step into others. This is where identity governance intersects with CI/CD security: service accounts, workload identities, and secrets should be scoped to the narrowest possible pipeline function, not treated as shared infrastructure credentials.

For attack-pattern context, the MITRE ATT&CK Enterprise Matrix is useful for mapping techniques such as trusted developer tooling abuse, command execution, and software deployment compromise. Where the pipeline also consumes AI-generated code or AI-assisted build steps, current guidance suggests adding provenance checks around model outputs and prompt-driven automation as well, since the attack surface extends beyond conventional dependencies. These controls tend to break down when builds rely on ad hoc scripts from ephemeral endpoints because content verification cannot be enforced consistently.

Common Variations and Edge Cases

Tighter verification often increases build friction and maintenance overhead, requiring organisations to balance release speed against confidence in what the pipeline executes. That tradeoff is manageable for stable, curated dependencies, but it becomes harder in environments with rapidly changing open source components, internal mirrors, or developer-created bootstrap scripts.

There is no universal standard for every edge case yet. For example, some teams can pin and sign all first-party artifacts but still need controlled exceptions for third-party installers or temporary migration scripts. In those cases, best practice is evolving toward compensating controls such as isolated staging networks, short-lived credentials, and explicit approval gates for any non-reproducible fetch.

Dynamic script execution is especially risky when the script itself is generated at runtime, fetched from a raw URL, or assembled by another automation layer. This is also where incident response matters: if a build system fetched altered code, teams need enough logging to reconstruct the path, identify which downstream artifacts were affected, and rotate any credentials exposed during the run. CISA cyber threat advisories are a useful reference point for tracking active supply chain tradecraft and hardening priorities. The guidance becomes less reliable in highly distributed build farms with unmanaged developer runners because consistent attestation and enforcement are difficult to sustain.

Related resources from NHI Mgmt Group

• How should teams secure CI/CD pipelines against identity-based attacks?
• How should security teams secure GitLab access from CI/CD pipelines?
• How should security teams govern open source dependencies in CI/CD pipelines?
• How should security teams govern credentials used by CI/CD pipelines?