Yes. GitHub's dependency graph parses actions referenced in workflow files as dependencies. They run inside your build with access to your code and secrets, so buyers who care about build integrity increasingly ask about them. Know which actions you use, how each is pinned, and who maintains it.
What GitHub says
GitHub's documentation states that workflows must sit in the .github/workflows directory to be recognised as manifests, and that actions or workflows referenced with the uses syntax are parsed as dependencies. It also notes that for GitHub Actions, alerts are generated just for actions that use semantic versioning, not SHA versioning.
Separately, GitHub's security hardening guidance says pinning an action to a full length commit SHA helps mitigate the risk of an attacker adding a backdoor to the action's repository, because they would need to produce a SHA-1 collision for a valid Git object. It also advises verifying that the SHA comes from the action's own repository and not a fork.
The trade off
| Approach | Benefit | Cost |
|---|---|---|
| Tag or version range | Easy updates, alerts work | A moved tag changes your build silently |
| Full commit SHA | Immutable reference | No version alerts, manual or bot updates needed |
| Vendored copy | Full control | You own the maintenance |
Neither is wrong. What a buyer wants is a deliberate choice and a way to keep up. A common pattern is pinning to SHA with a comment naming the version, and letting an update bot propose changes you review.
Steps to prepare
- List every action across your repositories, including those in reusable workflows.
- Record the owner of each: first party from your own organisation, a large vendor, or an individual maintainer.
- Note how each is referenced: branch, tag, SHA.
- Remove actions you no longer need.
- Replace actions from unknown individuals for anything touching secrets, or review and pin them.
- Set workflow permissions to the minimum and keep secrets out of jobs that do not need them.
- Add the list to your dependency inventory or SBOM supplement.
Why this appears in diligence
Build pipelines are an attractive target, and a compromised action runs with your credentials. A one page description of how you manage workflow dependencies answers the question before it is asked.
What to write
"Workflows use 14 third party actions. Eleven are pinned to full commit SHAs with the version in a comment. Three first party actions use tags. Updates arrive as pull requests reviewed by the platform team. Workflow permissions default to read-only." Use your real numbers, and make sure each sentence is true on the day.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a policy check can block a pull request that changes dependencies, including changes to workflow files if you scope the gate that way.
Safeguard provides policies and gates for pull requests, and SBOM and dependency scanning for the rest of your inventory. A free scan is a quick first look.
Quick check
Should every action be pinned to a SHA?
GitHub's guidance lists pinning to a full length commit SHA, and says to pin to a tag when you trust the creator. Choose per action and record why.
Do pinned actions still get security alerts?
GitHub says alerts apply just to actions using semantic versioning, so plan another way to learn about problems, such as reviewing update pull requests.
Sources
- GitHub Docs, Dependency graph supported package ecosystems
- GitHub Docs, Security hardening for GitHub Actions
Last reviewed: 19 October 2026.
