How Third-Party Tools Impact Pipeline Security

Third-party CI/CD tools can become your fastest path to a breach. If a tool can read secrets, publish artefacts, or assume cloud roles, one weak integration can put your code, releases, and production systems at risk.

I’d sum it up like this: the biggest problems are broad permissions, static credentials, mutable version tags, and unsafe pull request workflows. The fixes are plain enough: pin actions and images to fixed SHAs or digests, replace long-lived secrets with OIDC, lock down fork and comment-triggered workflows, and give each tool only the access it needs.

A few numbers make the point fast:

• Only 4% of organisations pin GitHub Actions to a full commit hash
• 71% leave marketplace dependencies unpinned
• 28.65 million new hardcoded secrets were found in public GitHub commits in 2025
• A March 2026 campaign led to about 500,000 stolen credentials and over 300 GB of data loss
• In the TanStack case, attackers published 84 malicious artefacts across 42 packages in six minutes

If I were reviewing pipeline risk today, I’d check these first:

• Which third-party tools can reach secrets or signing rights
• Which workflows still use mutable tags like @v1
• Which jobs run on pull requests, forks, or comments
• Which cloud roles trust GitHub OIDC without strict sub checks
• Which registry and deployment tokens are still long-lived

The core point is simple: the closer a tool sits to secrets, release approval, and cloud access, the more damage a compromise can do. The article shows where that exposure sits across source control, build, release, and deployment, and which controls cut the blast radius first.

What recent research shows about third-party pipeline risk

Recurring attack patterns across studies

Recent incident reports and security research keep landing on the same weak spots. The biggest one is over-permissioned integrations. Teams give tools far more access than they need, then assume those tools are safe. That extra trust creates a direct path to secrets, approvals and release systems.

A close second is long-lived or hardcoded secrets. These are still everywhere, and the numbers are going the wrong way. In 2025, 28.65 million new hardcoded secrets were detected in public GitHub commits - a 34% year-on-year increase [1].

Another pattern shows up in compromised build plugins and CI/CD actions. Attackers are going after the systems that build and test software, not just the application code. That makes sense: these tools often run with higher permissions and can reach secrets that normal application code never sees. If those tools are unpinned, a mutable tag can be switched to malicious code. A routine integration then becomes a trusted route into the pipeline.

The third repeat issue is unsafe pull request execution. Workflows triggered by pull request comments, or those using pull_request_target without tight controls, can let outsiders run arbitrary code in a privileged context. In April 2026, an attacker posted a single curl command in a GitHub pull request comment on the elementary-data project. The workflow interpolated the comment body into a run block, letting the attacker forge a release commit and publish a malicious package to PyPI and GHCR [7].

Where the evidence points to business impact

The business damage from these weaknesses is not small. In March 2026, a single five-day campaign by the group TeamPCP led to the exfiltration of about 500,000 credentials and more than 300 GB of data [6]. The European Commission was among those hit. Roughly 340 GB of uncompressed data was stolen, including 51,992 files of outbound email communications, after its cloud CI/CD pipeline executed a malicious release of the Trivy vulnerability scanner [8].

These incidents are hard to contain for one simple reason: stolen credentials can make malicious artefacts look legitimate. Once a trusted tool is compromised, one workflow can put the whole delivery chain at risk.

That is exactly what happened in May 2026, when the TanStack pipeline was hijacked through cache poisoning and OIDC token extraction. Within six minutes, 84 malicious package artefacts were published across 42 @tanstack/* packages, including @tanstack/react-router, which has 12.7 million weekly downloads. The artefacts carried valid SLSA provenance because they were built by the official pipeline using stolen OIDC tokens [9][10].

Fixing this kind of breach is also harder than patching one flaw and moving on. Teams have to rotate every secret the affected pipeline could reach, across every connected service. That can spread across source control, cloud accounts, registries and deployment systems faster than many firms expect.

Risk also changes by tool type, so the right control depends on what each tool can access.

Risk comparison by tool type

The table below maps common tool categories to the permissions they usually hold, the most likely attack path and the control that matters most. It is meant to help engineering leaders decide where to focus review time first.

The pattern is pretty clear: the more default trust a tool gets, the more damage a compromise can do. IDE extensions may look low risk because they sit on one developer machine, but stolen SSH keys or cloud credentials can push that access far beyond the workstation. Security scanners sit at the other end of the spectrum. They are trusted because they are there to protect the pipeline, which also makes them a prime target.

These risks do not appear in one place only. They show up at source control, build, release and deployment stages. The next step is to map them to the points in the pipeline where they are exposed.

Is Your Pipeline Compromised? The New CI/CD Threat

Where third-party tools create exposure across pipeline stages

Risk isn’t spread evenly across a pipeline. A tool that can only read one repo is a very different problem from a tool that can publish packages or assume cloud roles. Put simply: where a tool sits, and what it can touch, shapes the damage a compromise can do.

Source control, pull requests and workflow execution

Source-control integrations rely on GitHub Apps, OAuth apps, personal access tokens, SSH keys and webhooks [13]. Any of them can become an entry point, especially when forked pull requests or comment-triggered workflows are in play [11][3].

The pull_request_target trigger is one of the clearest danger areas. It runs code from an untrusted fork in the base repository’s privileged context [11]. That means an attacker may gain maintainer-level release rights through GITHUB_TOKEN [11]. Comment-handling logic can go wrong too. An unsanitised PR comment may kick off a release pipeline and hand over that same level of authority [3].

Once a trigger is abused, attention shifts to the build job that handles the untrusted code. That’s often where the blast radius starts to grow.

Build, artefact and release stages

The build stage is often the toughest part to lock down. Dependency managers such as npm and PyPI can run installation scripts, so a malicious update may execute inside a privileged build environment.

A common route is cache poisoning. An attacker can taint the build cache in a lower-privilege job, then wait for a later release workflow to restore that cache and publish the malicious code. The TanStack compromise followed this pattern: cache poisoning and stolen OIDC tokens led to signed malicious artefacts [11].

Publishing tokens are another soft spot. If a registry token sits in a long-lived secret or environment variable, anyone who gets into the runner environment can use it to upload packages directly and skip the pipeline altogether. In March 2026, the LiteLLM PyPI package was compromised in exactly this way. A stolen token was used to upload malicious versions 1.82.7 and 1.82.8, with a payload that triggered credential exfiltration every time the Python interpreter started on an infected host [2].

Once code makes it to release, that same chain of trust often stretches into registries and deployment credentials.

Deployment and cloud authentication

At deployment, third-party access becomes infrastructure access. Tools at this stage often hold, or can reach, cloud credentials, service account keys and deployment roles. When this layer is breached, the damage doesn’t stop in CI/CD - it spills straight into production.

Every vendor credential opens one more route into your systems. Static cloud credentials stored in environment variables are still a major problem. If a vendor is breached, those keys can go straight past your perimeter. In April 2026, ShinyHunters breached Cisco Systems by compromising a third-party vendor that held long-lived AWS CI/CD credentials, which enabled exfiltration of customer-facing source code [12][16].

Short-lived OIDC tokens cut some of the risk tied to static secrets, but only if trust policies check the repository subject claim. Research shows that 30–40% of AWS accounts using GitHub OIDC have trust policy misconfigurations and do not validate the repository subject claim [15]. In March 2026, a threat actor abused this exact gap - a Github-Actions-CloudFormation role with no sub claim condition - to create an Administrator role and take over a full AWS account in under 72 hours [14].

Controls that reduce third-party tool risk

::: @figure {CI/CD Pipeline Security: Third-Party Tool Risk by Stage} :::

The attack patterns above - tag hijacking, credential theft, and unsafe pull request execution - tend to hit the same weak spots again and again. The good news is that most of those weak spots can be shut down, or at least made much harder to abuse, with a focused set of controls.

It helps to split them into two groups:

• Preventive controls, which make compromise harder
• Detective controls, which help you spot trouble fast when something slips through

These controls line up directly with the attack paths already covered: tag hijacking, credential theft, and unsafe pull request execution.

Preventive controls that limit blast radius

Start at the source control layer. Disable pull request triggers from forks, and put comment-triggered actions behind maintainer checks such as CODEOWNERS. These are some of the cheapest and fastest ways to stop unauthorised runner execution before it starts [3].

Next, pin every third-party action and container image to a full commit SHA or digest, not a mutable tag. Tags can move. A full SHA or digest cannot. That one change cuts off a common route for supply-chain tampering.

Credentials need the same treatment. Swap static cloud credentials for OIDC federation. Short-lived, per-run identities mean that even if a credential is stolen, its shelf life is short enough to blunt reuse [1][20].

At build stage, Pipeline Execution Policies (PEPs) can enforce mandatory security jobs [5]. Runner isolation adds another layer by keeping third-party tools inside a narrow context with limited access to secrets and source code [19].

There’s also one fast audit that’s worth doing today: search all workflow files for expressions like toJSON(secrets). Attackers use this to exfiltrate a full secret bundle in a single command [3].

Detective controls that improve visibility and response

Preventive controls do a lot of the heavy lifting, but they won’t catch everything. That’s where detective controls come in. Their main job is simple: cut dwell time.

Runtime monitoring of CI/CD runners can surface unauthorised outbound connections and odd filesystem writes [18]. If an attacker gets code running, those signs often show up before the damage is fully done.

When upstream controls fail, runtime enforcement such as AppArmor profiles becomes the last line of defence. It can block unauthorised system calls or file access from compromised tools [18]. In plain terms, even if a tool turns hostile, it may still be boxed in.

Install-time behaviour checks matter too. They help catch obfuscated payloads that slip past static code review and signature verification [18]. That’s a big deal, because malicious code doesn’t always look suspicious on first inspection.

At the artefact stage, SBOM generation gives teams a live inventory of what is actually inside a build. That makes response far faster when a new vulnerability is disclosed [17]. Continuous lockfile integrity checks add another signal by comparing installed dependencies against committed lockfiles, which helps flag dependency drift before it reaches production.

Control comparison table

Use the table below to match each control to the pipeline stage it protects.

The next step is governance: assign owners, set the rollout order, and define approval rules for each control.

Priorities and next steps for decision-makers

Governance, ownership and next steps

Once controls are in place, the next weak spot is ownership.

Controls don't hold up without clear owners. Someone needs to be accountable for setup, review, and renewal.

Start with an inventory. List every third-party tool connected to your pipelines, what credentials it holds, and what permissions come with those credentials. Keep that inventory live, not tucked away in a spreadsheet no one checks. Every vendor credential creates a second way in, so access needs tight scoping.

From there, the operating model comes down to three parts:

• Set owners, review dates and escalation paths for every integration.
• Tie production access to named approvers and documented rotation steps.
• Assign incident-response ownership for pipeline compromise and secret rotation.

That operating model decides whether the controls above work day to day.

When outside support may help

If remediation capacity is tight, outside support can speed up the audit and rollout.

Prioritisation is simple. Large-scale remediation usually isn't. Replacing legacy static credentials across a mid-size estate typically takes 6–12 weeks [4]. If your team doesn't have the capacity for a full audit, Hokstad Consulting can support pipeline hardening, cloud security reviews, and automation design.

Key takeaways

The practical conclusion is simple.

Third-party tools add the most CI/CD risk when broad permissions, static credentials, and mutable tags show up together. Cut blast radius with least privilege, short-lived identity, immutable pinning, egress limits, and named ownership.

FAQs