GitHub Actions Workflow Checker

Why an action tag gets a review point

The sample references a version tag. Tags can move, so GitHub recommends a full commit SHA when an immutable action reference is required. This checker can inspect the reference shape. It cannot establish whether a SHA belongs to a trusted upstream commit or whether that commit is safe.

Permissions have context

A workflow-level permission setting can be overridden for a job. Repository defaults and organisation policy also affect the effective token. Read the relevant configuration rather than responding to a warning by granting write access everywhere. A job that publishes a release may legitimately need permissions a test job does not.

Untrusted input needs a boundary

Pull-request text and other event data can reach a shell script when expressions are inserted directly into a run block. The checker flags selected visible patterns. It does not follow every variable through reusable workflows, custom actions or generated scripts, so an empty warning list is not a security audit.

What happens when YAML is ambiguous

Duplicate keys and unsupported structures are rejected rather than interpreted with a silent last-value-wins rule. Only one document is accepted. Parsing and rule checks happen locally, and neither the workflow nor its actions are executed.

References

• Secure use of GitHub Actions
• Script injection risks, GitHub
• YAML parser documentation

Documentation reviewed: 1 November 2026. Rule results describe the supplied text, not a live application test.

Useful next steps

• Secret Redactor
• Security Report Builder
• Practical guides and coding projects

Maintained by MetaCyberGuru. A review point may need source, runtime or deployment context before you act on it.