CI/CD pipeline security: protect the path from code to production.

Treat the pipeline as a path into production

Your delivery pipeline can publish software, assume cloud roles, change infrastructure, and promote a release to customers. Those capabilities make CI/CD security a business issue even when the application itself has been reviewed. The practical question is who, or what, can cause the automation to exercise that authority. A passing test suite says little about whether the job should have been allowed to deploy in the first place.

Consider a fictional B2B SaaS company that operates a customer portal. Employees and approved contractors submit changes, automated jobs test them, and a release workflow deploys the portal. The team wants faster releases while protecting customer data and retaining clear approval records. This is an illustrative planning scenario, not an SPS customer or a claim about a discovered incident. The company’s starting question is whether a proposed change can influence production before the intended review has occurred.

NIST SP 800-204D examines software supply-chain security across the activities that build, package, and deliver software. [1] Apply that perspective to one real release path. Include repository settings, workflow definitions, build workers, package sources, artifact storage, signing, approvals, and deployment roles. The objective is to explain how a release becomes trusted, where that trust is checked, and who owns the decision when required evidence is missing.

Separate the authority at each stage

Draw the path from a proposed change to a running workload, then write the authority beside each step. Contribution checks may need to read code and report results. A build may need to fetch approved dependencies and write an artifact to a designated location. A release process may approve that artifact for promotion. Deployment should have only the access needed to update the intended service. Avoid treating one broad automation account as an inevitable convenience.

For the fictional portal, distinguish permission to propose code from permission to merge it, alter its workflow, publish a release, or approve production deployment. Identify who can change the rules governing those permissions. A required approval is weak if the same unreviewed change can remove the requirement. Protect workflow definitions and sensitive configuration through review and platform controls appropriate to the system, and include administrator bypasses in the map.

Review indirect paths as well. Can a contribution job overwrite an artifact later consumed by a release? Does a build worker retain credentials or data from a more privileged job? Can a manual rerun use different code from the version that was approved? These questions turn a flowchart into an authority review. Record the expected boundary and the evidence needed to verify it, rather than inferring separation from different job names or colors in the pipeline interface.

Keep untrusted work away from privileged execution

A proposed change becomes executable input when the pipeline runs its tests, build scripts, or dependencies. The contributor’s business relationship does not make every submitted byte trustworthy. The portal’s contractor should be able to receive useful test feedback without gaining release credentials or access to production networks. Design contribution checks for that limited purpose, and examine what they can read, write, and influence beyond their own job.

GitHub’s current security guidance warns about checking out untrusted code in privileged workflows, including certain pull-request and workflow-completion triggers. It also calls for caution with artifacts received from other workflows. [2] The general lesson is to evaluate the combination of trigger, executed content, permissions, and shared state. Moving a step into a second workflow does not establish a boundary if that workflow blindly executes or promotes material supplied by the first.

Build steps themselves are dependencies. GitHub now recommends workflow dependency lockfiles where supported, with full commit-SHA pinning as a fallback for repositories that cannot adopt them. [2] Use the mechanism appropriate to your platform to select reviewed versions, preserve their identity, and control updates. A fixed version can still contain a defect or malicious behavior. Give someone responsibility for reviewing changes to build tools, and check runner isolation, cleanup, and access separately from dependency selection.

Make short-lived credentials narrowly useful

Stored cloud keys are easy to copy into multiple pipelines and difficult to account for later. Workload federation can replace eligible long-lived secrets with temporary access. In GitHub Actions, OpenID Connect lets a workflow request short-lived cloud credentials after the provider checks its identity claims against configured trust conditions. [3] This reduces the need to store reusable cloud credentials in the repository platform, but it does not decide which permissions are appropriate.

For the fictional portal, the cloud owner should describe the specific release context permitted to request the production role. Match the provider-supported trust conditions to the intended repository, workflow, and release or environment context. Separately restrict what that role can do once issued. A broadly trusted job with temporary administrator access still has administrator authority during its lifetime. Test the trust decision and the resulting permissions as two related controls.

Plan the transition with the people who operate releases. Identify every consumer of the old credential, confirm the approved deployment path works, and remove obsolete access through a controlled change. Preserve a separately governed recovery path if the business needs one. Include non-production jobs, reusable workflows, and manual release procedures in the review; otherwise the main pipeline may improve while a rarely used shortcut retains the original exposure.

Know what each piece of release evidence establishes

A software bill of materials, or SBOM, is an inventory of components associated with a release. It helps a team investigate which products may include an affected dependency. NIST cautions that an SBOM alone is insufficient for vulnerability management. [1] Its usefulness also depends on coverage, accuracy, and a connection to the actual release. A file named SBOM in an old build directory is not a reliable answer to what is running today.

A verified signature can connect artifact integrity to an accepted key or signing identity. It does not establish that the software has no vulnerabilities or that every requested change was authorized. Provenance records how an artifact was produced, including information about its builder and inputs. Its value depends on the trustworthiness of its producer and on checking the claims against the release you intended to accept.

SLSA’s verification guidance calls for checking the provenance signature, matching its subject to the artifact digest, and comparing the builder, source, and build parameters with expectations. [4] For the portal, the deployment decision should concern an identified artifact with approved evidence, not merely a mutable label such as “latest.” Where practical, promote the tested artifact instead of rebuilding it after approval and assuming the second output is equivalent.

Make the checks part of the release path. Identify the approved signers and builders, the expected source, and the point that refuses a mismatch. Decide who can update that policy. A compromised or overpowered trusted builder can still produce misleading evidence, so signing and provenance complement the authority controls described earlier. They do not replace them.

Define what a gate must decide

A security gate needs an explicit decision rule. Specify its stage, inputs, tool or review, blocking criteria, evidence, owner, and exception route. NIST’s Secure Software Development Framework calls for defined security-check criteria and records of approvals, rejections, and exception requests. [5] This is a stronger operating foundation than adding a scanner whose result someone might notice after deployment.

Choose checks that address the portal’s meaningful exposures. Secret detection can examine proposed changes; dependency and configuration checks can inform the build; an approval can address a sensitive design change; release verification can check artifact identity and required evidence. Agree how findings are evaluated in context. An unavailable scanner, a missing result, and a completed scan with no blocking findings are different states and should not collapse into the same green indicator.

For a required gate, define fail-closed behavior: missing or invalid evidence prevents the protected promotion unless a separately approved exception applies. Review skip conditions, optional jobs, manual deploy paths, and administrative overrides. A failed check that does not affect the final deployment decision is reporting, not enforcement. Document how operators diagnose a blocked release and whom they contact so the process remains usable when a tool fails.

Roll out enforcement with an owned exception path

Start new checks in report-only mode against representative work, then tune the rules with developers before enforcing the agreed policy. Record which decisions remain advisory during that period. Set an owner and a review point for moving each gate into enforcement. A quiet dashboard should not be interpreted as protection when the check is still unable to block anything.

For the fictional portal, use the pilot to understand repeated false alarms, incomplete dependency identification, and failures caused by the workflow rather than the application. Preserve the underlying concern when adjusting a rule. Excluding an entire repository to silence one difficult result creates a different exposure from a documented, narrowly scoped exception. Keep changes to the gate policy reviewable just like changes to the workflow itself.

An exception should identify the finding or requirement, affected release or scope, business reason, accountable approver, temporary safeguards, and expiry or review trigger. The person accepting the exposure needs enough context to make that decision. A hotfix should follow a prepared route rather than depend on disabling controls broadly. When an exception expires, the default rule should apply again unless a new decision is recorded; demonstrate that behavior during acceptance.

Prove the rejected and accepted paths

Validate the design in an approved test environment with harmless, controlled cases. Show that an unauthorized contribution cannot obtain the production role, an artifact with missing or mismatched required evidence cannot be promoted, and a seeded policy violation reaches the intended blocking decision. Capture what was tested and where it stopped. A red job alone does not prove that another path could not complete the deployment.

Then demonstrate the intended release passing. Tie its source revision, workflow version, artifact digest, scan results, approval, and deployment record together. Verify that the running test workload uses the artifact whose evidence was accepted. This positive case matters: a gate that rejects everything does not provide a workable release process, and a green build without the expected identity checks does not establish the intended control.

Exercise the exception route with the same care. Show that only the approved scope passes, that the decision is retained, and that use beyond its bounds or after expiry is refused as designed. Also test how a missing result or unavailable verification service is handled. These checks support conclusions about the agreed paths and conditions; they do not prove every future workflow secure. Repeat affected checks when permissions, triggers, builders, or release policy change.

Leave the team with controls it can operate

The handoff should include the authority map, reviewed configuration changes, gate decisions, acceptance evidence, and a runbook for failures and exceptions. Name the owner for each control and the person who approves changes to it. Agree where records are retained and how a release can be traced without exposing credentials or unnecessary sensitive data. Review recurring overrides and unexplained missing checks as signs that the process needs attention.

SPS CI/CD Pipeline & Workflow Security Integration reviews the existing delivery path, proposes changes for your team to review, and introduces gates through report-only operation, tuning, and agreed enforcement. The service provides a gate map, an evidence index, validation records, and a tuning and exception runbook. Software Supply Chain Security adds focused review of dependency intake, build integrity, SBOMs, signing, and downstream verification. Your team retains ownership and operates the pipeline afterward.

For the fictional portal company, the desired result is a release process whose authority and evidence can be explained. Leadership can see what prevents an unapproved change from reaching customers, developers can understand a blocked release, and operators can handle an urgent exception within known limits. Begin with one important release path, validate the controls, and carry the proven pattern to other pipelines with their differences explicitly reviewed.