What should you read in an action.yml before using an action?

Open the action's metadata file and read the runs block first. It tells you whether the action executes JavaScript, builds or pulls a container, or chains shell and other actions. Then read the entry point it names, the inputs it takes, and what it sends over the network. Ten minutes here beats trusting a README.

What the file is

Every action has a metadata file, action.yml or action.yaml, at the root of its repository. It declares the name, the inputs and outputs, and how the action runs. Marketplace listings require exactly one such file at the root, so it is always easy to find.

Step 1: Find the action type

GitHub's metadata reference defines three types through the runs.using value.

The type decides where you read next. For JavaScript, open the main file, and notice whether it is a small readable script or a large bundled file. For Docker, look at the image reference. For composite, read every step.

Step 2: Read the entry point

For a JavaScript action, a bundled output file is normal, but the source should be in the repository so you can compare. Look for network calls, calls that read environment variables in bulk, and anything that writes to files that later steps will use.

For a Docker action, check whether runs.image points at a Dockerfile in the repository or at a published image. A Dockerfile you can read is easier to reason about than an image tag you cannot. If it points at an image, prefer a reference by digest, and check who owns that image.

For a composite action, read each run step, and note that GitHub's reference says shell is required when run is set. Also look at every uses step. The docs strongly recommend including a version on those, but a composite action can still reference another action by a moving tag. That nested action runs in your job too, with the same access.

Step 3: Read the inputs

GitHub stores input parameters as environment variables, named with an INPUT_ prefix. An input that asks for a token is an input that receives a secret, so ask why. If an action asks for a broad token when its stated job needs little access, that is a warning sign.

Also check outputs. An action that sets outputs or writes to the environment files can influence later steps, which is covered in what an action can change for later steps.

Step 4: Check the history, not just the file

A clean file today says little about tomorrow. Look at recent commits and releases, who has write access, and whether releases are tagged consistently. GitHub's secure use guidance recommends auditing the action's source for secrets sent to unexpected hosts or logged by accident, and pinning to a full commit SHA so the code you read is the code that runs.

A short vetting checklist

1. Identify the type from runs.using.
2. Read the entry point or every composite step.
3. List the inputs that receive credentials.
4. List the hosts the code contacts.
5. Note any nested uses and whether they are pinned.
6. Pin to a full SHA from the action's own repository.
7. Record the action in your inventory.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how each dependency is listed with its version, then picture your workflow actions sitting in the same list.

Quick check

Sources

• GitHub Docs: Metadata syntax for GitHub Actions
• GitHub Docs: Secure use reference
• GitHub Docs: Publishing actions in GitHub Marketplace

Last reviewed: 19 October 2026.