ISSUE-703 Critical Medium CLI Third-party actions

Action version carries a published security advisory

Control: Actions must not carry known CVEs · Config key: actionsMustNotCarryKnownCVEs

📋 What is this?

A step-level uses: owner/repo@ref in committed workflow YAML matches a published GitHub Advisory Database entry for the actions ecosystem. Plumber queries /advisories?ecosystem=actions&affects=<owner>/<repo> once per owner/repo (cached). Exact tags (@v4.1.0) and SHA-resolved versions are point-checked against each advisory's vulnerable_version_range. Moving partial tags (@v4, @v4.1) are span-checked across the whole release series they can float across, so a partial tag is only reported when the **entire** span is vulnerable — @v4 floating to v4.3.0 does not match >= 4.0.0, < 4.1.3. A ref that cannot be resolved to a release version — a commit SHA with no matching release tag, or a mutable non-numeric tag such as @rc / @main / @latest — abstains and surfaces a 'could not verify' warning instead of matching every advisory for that repo. Requires gh / GH_TOKEN; without auth the control abstains.

⚠️ Impact

A known-vulnerable action running in CI means the workflow inherits the published vulnerability class (RCE, secret exfiltration, privilege escalation, depending on the advisory). The blast radius is the union of the job's permissions and the secrets the workflow can read.

🔧 How to fix

Upgrade to a version outside the advisory's affected range (the advisory page lists a fixed-in version) and re-pin by SHA so a future retag cannot silently revert the fix. Configure Dependabot with package-ecosystem: github-actions to receive PR alerts when new advisories land against actions you already use.

✗ Before The pinned version is in the affected range of a published advisory.

# .github/workflows/release.yml — ❌ Affected by GHSA-mrrh-fwg8-r2c3
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: tj-actions/changed-files@v45.0.0   # CVE-2025-30066

✓ After Patched release pinned by SHA.

# .github/workflows/release.yml — ✅ Patched version pinned by SHA
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: tj-actions/changed-files@cc733854b1f224978ef800d29e4709d5ee2883e4 # v46.0.5

# .plumber.yaml
github:
  controls:
    actionsMustNotCarryKnownCVEs:
      enabled: true

💡 Tips

Exact tags (@v45.2.0) and SHA-resolved versions are point-checked against the advisory range. Moving partial tags (@v45, @v45.2) are span-checked across the whole release series and only fire when the entire span is vulnerable.
SHA pins are resolved through the repo's tag list to the most specific tag that points at the commit, so a moving major alias never shadows the exact release. A SHA without a resolvable release tag (and mutable non-numeric tags like @rc / @main) abstains with a 'could not verify' warning rather than flagging every advisory for that owner/repo.
Same scope limits as ISSUE-702: step uses: only, static YAML, no nested composite internals, no reusable-workflow callee files unless they live in this repo's .github/workflows/.
Without API auth the rule abstains (not a pass). Pair with Dependabot package-ecosystem: github-actions for ongoing alerts.
The PBOM tags affected includes with hasCve: true plus advisories: [GHSA-…] (JSON) / plumber:has-cve plus plumber:advisories properties (CycloneDX).

⚙️ Configuration

This control is configured in .plumber.yaml under the github section:

github:
  controls:
    actionsMustNotCarryKnownCVEs:
      enabled: true

See the CLI documentation for the full configuration reference.

📋 What is this?

⚠️ Impact

🔧 How to fix

💡 Tips

⚙️ Configuration

🔗 Related issues