Who should own controls for package source trust and runner secrets?

Why This Matters for Security Teams

Package source trust and runner secrets are often treated as separate concerns, but in practice they form one control surface: what code gets pulled into a pipeline and what authority the runner can exercise while it executes. If source resolution is weak, attackers can introduce malicious dependencies. If runner secrets are overexposed, that same code can exfiltrate tokens, keys, or certificates during build time. For a useful baseline, teams can map the problem to NIST SP 800-53 Rev 5 Security and Privacy Controls and then translate those controls into pipeline-specific enforcement.

The main failure is organisational: platform engineering usually owns the CI/CD system, IAM owns credentials, and security owns detection, but none of them can secure the outcome alone. Trust decisions happen at dependency resolution, while secret exposure happens at runtime, so a split ownership model without explicit control mapping leaves gaps. This is exactly where non-human identity governance becomes relevant, because runners, service accounts, and tokens are identities with standing authority, not just technical plumbing. In practice, many security teams encounter runner compromise only after a malicious package has already executed and a credential has already been reused outside the intended build context.

How It Works in Practice

Effective ownership usually follows the control plane, not the tool name. Platform engineering should own the mechanics of package source trust, including allowed registries, dependency pinning, mirror policies, signature verification, and build-time network restrictions. IAM should own the lifecycle of runner secrets, including issuance, rotation, scope, expiry, and revocation. Security operations should own monitoring, alerting, and response for suspicious package fetches, unexpected process spawning, token use outside the build window, and egress to unapproved destinations.

That division works best when the controls are written as shared requirements rather than informal habits. The OWASP Non-Human Identity Top 10 is useful here because runner tokens, workload credentials, and build identities all behave like non-human identities with their own lifecycle and abuse paths. A practical operating model usually includes:

• Allowlisted package sources and immutable version references for critical dependencies.
• Short-lived runner credentials with scoped permissions and automatic revocation after job completion.
• Secrets injection only at the job or step that needs them, never at broader pipeline scope by default.
• Central logging for package resolution, secret access, and process execution on runners.
• Alerting for dependency drift, unsigned artifacts, and abnormal runner egress.

Current guidance suggests treating the runner as a high-risk execution environment, especially when it has outbound internet access or can access production-adjacent secrets. The point is not to eliminate automation, but to reduce the blast radius if a package, plugin, or action is compromised. These controls tend to break down when legacy CI systems reuse long-lived tokens across many jobs because secret scope and package trust are no longer tied to a single execution context.

Common Variations and Edge Cases

Tighter package trust and runner-secret controls often increase build friction, requiring organisations to balance supply chain assurance against developer velocity. That tradeoff is real, especially in environments with large dependency graphs, private package mirrors, or self-hosted runners that need broad access to internal services. Best practice is evolving, and there is no universal standard for every pipeline pattern yet.

Edge cases usually appear where build systems are also deployment systems, or where runners need to reach internal registries, artifact stores, or test environments. In those cases, ownership can still be shared, but the control boundaries must be sharper: platform teams manage registry policy, IAM manages ephemeral credential issuance, and security defines detection thresholds and response playbooks. Agentic or automated build assistants raise the stakes further because tool-using software can amplify misuse of both package trust and secrets, so governance should explicitly cover non-human identities and execution authority. Teams should also distinguish between trusted internal packages and trusted execution, because a package from an approved source can still be unsafe once it runs with the wrong secret.

For programmes formalising this model, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary, while the OWASP guidance helps translate that vocabulary into CI/CD identity and secret-handling practice.

Related resources from NHI Mgmt Group

• Who should own response when a developer package exposes credentials?
• Who should own governance for shadow MCP servers and tool trust?
• Who should own accountability when bug bounty findings affect identity or access controls?
• Why do collaboration tools create such a large secrets risk?