r12habh opened a new pull request, #67766: URL: https://github.com/apache/airflow/pull/67766
## What this adds A new workflow `.github/workflows/actionscope.yml` that runs [ActionScope](https://github.com/r12habh/ActionScope) on PRs and pushes to `main` whenever Actions workflows, GitHub Actions sources, Terraform, or JSON IAM/policy files change. ActionScope is an open-source static analyzer (MIT, on PyPI) that maps GitHub Actions workflows to their AWS blast radius. The workflow is scoped to `contents: read` only, runs on `ubuntu-24.04`, pins both `actions/checkout` and `actions/setup-python` to commit SHAs, installs ActionScope from PyPI at a pinned version (`actionscope==0.3.2`), and uses `--fail-on critical` so it surfaces signal without blocking merges on existing findings. ## Why this matters for Airflow A local scan against current `main` (commit at fork time) found: ```text Workflows: 44 | Credential Sources: 8 | Overall Risk: 🟠 HIGH ⚠️ All 8 AWS credential sources use Static Keys, not OIDC. ⚠️ All 8 AWS deploy jobs run without GitHub Environment protection. ⚠️ 32 HIGH GITHUB_TOKEN permissions across CI workflows (mostly packages:write + pull-requests:write + id-token:write). Critical: 0 | High: 32 | Medium: 19 | Low: 173 ``` The 8 workflows configuring AWS credentials, all using static access keys via `aws-actions/configure-aws-credentials`: - `ci-amd.yml` → `ci-image-checks` - `ci-arm.yml` → `ci-image-checks` - `ci-image-checks.yml` → `publish-docs` - `publish-docs-to-s3.yml` → `publish-docs-to-s3` - `publish-docs-to-s3.yml` → `update-registry` - `registry-backfill.yml` → `backfill` - `registry-backfill.yml` → `publish-versions` - `registry-build.yml` → `build-and-publish-registry` Each of these is a candidate to migrate to OIDC role assumption, which avoids storing long-lived AWS credentials as GitHub secrets. This PR does not propose changing those workflows — it just adds the scanner so the finding is visible and trackable. The 8 environment hardening findings show those same deploy jobs run without a GitHub Environment declared, so Environment protection rules (required reviewers, deployment branch restrictions) cannot gate AWS role access. Adding `environment: production` is a small change with high security value. ## What the scanner does *not* find - **0 known-compromised actions** — Airflow's workflows do not reference any entries in the bundled compromised-actions database (`tj-actions/changed-files`, `actions-cool/*`, `aquasecurity/trivy-action`). - **0 unpinned external actions** — Airflow is consistently SHA-pinned. Great supply-chain hygiene. - **0 script injection** patterns (`${{ github.event.* }}` interpolation in `run:` blocks). - **0 artifact-poisoning** patterns (`workflow_run` jobs executing downloaded artifacts). ## How to run it locally ```bash pip install actionscope==0.3.2 actionscope scan . # or for SARIF output that GitHub Code Scanning can consume: actionscope scan . --output-format sarif --output-file actionscope.sarif ``` ## Threshold choice The workflow uses `--fail-on critical` deliberately: - It does *not* fail on the 32 existing HIGH findings, so the PR can land without forcing a parallel cleanup - It *will* fail on CRITICAL findings, which currently means a known-compromised action being added or a documented privilege-escalation pattern landing - Once Airflow is comfortable, threshold can be lowered (`high` or `medium`) ## Threat model fit ActionScope's purpose is *workflow-layer security analysis specific to GitHub Actions ↔ AWS*. It complements rather than duplicates existing tooling: | Tool | What it catches | What it misses | |---|---|---| | `actionlint` | YAML syntax + dangerous patterns | AWS blast radius, compromised actions | | `zizmor` / `Scorecard` | General workflow security patterns | AWS-specific role-to-policy correlation, GitHub Environment gaps | | `Checkov` | IAM policies in isolation | Workflow ↔ IAM correlation | | **ActionScope** | Workflow ↔ IAM correlation, known-compromised actions, OIDC misconfig, GitHub Environment hardening | General YAML linting (use `actionlint` for that) | For Airflow specifically — given the prominence of `apache-airflow-providers-amazon` and the project's identity as a major AWS-using OSS — having a CI signal that watches for AWS credential exposure regressions is on-mission. ## Validation - Verified locally against `apache/airflow` `main`: workflow YAML is valid, scan completes in ~2s, exits `0` with `--fail-on critical`, produces valid SARIF 2.1.0 with repo-relative `%SRCROOT%` paths - All 4 Actions referenced in the workflow are SHA-pinned per Airflow's existing convention - Permissions are minimal: `contents: read` only — no write capabilities introduced ## Notes for reviewers If the project would prefer this run nightly via `schedule` rather than on every workflow PR, that's a one-line change — happy to adjust. Same goes for the threshold, paths, or any naming preferences. --- ##### Was generative AI tooling used to co-author this PR? - [x] Yes (please specify the tool below) Generated-by: Claude Code following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
