AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Actions Security

skill-bitwise-media-group-skills-actions-security · by bitwise-media-group

Security hardening for GitHub Actions workflows with a least-privilege posture — default-deny permissions ({} then minimal per-job scopes), SHA-pinning every third-party action, avoiding pull_request_target (and the safe trusted-event allowlist pattern when an elevated trigger is unavoidable), preventing expression/script injection via env indirection, explicit secrets (no inherit), and OIDC over…

No reviews yet
0 installs
46 views
0.0% view→install

Install

$ agentstack add skill-bitwise-media-group-skills-actions-security

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-bitwise-media-group-skills-actions-security)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Actions Security? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

GitHub Actions security posture

A reusable workflow cannot constrain how a consumer wires its trigger, and a CI workflow runs on code a stranger proposed. Treat every workflow as reachable by an untrusted contributor and apply least privilege. These rules are enforced mechanically by the actions-validate skill (actionlint + zizmor) and CodeQL; the authoring conventions they assume live in actions-style. For attack anatomy and extended examples, see [reference.md](reference.md).

1. Default-deny permissions

Declare permissions: {} at the top level and grant each job only the scopes it needs. Never use permissions: write-all, and never rely on the repository default token (it can be broad).

permissions: {} # deny everything by default
jobs:
  build:
    permissions:
      contents: read # the minimum: check out the repo

A job that uploads code-scanning results adds security-events: write; one that comments on a PR adds pull-requests: write. Grant at the job level so a compromised step holds only that job's token. A reusable workflow's jobs can never exceed the caller's grant — keep that ceiling tight.

2. Pin every third-party action to a full commit SHA

A tag (@v4) or branch (@main) is mutable: whoever controls the action's repo can repoint it at new code that then runs with your token. Pin to a full 40-character commit SHA with the version in a comment — for first-party actions too.

- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3

Keep pins fresh with Dependabot's github-actions ecosystem so updates arrive as reviewable PRs:

version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: daily

3. Avoid pull_request_target

pull_request_target runs in the base repository's context — with repository secrets and a read/write GITHUB_TOKEN — while the pull request comes from an untrusted fork. Check out and run the PR's head code under it and a fork author can exfiltrate those secrets (the "pwn request"). So:

  • Test PR code with pull_request, not pull_request_target. Fork PRs then get a read-only

token and no secrets — safe by construction.

  • If you genuinely need base context (label, size, or comment on a PR), run no PR-controlled

code and never check out the PR head. The org's merge-notice and dependabot-merge callers use pull_request_target safely because they only call the API — they check out and run nothing.

  • For privileged build/release jobs that a fork-controllable event could reach, gate them on a

positive trusted-event allowlist so the path fails closed:

``yaml if: ${{ contains(fromJSON('["push","workflow_dispatch","schedule"]'), github.event_name) }} ``

4. Prevent expression/script injection

Never interpolate attacker-controlled text — a PR title, branch name, or comment body — directly into a run: script. The value is substituted before the shell runs, so $(...) or backticks in a PR title execute as code. Pass it through a quoted environment variable and reference the variable:

# WRONG — the title is injected into the shell
- run: echo "Title: ${{ github.event.pull_request.title }}"

# RIGHT — the title is data in the environment, never code
- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Title: $PR_TITLE"

5. Handle secrets explicitly

  • Pass secrets to a reusable workflow by name through secrets:; never secrets: inherit, which

hands over every secret in the repo.

  • Don't echo secrets or write them to logs/artifacts; GitHub masks known secret values but not

values derived from them.

  • Prefer OIDC (permissions: id-token: write plus the cloud's federation) to authenticate to

AWS/GCP/Azure over storing long-lived access keys as secrets.

6. Know the GITHUB_TOKEN

On a fork pull request the GITHUB_TOKEN is read-only and secrets are withheld; on a same-repo event it carries whatever permissions: you granted. Scope it down rather than up, and gate same-repo-only logic (label arming, review handling) so fork PRs skip it.

7. Enforce mechanically

Run the actions-validate loop (actionlint + zizmor) locally before committing, and scan actions with CodeQL in CI (the actions-reusable-workflows skill wires the shared codeql.yaml). Treat their findings — unpinned actions, injectable expressions, over-broad permissions — as violations, not suggestions.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.