CI/CD and build pipeline

Check method

Workflow permissions, untrusted triggers, secret exposure in build logs, container base images.

Possible evidence type

Code or configuration review, without exploiting the risk.

Access and limitations

Connected repository. Actual results and checks not run appear in your report. A check with no finding does not guarantee the absence of risk.

Concrete scenario

Untrusted pull-request code executes with deployment credentials or a write-enabled token.

What to inspect

Review workflow triggers, checkout context, token permissions and where secrets enter jobs.

Remediation approach

Separate untrusted tests from privileged release jobs and minimize token scope.

Trace what reaches the deployed application

Source code, dependencies, build workflows and deployment credentials form one supply chain. A vulnerable package reference is not always proof that the vulnerable path is reachable, and a safe manifest does not guarantee that the deployed artifact contains the same versions. Record the package, resolved version, advisory and affected usage before choosing a fix.

1. Compare manifests, lockfiles and the deployed build where available.
2. Review workflow token permissions and how untrusted pull-request code is handled.
3. Separate an exposed credential from a public identifier; rotate confirmed leaked secrets.

Upgrade and verify with controlled changes

Avoid blind major-version upgrades or simply deleting a lockfile. Review compatibility and release notes, rebuild with resolved versions, and run relevant regression checks. Credential rotation must revoke the old secret as well as update the application.

1. Prepare the dependency or workflow change in a reviewable branch.
2. Run the existing tests and build pipeline under appropriately scoped permissions.
3. Verify the vulnerable version or behavior no longer appears in the deployed artifact.

References

OWASP A08