Skip to main content

GitHub Actions Security

Skylos can scan GitHub Actions workflow files as part of --danger.

This means the same CLI run that catches application security issues can also review CI/CD configuration in:

  • .github/workflows/*.yml
  • .github/workflows/*.yaml
  • action.yml
  • action.yaml

Use this when you want pull requests to flag workflow changes that affect tokens, secrets, runners, release jobs, containers, or third-party action code.

Run The Scanner​

From the repository root:

skylos . --danger

For a normal PR gate, combine workflow security with secrets and quality checks:

skylos . --danger --secrets --quality --gate

For changed-code review:

skylos . --danger --secrets --quality --diff origin/main

Workflow findings appear in the same Security Issues output as application security findings.

What Skylos Catches​

Skylos focuses on CI/CD patterns that are high-signal in code review.

RiskExamples
Privileged triggerspull_request_target, workflow_run
Broad token permissionsmissing permissions, write-all, workflow-level write scopes
Mutable third-party codeunpinned uses: references and reusable workflows
Checkout credentialsactions/checkout without persist-credentials: false
Template injectionattacker-controlled GitHub contexts expanded in run, action inputs, or container options
Runner trustself-hosted runners and dynamic runs-on expressions
Mutable containersjob containers, services, Docker actions, docker pull, and docker run without digest pinning
Secret exposuresecrets: inherit, toJSON(secrets), dynamic secret lookup, broad secret env scope
Release riskOIDC jobs invoking repo-controlled build or release scripts
Artifact and package risklax artifact uploads, package installs that run lifecycle scripts, missing timeouts

See Rules Reference for the full rule list.

Example Finding​

name: CI
on:
  pull_request_target:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "${{ github.event.pull_request.title }}"

This workflow can produce findings for:

  • privileged pull_request_target execution
  • missing explicit token permissions
  • unpinned action reference
  • checkout credentials left available for later steps
  • attacker-controlled pull-request title expanded directly in shell

Safer Baseline​

For untrusted pull requests, keep the workflow unprivileged:

name: Skylos Security Gate

on:
  pull_request:
    branches: [main]

permissions:
  contents: read
  pull-requests: write

jobs:
  skylos:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
        with:
          persist-credentials: false

      - uses: actions/setup-python@42375524d7b3f331cfa0bf3d4e21d0d3e1df3630
        with:
          python-version: "3.12"

      - run: pip install skylos

      - run: skylos . --danger --secrets --quality --gate

The SHA values above are examples. Pin actions to the full commit SHA you have reviewed.

Release And Deploy Jobs​

Release workflows deserve stricter review because they often have access to:

  • package publishing tokens
  • cloud OIDC federation
  • repository write permissions
  • production secrets
  • signed artifact or provenance steps

Skylos flags release-like workflows that combine sensitive permissions with repo-controlled scripts or mutable state.

Example:

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/build.sh
      - run: ./scripts/publish.sh

The scanner reports this because local build and release scripts become part of the OIDC trust boundary. A safer design separates build/test work from the credential-minting publish step.

Suppressions​

Use suppressions only when the workflow risk is intentional and reviewed.

Inline suppressions work on the same line or the line above the finding:

# skylos: ignore[SKY-D292] internal action is pinned by organization policy
- uses: actions/checkout@v4

For repo-wide policy, use the normal Skylos configuration and suppression workflow described in Configuration.

Limitations​

GitHub Actions scanning is static analysis. It does not execute workflows, resolve every dynamic expression, or audit remote action source code.

It is strongest for review-time guardrails:

  • spotting dangerous workflow structure
  • making token and secret scope visible
  • catching mutable action/container references
  • highlighting risky release automation

Use it alongside GitHub branch protection, environment protection rules, action pinning policy, and code-owner review for workflow changes.

Other CI Providers​

Skylos can run in Jenkins, GitLab CI, CircleCI, Buildkite, and other CI systems as a normal CLI gate:

skylos . --danger --secrets --quality --gate

The workflow-configuration scanner on this page is GitHub Actions-specific. It does not currently parse Jenkinsfile, .gitlab-ci.yml, CircleCI config, or Buildkite pipeline definitions for CI/CD misconfiguration rules.

Use the non-GitHub CI examples in CI/CD Integration to run Skylos against repository source code, secrets, and quality issues from those systems.