CI/CD Platform Security Requirements for Buyers

A CI/CD platform runs untrusted code next to your most powerful credentials, so the platform you choose decides how far one malicious pull request, stolen token or compromised runner can reach. Build systems hold cloud deployment roles, package registry tokens, signing keys and production secrets, and they execute code from contributors, dependencies and third-party actions or plugins. Breaches at CI providers and in popular pipeline components have shown that these risks are real and shared across every customer. This vendor-neutral guide sets out the security requirements to write into a CI/CD platform selection, whether SaaS, self-hosted or hybrid, with evaluation criteria, vendor questions, red flags and a pilot plan. It is for platform engineering, DevSecOps and procurement teams. Securing pipelines you already run is covered in the CI/CD Security Guide, and tools that scan or protect pipelines in the CI/CD Security Tooling Buyer's Guide.

Key takeaways

Short-lived workload identity is the top requirement. The platform should issue per-job OIDC tokens with rich claims so cloud and registry access needs no stored long-lived secrets.
Isolation decides blast radius. Ephemeral, single-use runners and separation between jobs, projects and trust levels matter more than any scanning feature.
Flow control must be enforceable centrally. Protected branches, required reviews, protected environments and approval gates must apply to pipeline definitions as well as code.
Provenance should come from the platform, not the build script. Look for platform-generated, signed build provenance that meets SLSA Build Level 2 or, better, Level 3.
Audit everything the platform does with identity. Token issuance, secret access, permission changes and runner registration must be logged and exportable.

Define requirements

Code sources and trust levels: internal repositories only, or also public repositories and forks that accept outside contributions. Untrusted contributions require hard separation from secrets and privileged runners.
Deployment targets: list each cloud account, cluster, registry and SaaS the pipelines deploy to, and whether each supports federation with the platform's OIDC tokens. See the Workload Identity Federation Guide.
Runner model: vendor-hosted runners, self-hosted runners in your network, or both. Self-hosted runners that reach internal systems are high-value targets. See Self-hosted CI/CD Runners and Build Agents.
Extensions: marketplace actions, plugins, orbs or templates you expect to use, and who may approve new ones.
Artefact integrity needs: whether you must produce signed artefacts, build provenance, SBOMs or attestations for customers or regulators. NIST SP 800-204D sets out strategies for integrating supply chain security into DevSecOps pipelines.
Regulatory and customer drivers: secure development expectations such as NIST SSDF (SP 800-218), and supplier requirements under NIST CSF 2.0 GV.SC-05.
Operating capacity: whether you can patch and harden a self-hosted controller quickly. The TeamCity CVE-2023-42793 exploitation showed internet-facing build servers being used as a supply chain foothold.

Capability areas

Area	What good looks like	OWASP CI/CD risk addressed
Workload identity	Per-job OIDC tokens with claims for repository, branch or tag, environment, workflow and run; configurable audience; tokens available only to jobs that request them	CICD-SEC-6 Insufficient Credential Hygiene
Secrets management	Secrets scoped to project, environment and branch; not exposed to fork or untrusted builds; masked in logs; integration with external secrets managers; rotation support	CICD-SEC-6
Job token permissions	Built-in job tokens read-only by default with per-job elevation; tokens expire at job end	CICD-SEC-5 Insufficient PBAC
Runner isolation	Ephemeral single-use runners, VM or strong sandbox isolation, separate runner pools per trust level, no shared caches across trust boundaries	CICD-SEC-5, CICD-SEC-7
Flow control	Protected branches and environments, required reviewers, approvals for first-time or fork contributors, protection of pipeline definition files	CICD-SEC-1 Insufficient Flow Control Mechanisms, CICD-SEC-4 Poisoned Pipeline Execution
Third-party component governance	Allow lists for actions, plugins and images; pinning to immutable references (commit SHA or digest); organisation-wide policy enforcement	CICD-SEC-8 Ungoverned Usage of 3rd Party Services, CICD-SEC-3 Dependency Chain Abuse
Artefact integrity	Platform-generated signed provenance, keyless or managed signing, attestation storage and verification	CICD-SEC-9 Improper Artifact Integrity Validation
Human identity and access	SSO with MFA, SCIM provisioning, granular roles, short session lifetimes for the console, fine-grained and expiring personal tokens	CICD-SEC-2 Inadequate Identity and Access Management
Audit logging	Streaming audit logs for permission changes, secret access and changes, runner registration, token creation and policy changes	CICD-SEC-10 Insufficient Logging and Visibility
Secure configuration	Secure defaults, organisation-level policy, hardening guide for self-hosted controllers, supported upgrade path	CICD-SEC-7 Insecure System Configuration

Where identity fits

A CI/CD platform is an identity provider for workloads. Every job is a non-human identity that may receive a cloud role, registry write access or a signing capability. Prefer platforms where that identity is short-lived and described by verifiable claims. GitHub's documentation, for example, describes a per-job token whose subject and other claims are checked against conditions on the cloud role, which returns an access token valid only for that job, so cloud credentials no longer need to be stored as long-lived secrets. Ask every vendor to show the equivalent and to explain which claims your trust policies can pin. Long-lived personal access tokens, deploy keys and service account keys in pipelines are the main credential risk to design out. See the CI/CD Pipeline Identity Security Guide and the Workload Identity Federation Trust Review Checklist.

Deployment models compared

Model	Strengths	Security concerns	Fits best
SaaS controller with vendor-hosted runners	Vendor patches controller and runners; ephemeral runners often default	Shared provider risk: a provider breach can expose every customer's secrets; limited network reach to private targets	Most organisations, especially smaller teams
SaaS controller with self-hosted runners	Runners reach private networks; you control runner hardening	Runner persistence and lateral movement into your network; runner registration token handling	Hybrid estates with private deployment targets
Self-hosted controller and runners	Full control of data location and network exposure	You own controller patching, plugin governance and backups; internet-exposed controllers are actively targeted	Regulated or air-gapped environments with mature platform teams

Small vs large organisations: small teams usually do best with a SaaS platform, vendor-hosted ephemeral runners and OIDC federation to their cloud, because these remove the hardest operating work. Large organisations need organisation-wide policy enforcement, multiple runner pools by trust level, audit log streaming and delegated administration, and should weight those heavily.

Evaluation criteria

Criterion	Suggested weight	Evidence to request
Workload identity and secrets	20%	OIDC claim reference, secret scoping model, demo of fork build without secret access
Runner isolation	20%	Isolation technology, ephemeral runner support, runner pool policy controls
Flow control and policy enforcement	15%	Branch and environment protection settings, organisation policy options
Third-party governance	10%	Allow list and pinning enforcement, marketplace review process
Provenance and signing	10%	SLSA Build level claimed and how it is met, sample provenance
Human access	10%	SSO, MFA, SCIM, token types and expiry controls
Audit logging	10%	Event catalogue, streaming options, retention
Supplier assurance	5%	VDP, incident history and disclosure, CVE record quality

Weights are an NHI Mgmt Group starting point; raise runner isolation if you build public or third-party code.

Questions to ask vendors

Does every job receive a short-lived OIDC token? Which claims does it carry, can we set the audience, and can we restrict which jobs may request it?
How are secrets protected from builds triggered by forks or first-time contributors? Show it.
Is the built-in job token read-only by default, and can we enforce that across the organisation?
What isolation separates jobs from each other: separate virtual machines, containers or processes? Are vendor-hosted runners single-use?
Can changes to pipeline definition files require review from a specific group before they run with secrets?
Can we enforce an allow list of actions, plugins or images and require pinning to a commit SHA or digest?
Does the platform generate and sign build provenance itself, and which SLSA Build level do you claim? Can user-defined build steps reach the signing key?
Which audit events can we stream to our SIEM, and how quickly?
If your platform were breached, which customer secrets could be exposed, and how would you notify us? What did your last security incident disclosure contain?
For self-hosted components, what is your patch timeline for critical vulnerabilities and how do you notify customers?

Red flags

No OIDC or equivalent federation, so cloud access needs long-lived keys stored as secrets.
Secrets available to pull request builds from forks by default.
Persistent shared runners reused across projects or trust levels by default.
Job tokens with write access to repositories or packages by default.
No way to restrict third-party actions or plugins, or no support for immutable pinning.
Audit logs limited to a UI view, short retention or a premium tier.
Plugin ecosystems with no security review and unsigned plugin updates.

Common failure patterns

Provider breach exposes every customer's secrets: in the CircleCI breach, a stolen SSO session led to customer secrets being exposed and every customer had to rotate. Short-lived OIDC credentials limit what a provider breach can yield.
Trusting a mutable third-party component: the tj-actions/changed-files compromise pushed malicious code through tags that thousands of workflows referenced, leaking secrets into logs. Require allow lists and SHA pinning. See How to Pin GitHub Actions to Commit SHAs.
Poisoned pipeline execution: the Ultralytics PyPI compromise combined a workflow injection with a leftover publishing token (ATT&CK T1677 Poisoned Pipeline Execution).
Modified build scripts harvesting secrets: the Codecov breach altered a script that CI pipelines downloaded and ran, sending environment variables to the attacker.
Self-hosted runners on public repositories: GitHub's own guidance says self-hosted runners should almost never be used for public repositories because untrusted workflow code can persistently compromise them.
Internet-facing controllers left unpatched: build servers exploited through known vulnerabilities become a launch point for supply chain attacks, as with TeamCity CVE-2023-42793, which is on the CISA Known Exploited Vulnerabilities catalogue.

Proof of concept

Set up a pilot organisation with two repositories: one internal, one accepting outside contributions from a test fork.
Federate to a test cloud account with OIDC, with a trust policy pinned to repository, branch and environment. Confirm a job on another branch is refused.
Test fork safety: open a pull request from the fork that tries to print secrets and request an OIDC token. Both should fail, and the run should need approval.
Test pipeline definition protection: change a pipeline file on a feature branch to add a deployment step; confirm it cannot reach protected environments without review.
Test third-party controls: reference an action, plugin or image not on the allow list, and one pinned to a tag rather than a SHA or digest. Both should be blocked by policy.
Test runner isolation: write a file to the runner in one job and look for it in the next; on ephemeral runners it should be gone.
Test provenance: generate and verify signed provenance for a build artefact, and confirm build steps cannot read the signing material.
Test audit logging: stream audit events to your SIEM and confirm secret changes, permission changes and runner registrations appear.
Test revocation and rollback: revoke a runner and a personal token, and roll a deployment back using the platform's environment history.

Detection and measurement after selection

Alert on new self-hosted runner registrations, changes to organisation security policy, new secrets in production environments, OIDC tokens requested from unexpected repositories or branches, and personal tokens with broad scopes. Useful measures:

Percentage of deployments authenticated with OIDC rather than stored secrets.
Number of long-lived cloud or registry credentials stored in the platform, trending to zero.
Percentage of third-party actions or plugins pinned to immutable references.
Percentage of jobs on ephemeral runners.
Percentage of release artefacts with verified signed provenance.

Framework mapping

Requirement	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK technique addressed
Short-lived workload credentials	IA-5 Authenticator Management	PR.AA-01	T1552.001 Credentials In Files, T1528 Steal Application Access Token
Least privilege job tokens and roles	AC-6 Least Privilege	PR.AA-05	T1078.004 Cloud Accounts
Flow control and change review	CM-3 Configuration Change Control, SA-10 Developer Configuration Management	PR.PS-06	T1677 Poisoned Pipeline Execution
Provenance and artefact integrity	SR-4 Provenance, SI-7 Software, Firmware, and Information Integrity	PR.PS-06	T1195.002 Compromise Software Supply Chain
Supplier requirements	SA-4 Acquisition Process, SA-9 External System Services	GV.SC-05	T1199 Trusted Relationship
Audit of platform actions	AU-2 Event Logging, AU-9 Protection of Audit Information	DE.CM-09	T1078.004

In NIST SSDF (SP 800-218), practices PO.5 (implement and maintain secure environments) and PS.1 (protect all forms of code from unauthorised access and tampering) apply directly to the build platform. CIS Controls v8.1 Control 16 (Application Software Security) is the closest control-level fit.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support, with a focus on the workload identities and secrets that build platforms create and hold. Browse vendors in our products directory or contact us about independent evaluation support.

Security Requirements for Selecting a CI/CD Platform: Criteria, Vendor Questions and Pilot Tests