PS Product SecurityKnowledge Base

🔍 GitHub Actions and GitLab Components Review Playbook

Intro: Third-party pipeline logic is code execution with transitive trust. Reviewers should treat it like software supply chain and privileged automation at the same time, not like a harmless convenience snippet.

What this page includes

  • how to review third-party GitHub Actions and GitLab components
  • version pinning, source trust, and secret-minimization decisions
  • self-hosted runner implications
  • what to approve, reject, or quarantine

Third-Party Integration Trust Boundaries

Review questions for any reusable pipeline component

  • Who maintains it, and how do we know?
  • Is the source reviewed, or only the marketplace/catalog description?
  • Is the component pinned to a trustworthy immutable version or digest?
  • What secrets, tokens, or cloud trust relationships are available at runtime?
  • Could the component modify build outputs, manifests, pull requests, or releases?
  • Would a compromised runner make the damage much worse?

Safer GitHub Actions patterns

Prefer:

  • pinning actions to a full commit SHA for higher-trust workflows;
  • reviewing source before granting secrets or write permissions;
  • using OIDC instead of long-lived cloud secrets where appropriate;
  • separating untrusted pull-request execution from privileged deployment paths.

Safer GitLab component patterns

Prefer:

  • using published, versioned components rather than floating references;
  • auditing include: component source and inputs before adoption;
  • using minimum-scope tokens and segregated runner pools;
  • avoiding branch-based floating references for sensitive component usage.

Red flags

  • floating refs such as main, master, or unfixed latest tags in privileged paths;
  • undocumented secret usage;
  • components that download and execute additional remote content at runtime;
  • privileged jobs running on shared or reusable runners with weak isolation;
  • actions or components with write access to repo, artifacts, or deployment targets without clear need.

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.