A maintained action is a curated replacement for a third-party GitHub Action that is actively reviewed, updated, and released under controlled processes. In practice, the term signals lower operational risk because the code is still supervised, release controls exist, and changes are managed with security review rather than left to chance.
Expanded Definition
A maintained action is not just a popular replacement for an external automation component. It is a deliberately supervised version of a GitHub Action that remains under review, receives updates, and is published through controlled release practices. That matters because the security question is not whether the action works today, but whether the code path can be trusted tomorrow when dependencies, permissions, or maintainers change. In the supply chain context, this aligns with the broader control intent described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need disciplined review, change control, and integrity protection. Usage in the industry is still evolving, and definitions vary across vendors and repositories, but the operational meaning is consistent: maintainers are actively accountable for the code. The concept sits between a frozen pinned dependency and an ungoverned third-party action. The most common misapplication is treating a maintained action as inherently safe, which occurs when teams assume maintenance alone eliminates the need for pinning, review, and permission scoping.
Examples and Use Cases
Implementing maintained actions rigorously often introduces a governance overhead, requiring organisations to balance developer convenience against the cost of review, release checks, and dependency monitoring.
- A security team replaces an unreviewed build step with a maintained action that is versioned, signed, and tracked through a controlled release pipeline.
- A platform team approves only maintained actions for CI workflows that can access repository secrets, reducing the chance of unvetted code execution.
- An engineering group audits a maintained action against OWASP Non-Human Identity Top 10 guidance when the action uses tokens, service credentials, or other non-human identities.
- A compliance team documents why a maintained action is preferred over a community fork, because the maintainer can respond to vulnerabilities and dependency drift.
- A release engineering team pins the action to a trusted commit and monitors upstream changes before allowing automatic adoption of new versions.
For identity-heavy pipelines, the difference becomes acute when the action can mint credentials, read secrets, or interact with cloud APIs. If the workflow touches authentication material, the action should be treated as a privileged component, not just a convenience wrapper. Controls around provenance, code review, and runtime permissions mirror the intent found in the NIST software supply chain security guidance, where trust depends on traceability and managed change.
Why It Matters for Security Teams
Security teams care about maintained actions because CI and automation pipelines often hold the same trust level as administrators, especially when they can access repositories, secrets, deployment targets, or cloud roles. If a workflow component is abandoned, compromised, or silently modified, the blast radius can include source code, production credentials, and release integrity. A maintained action reduces that exposure only when governance is real, meaning ownership is explicit, update cadence is visible, and permission scope is constrained to the minimum necessary. This is where identity and NHI governance intersect directly: the action may operate as a non-human identity, consume secrets, and trigger downstream privileged operations. That makes review discipline, secret scoping, and dependency provenance central rather than optional. The issue is also closely related to secure software supply chain expectations in the CISA secure software development resources. Organisations typically encounter the consequences only after a compromised workflow or a broken upstream release disrupts builds, at which point maintained action governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Managed change and review align with secure development and maintenance practices. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control is central to approving maintained actions and their updates. |
| OWASP Non-Human Identity Top 10 | Maintained actions often handle non-human identities, secrets, and automation trust. |
Track maintained actions under controlled change processes and review updates before adoption.
