Abandoned actions and the frozen actor

An abandoned action is an action whose maintainer has moved on. The action is not malicious; the action is unmaintained. The bytes the runner pulls do not change. The world around the bytes does: new CVEs in transitive dependencies, new runner images with new system libraries, deprecated endpoints in the APIs the action calls. The frozen action becomes a frozen attack surface, and no one patches it because no one is home.

What “abandoned” actually means

An action is abandoned when the maintainer has stopped responding to:

• Security advisories. A CVE is published against the action or its transitive dependencies. The maintainer is the only person who can publish a patched release.
• Dependency updates. A widely-used package ships a security fix. The action’s package.json references the old version.
• API changes. The cloud provider deprecates an endpoint the action calls.
• Compatibility changes. GitHub ships a new runner image with a new Node version. The action’s pinned Node is unsupported.

flowchart LR
    A["Day 1 - action published"] --> B["Runner image v1"]
    A --> C["Dependency version v1"]
    A --> D["API version v1"]
    E["Day 600 - maintainer gone"] --> F["Runner image v47"]
    E --> G["Dependency v1 still installed"]
    E --> H["API v1 deprecated"]
    F -. "new CVEs" .-> G
    F -. "no patches" .-> H

The action is unchanged. The action’s environment is not. The gap is where the security debt accumulates.

The signals of abandonment

Five signals indicate abandonment risk: (1) no commits in 12 months; (2) open issues with no response for months; (3) no release in 18 months; (4) transitive dependencies pinned to old versions; (5) maintainer account inactive. None is conclusive alone, but together they paint a picture of an action with no one left to fix it. The distinguishing test is responsiveness: an abandoned action does not respond to security reports within a reasonable window.

Why pinning to a SHA does not help

Pinning to a SHA closes the tag-swap attack. Pinning does not close the abandonment gap. The pinned SHA still resolves to the same bytes. The same bytes still depend on the same vulnerable transitive packages and still call the same deprecated APIs. The bytes are immutable; the environment is not.

Distinguishing abandoned from stable

Three patterns look like abandonment but are not:

• Feature-complete mature projects. A linter, parser, or transformer. The project has converged; the lack of commits is the goal.
• Versioned stable branches. The maintainer commits to main regularly but treats v1.x.x as a frozen LTS branch.
• Vendor-owned projects with batch updates. A cloud vendor publishes quarterly releases; the action appears unmaintained between batches.

The distinguishing test is responsiveness. A stable action’s maintainer responds even if the response is “triaged, not patching”.

Production discipline

1. Maintain an action inventory. List every third-party action with the maintainer, last commit, last release, and pin. Review quarterly.
2. Set a deprecation threshold. No commits in 18 months, no release in 24 months, and an unresponsive maintainer means the action is deprecated.
3. Prefer vendor-owned actions for vendor-specific work. aws-actions/*, azure/*, google-github-actions/* are first-party to their vendors.
4. Audit transitive dependency age at pin time. An action pinning ^1.0.0 of a dependency that is now ^4.0.0 upstream is at risk of breaking on the next major release.
5. Plan a fork as a fallback. Fork the action into your own organisation, vendor the dependencies, and maintain the fork internally. The fork is first-party.

Cross-course references

• Git, CI/CD & GitOps — Part LXVI-03 (Supply-Chain Attack) covers the malicious-maintainer case.
• Git, CI/CD & GitOps — Part LXVI-05 (Pinning to SHA) covers the immutable-reference defence.
• Git, CI/CD & GitOps — Part LXV-05 (Artifact Trust) covers the content-addressing model.
• Linux for Production Sysadmins — Part XXIV (Package Security) covers the system-level analogue.

Quiz