DORA Article 28 requires financial entities to manage risks introduced by ICT third-party service providers.
In modern software delivery, CI/CD pipelines are among the most third-party–dependent systems in the organization.
Git platforms, CI runners, plugins, and artifact registries are not just tooling choices — they are embedded external services that directly influence software integrity, availability, and operational resilience.
This article focuses specifically on third-party risk within CI/CD pipelines, explaining where these risks arise, how DORA Article 28 applies, and which controls auditors expect to see enforced.
Why CI/CD Pipelines Are a Third-Party Risk Concentration Point
CI/CD pipelines aggregate multiple external dependencies into a single execution flow:
- source code is hosted externally,
- builds often run on shared or managed infrastructure,
- third-party code is pulled automatically,
- artifacts are stored and distributed by external services.
From a DORA perspective, CI/CD pipelines represent:
- high-impact ICT dependencies,
- with privileged access,
- operating at machine speed,
- and capable of propagating failures or compromises directly into production.
As a result, CI/CD platforms must be treated as in-scope ICT third-party services under Article 28.
GitHub / GitLab SaaS as ICT Third-Party Providers
Risk exposure
GitHub and GitLab SaaS platforms control:
- access to source code,
- change approval workflows,
- identity and permission enforcement.
Compromise or misconfiguration can lead to:
- unauthorized code changes,
- bypassed approvals,
- loss of traceability.
Article 28 expectations
Auditors expect:
- Git hosting platforms listed in the third-party inventory,
- clear risk classification (often critical),
- enforcement of segregation of duties,
- evidence of access control and approvals.
Access logs, pull request approvals, and branch protection settings are treated as audit evidence, not operational details.
Cloud-Based CI Runners
Risk exposure
Managed or cloud-hosted CI runners:
- execute untrusted code,
- access secrets and credentials,
- interact with internal and external systems.
They often run on shared infrastructure, increasing exposure.
Article 28 expectations
Under Article 28, organizations must demonstrate:
- isolation between runners,
- controlled access to secrets,
- monitoring of execution environments,
- ability to restrict or revoke runner access.
Auditors frequently ask:
“Who controls the execution environment where your code is built?”
Marketplace Actions and Plugins
Risk exposure
CI/CD marketplaces introduce unvetted third-party code directly into pipelines.
Risks include:
- supply chain attacks,
- malicious updates,
- lack of version control,
- unclear ownership.
Article 28 expectations
Auditors expect:
- governance over which plugins are allowed,
- risk assessment for critical actions,
- version pinning and review processes,
- monitoring of changes over time.
Unrestricted marketplace usage is often flagged as a major Article 28 weakness.
Artifact Registries
Risk exposure
Artifact registries store and distribute:
- build outputs,
- container images,
- internal libraries.
If compromised, they can:
- propagate malicious artifacts,
- break deployment integrity,
- affect multiple systems simultaneously.
Article 28 expectations
Auditors expect controls covering:
- access restrictions,
- immutability policies,
- artifact signing and verification,
- retention of artifact metadata.
Artifact registries are treated as core supply chain components, not passive storage.
Dependency Proxies and External Repositories
Risk exposure
Dependency proxies and external repositories:
- pull code from outside the organization,
- introduce indirect third-party dependencies,
- may change content without notice.
This creates hidden third-party exposure.
Article 28 expectations
Auditors expect:
- visibility into dependency sources,
- controls to restrict or cache external dependencies,
- traceability linking dependencies to builds,
- monitoring of dependency changes.
SBOMs and dependency logs are often reviewed as Article 28 evidence.
Core CI/CD Controls Expected Under Article 28
Across all CI/CD-related third-party services, auditors expect to see:
- explicit inclusion in third-party inventories,
- risk-based classification and governance,
- access isolation and least privilege,
- enforceable policies (approvals, gates),
- continuous monitoring,
- automated evidence generation.
CI/CD pipelines should enforce these controls by design, not via manual procedures.
Evidence Auditors Commonly Request
For CI/CD third-party risk, auditors frequently request:
- access logs from Git platforms,
- CI execution logs and runner metadata,
- approval records and policy gate results,
- artifact signing and provenance data,
- monitoring alerts involving CI/CD services.
These artefacts are used to validate that controls are operating, not just defined.
Relationship with Other DORA Article 28 Controls
CI/CD pipelines often act as the enforcement layer for:
- contractual requirements,
- security policies,
- exit strategy constraints.
They bridge legal, security, and engineering domains — making them central to Article 28 compliance.
Key Takeaway
Under DORA Article 28, CI/CD pipelines are not neutral automation tools.
They are high-risk ICT third-party integration points.
Organizations that:
- explicitly govern CI/CD third-party services,
- enforce controls within pipelines,
- and generate continuous evidence
are significantly better positioned to pass Article 28 audits and manage real operational risk.
Related Content
- DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
- DORA Article 28 Evidence Pack — What to Show Auditors
- CI/CD Security Checklist for Enterprises
- CI/CD Audit Red Flags
