How do you detect suspicious curl or netcat use in CI/CD pipeline scripts?

What makes curl and netcat suspicious in pipeline scripts?

In CI/CD, curl and netcat are not inherently bad. They become suspicious when they are used as general-purpose transfer or execution primitives instead of controlled build tooling. The main signals are outbound fetches to untrusted locations, shell piping of remote content into execution, and network listeners or ad hoc data transfer commands that do not match the build step’s stated purpose.

That matters because pipeline scripts run with access to source, artifacts, runners, and often secrets. A command that looks like simple plumbing can hide staging, exfiltration, or a reverse connection. The review question is not whether curl or netcat appears, but whether the command creates a trust boundary crossing that the pipeline does not need.

In practice, suspicious use often shows up as commands that fetch binaries, scripts, or install steps directly from the internet during build time, especially when the destination is uncoded, shortened, dynamically built, or unrelated to the organisation’s approved package sources. The same concern applies when netcat is used to relay files, open listeners, or move data in ways that bypass normal artifact handling, logging, and approval paths.

The safest way to read these patterns is to ask what the script is trying to prove or produce. A legitimate build may download dependencies, but it should do so through known registries, pinned references, and reproducible steps. If the script is pulling arbitrary content and immediately executing it, or using a listener to receive data from outside the normal delivery path, the command deserves closer scrutiny.

Review the surrounding context as well. A curl command used to call a documented internal service is very different from curl embedded in a one-line shell pipeline that fetches a remote script, decodes it, and runs it with broad environment access. Likewise, netcat may be acceptable in a controlled test harness, but it is far more suspect when used to establish an interactive channel, move secrets, or stage payloads from a runner.

Why this pattern is risky in CI/CD

Pipeline scripts are high-trust automation. When they can reach out to arbitrary hosts or create unsanctioned connections, they can bypass the controls that normally protect software delivery. That can expose build secrets, leak source or artifact contents, or let an attacker turn the pipeline into a staging point for later movement into deployment systems.

One useful reference point is the CI/CD Security Guide, which frames pipeline hardening around trusted execution paths, runner isolation, and rules that reduce poisoned pipeline execution.

Suspicious curl and netcat usage also fits the broader pattern described in the Guide to the Secret Sprawl Challenge, because ad hoc transfer and fetch commands often show up where credentials, tokens, and other secrets are easiest to collect.

For an incident-driven example of how pipeline activity can leak secrets when trust is misplaced, see tj-actions/changed-files compromise 2025. The lesson is not the specific tool, but the ease with which a trusted workflow can become a secret-exfiltration path once execution is redirected.

External references are useful here too: SLSA emphasizes build provenance and integrity, which is exactly what arbitrary fetch-and-run patterns weaken. If your pipeline depends on remote content at build time, provenance becomes harder to prove and harder to trust.

How to investigate and triage the command

Start by classifying the command’s role. Is it retrieving a known dependency, moving an artifact, testing connectivity, or doing something the pipeline should never need? Then inspect the destination, the protocol, and the surrounding shell logic. The more a command depends on remote, mutable, or opaque content, the more likely it is to be abusive or fragile.

Look for execution chaining, especially when curl output is piped into bash, sh, python, or another interpreter. That pattern can collapse review time and hide the true payload. With netcat, pay close attention to listeners, reverse shells, port forwarding, and any use that creates a manual transfer channel outside approved artifact storage or CI logging.

Check whether the command touches secrets or environment variables. If the script reads tokens, prints masked values, or sends runner state to a remote endpoint, treat it as a possible exfiltration path even if the command name itself is ordinary. In CI/CD, the dangerous part is often not the utility, but what the utility is asked to deliver or receive.

When the behaviour is legitimate, you should be able to explain it in one sentence and tie it to an approved source, destination, and build purpose. If you cannot justify those three elements, the script should be treated as suspicious until proven otherwise.

Risk and Threat Considerations

Suspicious curl and netcat usage is risky because it can turn a build runner into an outbound control point, an exfiltration path, or a staging host for malicious code. The same primitives that help engineers debug or fetch dependencies also make it easy for attackers to hide in plain sight inside ordinary pipeline syntax.

Failure mechanism: The script downloads or relays remote content outside an approved supply path, then executes it, transfers secrets, or opens a listener that enables interactive control or reverse connection behaviour.

Impact: The pipeline may leak credentials, execute unreviewed code, undermine artifact integrity, or provide a foothold for follow-on compromise of build, release, or deployment systems.

Practitioner Guidance

What to verify: Verify that every curl destination is expected, pinned, and tied to an approved dependency or internal service. Verify that any netcat use has a documented operational purpose and is not being used as a covert transfer or shell mechanism.

Common mistake: Treating curl and netcat as suspicious only when they appear in obviously malicious one-liners. In practice, the most important review signal is whether the command crosses a trust boundary without a clear build justification.

Decision rule: If the command fetches remote executable content, moves secrets, or creates an inbound or reverse connection in a pipeline step that should be deterministic, escalate it for review before the script is allowed to run.

Practitioner takeaway: The command name matters less than the trust boundary it crosses. In CI/CD, a legitimate transfer step is explainable, pinned, and observable, while a suspicious one is remote, mutable, and capable of turning the runner into an attacker-controlled channel.

Related resources from NHI Mgmt Group

• How do you know if your CI/CD pipeline is still exposed to hidden single points of failure?
• What are the signs that credential use in CI/CD is suspicious rather than part of a normal workflow?
• What happens when a CI/CD pipeline is triggered with suspicious behavior and no runtime guardrails?
• How do I implement secrets scanning in a CI/CD pipeline?