CI/CD security review: untrusted changes and deployment authority

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A CI/CD security review should examine where untrusted contributions or build inputs can interact with trusted credentials and deployment permissions. A passing test suite does not establish that the workflow granting release authority is safe.

GitHub documents workflow permission controls and risks associated with untrusted input and code. GitHub Actions secure-use reference provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Identify the trust transition

Map the events that start workflows, the repository or contributor that supplies code, and the permissions available to each job. Include reusable workflows, third-party actions, build artifacts, caches, and deployment environments. Determine who can approve protected-environment access and change pipeline definitions. A low-trust test job should not silently inherit release credentials. Ask owners to describe the intended boundary before evaluating it, because some automation deliberately trusts internal branches while isolating outside contributions. Review the exact trigger and execution context.

Use a harmless repository fixture

Create an owned test repository or isolated branch with a non-secret marker and a deployment target that has no production authority. Exercise an ordinary trusted build and an approved lower-trust change. Observe whether the marker or protected job becomes available outside the intended boundary. Avoid running attacker-supplied code, publishing package artifacts, or touching real release credentials. The purpose is to evaluate a controlled permission transition, with clear rollback and audit records. An assessment can often combine configuration analysis with a minimal sandbox run.

Track artifacts and identity

Preserve the triggering event category, revision, workflow version, job permissions, approval record, artifact provenance, and observed result. Keep tokens and private repository content out of general reports. A build completing successfully says little about whether its output came from the approved revision. Likewise, an action name is not evidence that it runs the intended code version. Distinguish observed credential access from potential policy exposure. If no runtime proof was authorized, identify the finding as a configuration or trust-model issue rather than a demonstrated production compromise.

Retest release safeguards

After remediation, repeat the trusted and lower-trust fixture and confirm legitimate release operations remain possible. Check that approval applies to the artifact actually deployed, not a later mutable reference. Remove temporary permissions and artifacts. Document excluded repositories, external runners, and package registries. One workflow assessment cannot establish the security of every build dependency or runner host. Businesses using agentic testing should require the same isolation of assessment automation: dedicated credentials, bounded repository access, controlled outputs, and an accountable owner for each run.

A useful assessment artifact

Produce an authority graph connecting input source, workflow revision, runner, artifact, approval, and deployment target. It gives release owners a concrete way to reason about trust changes when they introduce a new reusable workflow or a third-party build action.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.