Accountability should sit with the maintainers who own the release process, but it must be shared across code owners, security reviewers, and CI administrators. The team that can change workflow logic, tag rules, or artifact publication settings should also own the control checks. Clear ownership reduces the chance that privileged release steps remain unreviewed or weakly governed.
Who actually owns release trust in an open source project?
Accountability for release artifacts and workflow permissions should follow control over the release path, not just repository visibility. In open source projects, the people who can approve code, change workflow logic, manage tagging, or publish artifacts are the ones who can prevent a compromised release from reaching users. That makes ownership a governance question as much as a technical one.
Open source release security is often weakened when responsibility is split informally between maintainers, security volunteers, and infrastructure admins without a named control owner. The practical test is whether a specific role can be held responsible for the integrity of signing, publishing, and permission changes. If no role can answer for those decisions, the release process is effectively governed by assumption rather than accountability. In practice, many projects discover that their weakest release controls were never formally owned until a publishing mistake or workflow abuse exposed the gap.
How release artifacts and workflow permissions should be assigned in practice
Release accountability should be anchored to the maintainers who own the release process, because they are the people best placed to decide what is acceptable to ship and who may publish it. That does not mean maintainers carry every operational task alone. Code owners should review changes that affect release logic, security reviewers should validate privileged paths and signing requirements, and CI administrators should control the build and publication environment. The point is to align ownership with the ability to change a control, not merely with the ability to observe it.
Where the project uses automated pipelines, the workflow definition is itself part of the trust boundary. If a contributor can alter a job that signs, tags, uploads, or promotes an artifact, then release assurance depends on that permission being tightly governed. This is where many projects need explicit review gates, separation between code changes and workflow changes, and clear rules for who may approve exceptions. The ownership model should also cover service accounts, tokens, and deployment credentials used by the pipeline, because release integrity can fail even when the source code review looks sound.
A useful operating rule is that the team responsible for the release decision must also be able to evidence the control checks around publication. That includes who approved the release, who can modify the workflow, and who can revoke access if the process is misused. Without that linkage, the project may have security policy on paper but no durable way to enforce it. The OWASP Non-Human Identity Top 10 is relevant here because release pipelines often depend on machine credentials and automated identities that need explicit ownership.
These controls break down when maintainers assume infrastructure teams will secure publication by default, or when CI permissions are treated as purely operational rather than as part of release governance.
Where release ownership gets confused, and what to do about it
Tighter release control often increases coordination overhead, requiring projects to balance fast publishing against stronger approval and permission boundaries.
Projects with many contributors, multiple release branches, or externally run infrastructure often need a sharper distinction between development ownership and release ownership. It is common for code owners to understand the software but not the pipeline, while CI administrators understand the pipeline but not the security meaning of a release decision. That split can work only if the accountability model names who has final authority over publication and who must review changes to the release path. Guidance here is less uniform than in mature enterprise environments, so teams should treat the ownership model as an explicit governance choice rather than a convention.
Another edge case appears when release artifacts are built in one system and published in another. In that model, accountability must extend across both systems, or the project creates a blind spot between build integrity and publication integrity. The same is true when release permissions are delegated to a small subgroup for speed: if that subgroup can bypass review, then the project has moved from shared accountability to concentrated trust. The right response is not to remove all delegation, but to make delegation visible, time-bounded, and reviewable.
The NIST SP 800-53 Rev 5 control family on access control is relevant to this ownership problem because release permissions are still permissions, even when they sit inside a software supply chain. The control fails when the project cannot show that publication rights, workflow changes, and approval authority are assigned, reviewed, and revoked as intended.
Risk and Threat Considerations
Release artifacts and workflow permissions create a supply-chain risk because they sit on the path from source code to trusted distribution. If an attacker, rogue contributor, or over-privileged maintainer can alter workflow logic or publication settings, they may be able to inject malicious code into a legitimate release process without changing the visible project history.
Failure mechanism: The risk materialises when workflow permissions, signing keys, tags, or artifact publication rights are more permissive than the release governance model assumes. Abuse can occur through stolen credentials, unauthorized workflow edits, compromised automation identities, or mis-scoped review rules that allow sensitive release steps to proceed unchallenged.
Impact: The project may publish tampered artifacts, undermine user trust, or distribute compromise at scale through the normal update path. In an open source ecosystem, that can affect downstream adopters who rely on signed releases, package registries, or automated deployment pipelines.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Release and workflow permissions are privileged access paths that need ownership and review. |
| Recommendation — Apply Control 6 to assign, review, and revoke release and CI permissions on a named ownership basis. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Release pipelines depend on machine identities and credentials that need clear ownership. |
| Recommendation — Inventory and govern pipeline tokens, signing keys, and automation credentials as owned non-human identities. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Release governance depends on limiting who can approve, publish, or alter workflow permissions. |
| GV.RM-06 — Supply Chain Risk Management | Open source release ownership is a supply-chain governance problem with downstream trust impact. | |
| Recommendation — Enforce PR.AC-4 to restrict release-path changes to explicitly authorised maintainers and administrators. Assign supply-chain risk ownership for release paths and verify publication controls are governed end to end. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Compromised release credentials can be abused to sign or publish malicious artifacts. |
| Recommendation — Monitor for exposed release credentials and rotate any keys that could sign or publish artifacts. | ||
Practitioner Guidance
What to prioritise: Name one accountable owner for the release process, then assign review and approval duties to the people who can actually change publication logic, not just the people who understand the code. The accountability chain should be explicit for workflow changes, tagging, signing, and artifact promotion.
What to verify: Check whether release permissions, CI access, and token ownership match the governance model on paper. If a person or service can publish artifacts but cannot be challenged through review, logging, or revocation, the control is weaker than it appears.
Common mistake: Treating release security as an infrastructure task alone. The release owner must remain responsible for the trust decision, while platform teams provide the technical safeguards that make that decision enforceable.
Practitioner takeaway: The safest open source release model is the one where authority, access, and review all point to the same named control owner, rather than being spread across roles that no one can fully govern.
Related resources from NHI Mgmt Group
- Who should be accountable for securing open source projects that are scanned with AI tools?
- Who is accountable for securing workflow editing permissions and runtime isolation in automation platforms?
- Who is accountable when a forged open-source release is published to a package registry and container registry?
- When should teams treat open source contribution workflow as a security issue?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
