PCI DSS internal penetration testing now spans cloud and build pipelines

At a glance

What this is: PCI DSS v4.0.1 broadens internal penetration testing to include cloud, SaaS, and build pipelines when they can influence the cardholder data environment.

Why it matters: This matters because identity paths, not just network paths, now determine whether a segmentation control actually protects the CDE.

Context

PCI DSS internal penetration testing now has to treat the cardholder data environment as an identity and access problem as much as a network one. If cloud accounts, SaaS services, or build pipelines can reach systems that store or process cardholder data, traditional perimeter-style scoping is no longer enough.

The practical issue is segmentation validation. Teams must understand not only where the CDE lives, but also which authenticated paths, third-party services, and deployment systems can alter or reach it. That puts IAM, PAM, workload access, and CI/CD governance directly into PCI scoping decisions.

Key questions

Q: What breaks when PCI segmentation does not cover cloud and CI/CD access paths?

A: Segmentation can appear sound at the network layer while identity-bearing paths still reach the CDE through cloud tenants, SaaS apps, or deployment systems. That means a stolen credential or compromised pipeline can bypass the intended boundary and expose cardholder data without a direct perimeter breach.

Q: Why do authenticated SaaS and pipeline paths increase PCI CDE risk?

A: Because they can function as trusted bridges into systems that store, process, or deploy into the CDE. If a user session, service account, or automation token can alter those systems, the effective security boundary shifts from routing controls to access control and governance over credentials.

Q: What are the signs that PCI internal testing scope is too narrow?

A: Common indicators are a scope that covers only subnets and firewalls, no inventory of cloud components, no review of SaaS access, and no inclusion of build tools that can deploy into CDE-connected systems. If identity paths are missing, the assessment is probably missing the real attack surface.

Q: Who is accountable for deciding whether cloud, SaaS, and pipelines are in PCI scope?

A: The entity must document and confirm scope, but the QSA ultimately judges whether the segmentation evidence is sufficient. Practitioners therefore need a clear ownership chain across security, IAM, cloud, and DevOps so that access paths into the CDE are not left outside the test plan.

Technical breakdown

Why cloud infrastructure enters PCI internal testing scope

PCI DSS v4.0.1 explicitly treats cloud components, virtual components, containers, and orchestration tooling as system components when they can affect the CDE. That matters because a cloud tenant, virtual private cloud, or container platform may host systems that process cardholder data or provide indirect access into it. In practice, this turns cloud inventory into part of the pen test boundary, not just an architecture appendix. The testing question is no longer only whether a segment is routed correctly, but whether an authenticated cloud path can reach or reshape a CDE asset.

Practical implication: include cloud accounts, orchestration layers, and IAM paths in the IPT scope review before segmentation testing begins.

How SaaS and authentication paths affect segmentation validity

The article’s core point is that segmentation can fail even when network controls hold if a stolen credential can authenticate into a SaaS application that stores or exposes cardholder data. That is not a pure network issue. It is an access control failure where authentication and authorization become the effective segmentation layer. For PCI testing, that means pen testers need to assess whether identity-bearing access paths create a de facto bridge into the CDE, especially where business workflows depend on trusted sessions, federated login, or shared service access.

Practical implication: test whether account compromise can bypass network segmentation through SaaS and federated access routes.

Why build pipelines are now part of the attack surface

Build pipelines such as GitHub Actions, Azure DevOps, Jenkins, and cloud build services matter because they can deploy code, inject configuration, or modify objects that ultimately impact the CDE. If an attacker can tamper with a pipeline, they may not need direct network access at all. The relevant mechanism is trusted deployment privilege. In other words, the pipeline becomes an upstream control plane whose compromise can translate into CDE exposure through code, credentials, or infrastructure changes. That makes CI/CD governance part of PCI segmentation evidence, not just DevOps hygiene.

Practical implication: include pipeline trust boundaries and deployment credentials in the same scoping model used for CDE segmentation.

Threat narrative

Attacker objective: The objective is to gain unauthorized access to cardholder data or a path that can affect the CDE without having to break the network boundary directly.

1. Entry occurs through cloud, SaaS, or CI/CD access that is legitimately trusted inside the environment rather than through a simple perimeter breach.
2. Credential access or session reuse allows the attacker to authenticate to systems that should be segmented from the CDE but are still reachable through trusted identity paths.
3. Escalation happens when pipeline control, SaaS storage, or cloud administration privileges let the attacker move from indirect access to a CDE-relevant foothold.
4. Impact is unauthorized reach into cardholder data systems or the ability to alter deployment paths that protect those systems.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PCI scoping has become an identity governance exercise, not just a network test. Once cloud tenants, SaaS applications, and build pipelines are in scope, the decisive question is who or what can reach the CDE through authenticated paths. That changes the control problem from segment maps to entitlement maps. Practitioners should treat PCI scoping as a review of access relationships, not only infrastructure boundaries.

Build pipelines are now security-relevant system components because they control what reaches production. A pipeline compromise can become a cardholder-data exposure path even when the runtime network is tightly segmented. The article shows why deployment systems, service principals, and automation tokens belong in the same governance conversation as firewalls and subnets. Practitioners should evaluate pipeline trust as part of the CDE access model.

Segmentation integrity gap: credentialed access can collapse controls that look effective from the network layer. Bishop Fox’s point is that stolen credentials, reused sessions, and trusted SaaS access can defeat a segment without any obvious routing break. That is a control-assumption problem, not merely a tooling problem. Practitioners should validate whether any identity path can act as an implicit bridge into the CDE.

PCI DSS v4.0.1 pushes assessment teams toward a broader attack-surface model for internal testing. The relevant governance shift is that “in scope” now follows business workflows and control influence, not just physical or virtual location. That aligns with the direction of modern identity security: if access can reach the asset, it is in the security boundary. Practitioners should update scoping playbooks accordingly.

The evidence set for segmentation has to include both technical reachability and identity reachability. Open ports still matter, but so do authenticated paths, third-party access, and automation credentials that can move laterally into the CDE. This is where PCI testing overlaps with IAM and PAM governance. Practitioners should measure segmentation effectiveness against both network and authentication control failure modes.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

PCI DSS scoping now has a clear identity-security dimension: any cloud, SaaS, or automation account that can reach the CDE must be treated as part of the effective boundary. That means IAM, PAM, and CI/CD governance now influence PCI outcomes as directly as firewall design.

Cloud Identity Boundary Drift: once authenticated access paths can reach the CDE, the boundary has drifted from network segmentation into entitlement management. Practitioners should re-evaluate which identities, tokens, and deployment systems can act as implicit trust bridges before the next assessment.

The build-pipeline threat is not theoretical. 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026, which is why pipeline access belongs in PCI scoping and control evidence.

For practitioners

• Map all CDE-relevant identity paths Document every cloud account, SaaS tenant, service principal, and human account that can reach data, applications, or deployment systems tied to the CDE.
• Add CI/CD systems to segmentation scope Treat GitHub Actions, Azure DevOps, Jenkins, and other build tools as in-scope components when they can deploy to or modify CDE-connected systems.
• Test authentication as a segmentation control Validate whether stolen credentials, federated sessions, or shared SaaS access can bypass network isolation and expose cardholder data.
• Separate testing evidence by access path Record the segment, source IP, open ports, and authentication route for each test so the QSA can see whether the control failed at network or identity level.
• Review third-party connections into the CDE Confirm that vendor access, integration accounts, and external automation do not create an undocumented path into systems that store or process cardholder data.

Key takeaways

• PCI DSS v4.0.1 expands internal testing into cloud, SaaS, and CI/CD systems that can influence the CDE, which makes identity paths part of the scope boundary.
• A segmentation assessment that ignores authenticated access can miss the most direct route into cardholder data, especially when stolen credentials or trusted sessions are involved.
• Practitioners should document cloud components, third-party access, and build pipelines as part of the same evidence set used to prove segmentation effectiveness.

Key terms

• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• Segmentation Control: Any technical or administrative measure intended to prevent one environment from reaching another without explicit approval. In PCI testing, this includes firewalls, identity controls, session boundaries, cloud restrictions, and deployment paths, because each can determine whether an attacker can move into the CDE.
• Access Path: An access path is the route an identity uses to reach a resource, whether directly, through a role, via a group, or through inherited permissions. In NHI governance, access-path analysis matters because machine identities often gain broad access through indirect relationships that are easy to miss.
• Build Pipeline: A build pipeline is the controlled set of systems and steps that compiles, signs, tests, and packages software for release. It often holds high-value secrets such as signing certificates, publishing credentials, and cloud tokens. If compromised, it can become the shortest path from a developer environment to a tampered production release.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management in a way that helps practitioners connect identity controls to real-world access paths.If your programme has to prove who and what can reach sensitive systems, this course helps translate identity risk into operating controls.