skills.rest
DeepSpaceCartel
DeepSpaceCartelOFFICIAL
Explore all skills by this author →
WebsiteGitHub

github-actions

Write and harden GitHub Actions workflows with least-privilege permissions and pinned actions.

Updated Sep 9, 2026
Search Tags:#devops#ci/cd#github actions#oidc#workflow security#sha pinning#self-hosted runners
One-click install
npx skills add https://github.com/DeepSpaceCartel/skills --skill github-actions-deepspacecartel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: github-actions
Source: https://github.com/DeepSpaceCartel/skills/tree/main/skills/github-actions
Command: npx skills add https://github.com/DeepSpaceCartel/skills --skill github-actions-deepspacecartel

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? GitHub Actions workflows are executable infrastructure with access to your repository, secrets, and cloud accounts, yet they are often written as casual YAML config. This Skill helps you write and review workflows that follow security hardening guidance, avoiding common vulnerabilities like secret exfiltration via pull_request_target, mutable action tags, and over-privileged GITHUB_TOKEN scopes. ## Core Features & Use Cases - Workflow structure and triggers: Covers workflow/job/step structure, event triggers (pull_request, push, schedule, workflow_dispatch, workflow_call), contexts, concurrency controls, caching, and matrix builds. - Security hardening: Enforces least-privilege permissions, pinning third-party actions to full commit SHAs, OIDC federation to cloud providers instead of long-lived secrets, safe secret handling, and fork-PR safety rules. - Self-hosted runner guidance: Explains runner trust boundaries, ephemeral runners, in-cluster ARC patterns, and gating so untrusted fork PRs never execute on self-hosted infrastructure. - Use Case: When reviewing a pull request that adds a CI workflow, use this Skill to verify the workflow sets explicit permissions, pins every action to a SHA, avoids pull_request_target for running PR code, and routes deploy secrets through protected environments. ## Quick Start Ask the AI to review the workflow file at .github/workflows/ci.yml for security issues and missing hardening practices.

Frequently Asked Questions about github-actions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I secure a GitHub Actions workflow?▼

Set explicit least-privilege permissions (start from contents: read), pin every third-party action to a full 40-character commit SHA, use OIDC instead of long-lived cloud secrets, and route deploy jobs through environments with required reviewers. Never run untrusted PR code with secrets available.

What is the difference between pull_request and pull_request_target?▼

pull_request runs the PR's workflow with a read-only token and no secrets for forks, making it the safe CI default. pull_request_target runs the base repo's workflow with secrets and a write token, so checking out PR code under it lets attackers exfiltrate secrets.

Why should I pin GitHub Actions to a commit SHA?▼

Tags like @v1 are mutable and can be re-pointed by an attacker to malicious code, which then executes with your workflow's secrets and token. Pinning to a full commit SHA makes the action immutable; add a version comment and let Dependabot update both.

Can self-hosted runners run fork pull requests safely?▼

No. A self-hosted runner persists between jobs and has network and cluster access, so running untrusted fork PR code on it risks pivoting into your infrastructure. Gate jobs with a same-repo check or skip fork PRs entirely, and prefer ephemeral runners.

How do I use OIDC instead of cloud secrets in GitHub Actions?▼

Grant id-token: write in permissions, then use an action like aws-actions/configure-aws-credentials to exchange GitHub's short-lived OIDC token for temporary cloud credentials. Restrict the cloud role's trust policy to your repo and branch so no long-lived key is stored.

When should I use a reusable workflow vs a composite action?▼

Use a reusable workflow (workflow_call) when you need a whole job with its own runner, needs ordering, or matrix. Use a composite action when you only need to share a few steps inside an existing job; composite actions run in the caller's job and cannot define jobs.

Related Skills

Explore More Software Engineering Skills→
igot-aiigot-ai

build-verify

Detect project ecosystems via lockfiles, install dependencies, and execute builds.

Official
Advanced
tankpkgtankpkg
1

@tank/github-actions-mastery

Design secure GitHub Actions workflows with SHA pinning and OIDC federation.

Official
Advanced
AutomatticAutomattic
12.6k

calypso-security-alerts

Guides advisory triage of Dependabot alerts and remediation PRs for wp-calypso.

Official
Intermediate
testdriveraitestdriverai
238

testdriver:ci-cd

Orchestrate TestDriver tests in CI/CD pipelines with parallel execution across platforms.

Official
Intermediate