A CI/CD pipeline is a privileged production system. It can read source code, retrieve secrets, create trusted artefacts and deploy to customer environments. Security must cover developer identity, local tooling, repositories, dependencies, workers, provenance, deployment authority and incident recovery.

The objective is not to add a scanner everywhere. It is to prevent an untrusted change from becoming a trusted release.

Developer identity and endpoints

Require phishing-resistant MFA where feasible for source control, cloud and privileged systems. Separate daily accounts from emergency access.

Govern developer extensions and repository applications that can read code or tokens. Keep devices patched and encrypted. Removing a malicious workflow after execution does not revoke stolen credentials.

Repository governance

Protect important branches. Require accountable review. Restrict who can modify workflow files, deployment definitions and dependency policies.

Use ownership rules for sensitive paths but do not treat automated assignment as meaningful review. Prevent self-approval for high-risk changes. Protect release tags.

Secrets and workload identity

Prefer short-lived workload-bound credentials over long-lived cloud keys. Apply least privilege. Separate environments where blast-radius reduction justifies it.

Continuously scan history and artefacts for secrets. On exposure, revoke and rotate; deletion from the branch is insufficient.

Dependencies and inputs

Maintain a dependency inventory and update policy. Verify package origin, lock files and registries. Restrict install scripts and untrusted build steps where possible.

Use vulnerability, exploitability, reachability, exposure and business impact to prioritise. Treat update bots as privileged actors.

Build isolation

Use clean, ephemeral workers for sensitive builds. Prevent untrusted pull-request code from receiving production credentials.

Separate build and deployment so compilation does not automatically grant production authority. Record builder, source revision, parameters and output digest.

Artefacts and provenance

Store artefacts in controlled registries. Promote immutable references. Scan the artefact that will deploy, not only source code.

Use signing or provenance attestations where supported. Verify policy before deployment. SLSA provides a framework for supply-chain integrity; apply an appropriate level rather than adopting labels without value.

Deployment authority

Separate approval from execution for material changes. Use environment protection, time-bounded credentials and narrow roles.

Protect infrastructure-as-code as seriously as application code. A one-line permission change can have more impact than a feature.

Verification and rollback

Require risk-based tests and policy gates. A failing critical gate must block release.

Use staged rollout and stop conditions. Keep rollback procedures current and test database compatibility.

Observability and recovery

Log authentication, workflow changes, secret access, artefact creation, deployment, overrides and cloud permission changes.

Create a compromise runbook covering containment, rotation, artefact invalidation, affected releases, forensics and customer impact.

Minimum review

Who can change the pipeline?

What untrusted input can execute?

Which credentials can each stage obtain?

Can a pull request reach production secrets?

How is an artefact tied to source and builder?

What is verified before deployment?

Can the team identify every release produced during a compromise?

How quickly can credentials be revoked?

Can production restore a known-good artefact?

Who owns the control system?

Implementation sequence

Days 1–10: Inventory repositories, workflows, apps, runners, registries, credentials and environments.

Days 11–30: Fix critical identity, secret and untrusted-execution paths.

Days 31–60: Add provenance, promotion, environment controls and evidence retention.

Days 61–90: Exercise compromise response and measure exceptions.

Evidence that the pipeline is actually safer

Test identity boundaries

Demonstrate that pull-request code cannot obtain production credentials, that human and workload identities are distinct and that privileges expire. Review the path an attacker would use after compromising a developer account or third-party action.

Verify the released artefact

A production release should be traceable to reviewed source, an approved workflow and a known builder. Rebuilds should not silently change dependencies, and deployment should verify provenance rather than trust a filename or registry location.

Exercise recovery, not only prevention

Revoke credentials, quarantine a runner, block a compromised dependency and restore a known-good artefact in a controlled exercise. Record detection time, decision owner and recovery time. Controls that have never been exercised remain assumptions.

Threat-model the delivery system

Map source repositories, registries, runners, artefact stores, cloud control planes and production environments. Record the identities crossing each boundary and the consequence of compromise. Consider stolen developer sessions, malicious pull requests, poisoned dependencies, compromised build images, leaked tokens and insider misuse. Trace how untrusted input could reach signing, deployment or customer data.

Turn the model into testable outcomes: reviewed changes, isolated execution, least-privilege identities, verified artefacts, controlled deployment and recovery. A collection of security tools is not a secure pipeline if nobody can demonstrate which attacker path each control interrupts.

Repository and change control

Protect release branches and high-consequence workflow, infrastructure and ownership files. Require review, passing checks and restricted bypass. Use strong authentication, rapid offboarding and separate emergency administration. Repository applications and automation tokens are privileged integrations and need ownership, scope review and removal when unused.

Treat forked and untrusted pull requests as hostile. Do not expose production secrets or privileged self-hosted runners before trust is established. Separate validation of untrusted code from release workflows and ensure a pull request cannot modify the very checks used to approve it without independent review.

Dependencies and builders

Lock dependencies and actions to reviewed versions or immutable references where practical. Control package sources and monitor unexpected ownership or release changes. Updates should produce a reviewable change rather than silently alter the next build. Version compilers, base images and tooling so an artefact can be reproduced and investigated.

Prefer clean, ephemeral builders and restrict network access and credentials to what each stage needs. Persistent runners require isolation, patching and detection because one job can contaminate the next. Generate component inventories and provenance from the build rather than reconstructing them after an incident.

Secrets and workload identity

Replace reusable cloud credentials with narrowly scoped, short-lived workload identities where the platform supports them. Bind access to repository, workflow, environment and branch context. Separate development, test and production identities; a test job should not inherit production access for convenience.

Scan repositories and histories, but also monitor credential use and keep a rapid revoke-and-reissue procedure. Identify downstream systems that trusted a leaked token. Removing a secret from the latest commit does not end exposure, and rotation without reducing privilege leaves the same attack valuable next time.

Artefact and deployment integrity

Build once, test the resulting artefact and promote that same immutable object. Rebuilding for production can introduce different dependencies or code. Store hashes, inventory and provenance with retention suitable for investigation. The deployment system should verify source, builder, approvals and policy instead of trusting a filename or registry location.

Separate authority to create an artefact from authority to release it. Use progressive delivery where the application supports it and tie progression to technical and business indicators. Preserve a known-good artefact and design database compatibility because application rollback cannot reverse every data change.

Vulnerability policy and recovery

Severity is an input, not the complete decision. Consider reachability, privilege, exposure, mitigations and asset importance. Define a small set of conditions that always stop release. Every exception needs an owner, justification, compensating control and expiry; a permanent ignore file is not governance.

Exercise compromise response: revoke a credential, quarantine a runner, block a dependency and restore a known-good artefact. Measure remediation time, exception age, credential lifetime, provenance coverage and recovery results. The aim is fewer exploitable paths and dependable delivery, not a larger volume of alerts.

A control-by-control implementation checklist

For source control, verify protected changes, reviewer independence, administrator use and external-contribution isolation. For builds, verify pinned inputs, ephemeral execution, restricted network paths, component inventory and reproducibility. For identity, verify short-lived credentials, environment separation and rapid revocation. For artefacts, verify immutable promotion, provenance and retention. For deployment, verify policy, approvals, progressive exposure, database compatibility and rollback.

Each control needs an owner, test method, evidence location and review trigger. Test the negative path: attempt to deploy an unapproved artefact, request production credentials from an untrusted job, use an expired exception and run a vulnerable dependency past policy. Record whether prevention, detection and response worked. Repeat after material changes to runners, cloud identity, registries or release architecture. This turns pipeline security from a diagram into an auditable operating capability.

Secure developer tooling around the pipeline

The attack surface extends beyond workflow files. Inventory developer workstations, command-line credentials, IDE extensions, AI coding assistants, repository applications, chat-based deploy bots and cloud consoles. Determine which tools can read private code, modify branches, approve changes or reach production. Apply device controls, least privilege and data-handling rules according to consequence instead of treating every tool as equally trusted.

For AI-assisted development, define what code and data may be sent to a provider, how generated dependencies are reviewed and which tests are mandatory before merge. Generated code should enter the same review and security process as human-written code. The risk is not its origin alone; it is speed and volume exceeding the team’s ability to understand what enters the trusted build.

Protect release communications and emergency processes. An attacker who controls a chat account or support channel should not be able to trigger production action without independent identity and policy checks. Break-glass access needs strong authentication, time limits, alerting and retrospective review. Practise using it so teams do not create an unofficial bypass during a real incident.

Include vendors and managed services in response planning. Know how to disable repository applications, rotate registry access, suspend a runner fleet and obtain provider audit evidence. Maintain offline contact and ownership information for high-consequence dependencies. A pipeline is resilient when compromise can be contained without losing the ability to build, verify and restore software.

What good looks like

A secure delivery system lets developers ship routine changes without broad standing privilege while making exceptional access visible. Reviewed source produces a traceable artefact in an isolated environment; policy verifies that artefact before progressive deployment; monitoring detects customer impact; and responders can revoke identity and restore a known-good release. Teams can explain exceptions, reproduce evidence and practise recovery. That outcome matters more than the number of scanners installed. Review the model after material changes to repositories, runners, cloud accounts, AI tooling, registries or production architecture.

For regulated or high-consequence products, connect pipeline evidence to the wider control environment. Show how change approval, separation of duties, asset inventory, vulnerability response, logging and incident management operate together. Preserve evidence automatically where possible, but ensure reviewers can understand it without proprietary dashboard access. Audit readiness should follow from dependable engineering behaviour; it should not require teams to recreate history immediately before an assessment.

Keep the control set proportionate to product risk, but do not waive identity isolation, artefact verification or recovery merely because the engineering team is small. Simpler implementation is acceptable; invisible privilege and untested recovery are not.

Scenario: containing a compromised dependency before it becomes a production incident

A commonly used package releases a malicious update that is pulled into a build. In a weak pipeline, an unpinned dependency changes silently, the runner has broad network and cloud access, and production receives an artefact whose inputs cannot be reconstructed. Investigation begins only after unusual behaviour appears. The incident becomes difficult to contain because teams do not know which builds used the package, which credentials were exposed or which customers received the release.

In a stronger design, lockfile and dependency-update controls create a reviewable change. The build runs in an isolated ephemeral environment with no production deployment credential. It produces a component inventory, provenance and immutable artefact. Policy prevents deployment when the dependency violates an approved condition, or the security team can rapidly identify affected artefacts when new intelligence emerges. Promotion verifies the exact artefact instead of rebuilding from the same compromised input.

Response still matters because prevention will never be perfect. The team blocks the package source, revokes any credentials available to the affected builder, quarantines runners, searches logs for attempted access and restores a verified release. Application and business monitoring confirm whether customer activity changed. Engineering records the decisions, evidence and communication rather than treating replacement of the package as the end of the incident.

The post-incident review asks why the dependency was trusted, which control detected it, how long containment took and whether exceptions or ownership delayed action. Improvements may include narrower egress, stronger pinning, registry policy, credentialless builds or faster artefact discovery. This scenario illustrates the purpose of secure CI/CD: preserve the ability to deliver and recover trustworthy software when a developer tool, dependency or identity can no longer be trusted.

Questions for a CI/CD security assessment

Ask the assessor to trace concrete attacker paths across developer identity, repository, workflow, runner, registry, cloud and production. Confirm that the review includes repository applications, self-hosted infrastructure, AI coding tools and emergency access—not only scanner settings. Request attempts to obtain production credentials from untrusted code, modify protected workflows, deploy an unverified artefact and use an expired exception. The output should distinguish prevention, detection and response and name evidence owners. Clarify how severity, exploitability, business consequence and release urgency shape policy. Require a staged remediation plan that protects high-consequence paths first without making routine delivery dependent on manual heroics. The team should leave with tested credential revocation, artefact discovery and recovery procedures. If the assessment recommends tools without explaining identity boundaries, build trust and rollback, it addresses symptoms rather than the delivery system. Reassessment triggers should include runner changes, new registries, cloud migrations, repository consolidation and significant AI-assisted development adoption.

Make the final report usable by engineering, security and leadership. Summarise the highest-consequence attacker paths, show the failed and passed evidence, identify owners and sequence remediation around production risk. Keep detailed configuration findings linked to the control they affect. A concise executive view and testable engineering backlog are both necessary; one without the other produces either anxiety or unactionable technical noise.