Third-party actions are code — they execute on the runner

A uses: line in a workflow is a code-fetch instruction. The runner downloads the referenced action and executes it with every secret, network path, and write privilege the job holds. The trust you extend to the marketplace is the trust you extend to the action’s author, to their node_modules, and to their build pipeline. The marketplace is a discovery layer; it is not a trust layer.

First-party versus third-party

Actions are categorised by ownership. A first-party action lives in a repository owned by the same user or organisation as the workflow file — actions/checkout, actions/setup-node, and github/codeql-action are first-party because GitHub owns them. A third-party action lives in a repository owned by someone else. The trust boundary stops at the runner and resumes at the action author’s repository.

flowchart LR
    A["Workflow repo"] --> B["Runner"]
    B --> C["First-party action"]
    B --> D["Third-party action"]
    C --> E["Same-org trust"]
    D --> F["External trust"]
    D --> G["Author deps"]
    D --> H["Author build pipeline"]

A first-party action inherits the identity the runner already trusts. A third-party action extends that trust to a stranger, and to that stranger’s transitive dependencies and release pipeline.

What the runner actually executes

When the runner resolves uses: thirdparty/action@v1, three things happen: resolve the reference, download the action’s files (action.yml, index.js, Dockerfile, plus node_modules for JavaScript actions), and execute the action’s runs.using entry. The action inherits every privilege the job has — read access to the checkout, every secret in secrets.*, the runner’s network egress, and write access to the runner’s filesystem during the job.

Why the marketplace is not a trust layer

The marketplace shows a verified badge, a star count, a download counter, and a maintainer name. The badge is a domain verification (the publisher controls the listed URL). The star count is social proof. The download counter is a number. The maintainer name is a GitHub account. None of these are a security audit of the action’s code, its dependencies, or its maintenance status. The marketplace is a catalogue; the trust evaluation is the consumer’s responsibility.

Production discipline

1. Default to first-party actions. actions/checkout, actions/setup-node, aws-actions/configure-aws-credentials.
2. Treat every third-party uses: line as a code-review item. The PR must justify the maintainer and the version.
3. Read the action’s source. Not the README; the action.yml, the index.js, the package.json.
4. Pin the reference to a SHA, not a tag. Covered in LXVI-05.
5. Restrict the runner’s privileges. Narrower secrets and shorter token TTLs shrink the blast radius.

Cross-course references

• Git, CI/CD & GitOps — Part LXV-04 (Runner as Actor) establishes the runner’s privilege model.
• Git, CI/CD & GitOps — Part LXV-03 (Dependency Trust) covers the package-level analogue.
• Linux for Production Sysadmins — Part XII (RepoSecurity) covers the apt/dnf trust model.

Quiz