Discuss: which GitHub-Actions-security measures should be recommended / encouraged / enforced across ASF repos?

[potiuk]

Follow-up to the discussion on #631 (actions-audit.py), where @raboof noted we don't yet have consensus on all the checks the tool proposes, and @dave2wave raised the enforcement vs. voluntary-adoption split and the missing input from Security / Infra.

This issue is the place to work toward that consensus. Once we agree, #631 (and any successor in apache/infrastructure-gha-workflow-scanner) can be adjusted to match.

Classification scheme

For each check, please indicate which tier it belongs to:

• 🟢 Recommend — document it, PMCs opt in themselves
• 🟡 Encourage — proactively open PRs against PMC repos (with PMC consent upstream on dev@), PMCs can decline
• 🔴 Enforce — mandatory baseline, continuously scanned (e.g. via infrastructure-gha-workflow-scanner), failure flagged to Infra
• ⚪ Out of scope — not appropriate as an ASF-wide policy

Checks proposed in #631

• Dependabot enabled for github-actions ecosystem — tier: ⚪🟢🟡🔴
• Dependabot cooldown for github-actions (separate thread in Determine recommendations for cooldown periods #683 — current proposal: 7 days for "used" actions; 0 days for dependabot PRs that trigger review in this repo) — tier: ⚪🟢🟡🔴, value: 0 / 4 / 7 / other
• Dependabot cooldown for language/package ecosystems (pip, npm, uv, maven, etc.) — tier: ⚪🟢🟡🔴, value: ?
• CodeQL scanning for Actions (github/codeql-action) — tier: ⚪🟢🟡🔴
• Zizmor workflow scanner (zizmorcore/zizmor-action) — tier: ⚪🟢🟡🔴
• ASF allowlist-check (requires every uses: ref to be on the approved list) — tier: ⚪🟢🟡🔴

Checks proposed elsewhere / worth considering

• Hash-pinning of all third-party actions (incl. actions/*, github/*) — raised in Determine recommendations for cooldown periods #683 / Pin all workflow actions to commit SHAs #703 — tier: ⚪🟢🟡🔴
• Binary-download verification in allowed actions (see Determine some more criteria for actions review #686 / verify-action-build: add binary download verification check #743) — applies to allowlist review, not per-PMC repo scan — n/a here
• Minimum-permission workflows (top-level permissions: read-all or equivalent) — tier: ⚪🟢🟡🔴
• persist-credentials: false on actions/checkout — tier: ⚪🟢🟡🔴

Meta questions

• Where does the tooling live? → this repo (infrastructure-actions) for voluntary / PR-opening; apache/infrastructure-gha-workflow-scanner for continuous enforcement? Or both? (@raboof, @dave2wave)
• Scope: PMC repos (prefix matched), non-PMC repos (infrastructure-*, tooling-*, www-site), or both? (@dave2wave raised scoping)
• .asf.yaml opt-in/opt-out — should PMCs be able to configure which checks apply via .asf.yaml? (@dave2wave's suggestion)
• Decision process: who has binding input? Proposed: Infra + Security Response team ratify the tiers; PMCs consulted on dev@ before any "🟡 Encourage" PRs are opened.
• Rollout: trial with a small number of friendly PMCs first (announce on their dev@), iterate on PR template, then broaden.

Related

• Add actions-audit.py for auditing Apache repo security tooling #631 — audit tool PR
• Determine recommendations for cooldown periods #683 — cooldown-period discussion
• Determine some more criteria for actions review #686 — allowlist review criteria
• Pin all workflow actions to commit SHAs #703 — hash-pin all third-party actions

cc @raboof @dave2wave @ppkarwasz

[potiuk]

Shall we discuss that one to get to some consensus?

[kevinjqliu]

my preference would be to enforce ASF allowlist-check across all apache repo, its a standlone github workflow file (https://github.com/apache/iceberg/blob/main/.github/workflows/asf-allowlist-check.yml), we can just push it to all the repos.

otherwise, the failure case is that CI can silently fail (#574)

[ppkarwasz]

• Dependabot cooldown for language/package ecosystems (pip, npm, uv, maven, etc.) — tier: ⚪🟢🟡🔴, value: ?

Cooldown doesn't work for some ecosystems like poetry (dependabot/dependabot-core#13749), so I would encourage it, but not enforce it.

[ppkarwasz]

• CodeQL scanning for Actions (github/codeql-action) — tier: ⚪🟢🟡🔴

INFRA can add it by default by modifying the GitHub Advanced Security default configuration and this can be enabled via .asf.yaml (apache/infrastructure-asfyaml#94).

[potiuk]

Cooldown doesn't work for some ecosystems like poetry (dependabot/dependabot-core#13749), so I would encourage it, but not enforce it.

My instinct tell me that we should not allow ecosystems that do not have cooldowns :) . They are single most effective protection against all kinds of account takeovers.

[potiuk]

I think this is a nice try to advertise but there is absolutely nothing in what your product do that what we can aks our agents to do in minutes. It's more important for us to agree wha to do - not whether we should use any specific tooling for that - that can be recreated in minutes. Hiding it as off-topic.

[dave2wave]

Here is a description of the tooling team's gha scanner. Drill down in the repos for results.

[dave2wave]

Let me put it strongly with respect to our duties with CRA. It is likely that we will be responsible for two kinds of actual exploits.

1. Exploited CVEs in PMC releases.
2. Exploited leaks from ASF infrastructure. We need to prevent all leaks. If projects won't block then we either prevent it or continually have to report a project's leaks.

It's in The ASF's interest to NEVER need to report. We need to deal with the Beam like projects immediately.

[potiuk]

Let me put it strongly with respect to our duties with CRA. It is likely that we will be responsible for two kinds of actual exploits.

1. Exploited CVEs in PMC releases.
2. Exploited leaks from ASF infrastructure. We need to prevent all leaks. If projects won't block then we either prevent it or continually have to report a project's leaks.

It's in The ASF's interest to NEVER need to report. We need to deal with the Beam like projects immediately.

I think this is quite off-topic. We are not talking here about dealing with "kinds of projects" but about defining what is a "mandatory" configuration for security setup in GH action. If you have a topic about "dealing with difficult projects" this is a completely different discussion - quite unrelated to this very narrow topic of GH actions.