CyberArk Code Sign Manager - Self-Hosted vs OpenPubkey
CyberArk Code Sign Manager - Self-Hosted
docs.venafi.comOpenPubkey
github.comSide by side
| Figure | CyberArk Code Sign Manager - Self-Hosted | OpenPubkey |
|---|---|---|
| Price from | — | Free |
| Free plan | — | Yes |
| Free trial | — | — |
| Open source | — | — |
| Web | Yes | — |
| Windows | Yes | Yes |
| macOS | Yes | Yes |
| Linux | Yes | Yes |
| API | Yes | Yes |
| Self-hosted | Yes | Yes |
| Plans published | 0 | 1 |
| Spec score · Code Signing Software | 7.9 (#9) | 8.3 (#6) |
| Purpose | Protects and governs use of private code signing keys managed by Trust Protection Foundation. | OpenPubkey binds user or workload identities to public keys through OpenID Connect, allowing identities to sign messages or artifacts. |
| Support | The maker says existing customers can continue to access product documentation, support, and guidance, and should use their existing support path for product-specific help. | The project directs feature requests, bug reports, and technical questions to GitHub issues and points users to its OpenSSF Slack channel. |
Plans
CyberArk Code Sign Manager - Self-Hosted
No plans published.
In their own words
CyberArk Code Sign Manager - Self-Hosted
CyberArk Code Sign Manager - Self-Hosted protects and governs private code signing keys managed by Trust Protection Foundation. Keys can be held in the platform’s Secret Store or on an HSM. Administrators can set restrictions based on purpose, user, and IP address, and configure whether signing requires approvals. Approval flows can have multiple levels, limited-use approvals, and expiration options; approvers receive email notifications to review requests. The system audits key use, and APIs expose event logs and signing statistics. REST APIs can request signing, manage projects and environments, set user rights, inspect logs, and approve or reject requests. Identities and groups can be added through Active Directory or an LDAP provider and assigned roles in signing projects. Clients are available for Windows, Linux, and macOS, with interfaces including CSP/KSP, PKCS#11, GPG, and macOS Keychain; .NET is listed for Windows. GPG private keys remain within Trust Protection Foundation while public keys and private-key stubs synchronize to workstations. Installation is part of a Trust Protection Foundation deployment and requires several listed components, including Certificate Lifecycle and Monitoring, Key Lifecycle and Monitoring, HSM Backend, Authentication Server, Web Console, and Web SDK. Pricing is on request.
OpenPubkey
OpenPubkey binds a user or workload identity established through OpenID Connect to a public key, so the identity can sign messages or artifacts. A PK Token represents control of an OIDC identity and its related private key at a particular time, provided the verifier trusts the identity provider. The project lists Google, Azure/Microsoft, Okta, OneLogin and Keycloak as compatible without changes to those providers; however, its client and verifier currently create and verify tokens from Google for users and GitHub for workloads. Current workload identity use requires GQ signatures. For user identity, they are unnecessary when the PK Token is not public. GQ signatures allow the identity provider’s signature to be stripped from an ID Token while preserving proof of that signature, preventing use against OIDC resource providers. OpenPubkey says it needs no additional certificate authority because the OpenID Provider fulfills that role. Public PK Tokens can reveal claims from an OIDC ID Token, potentially including a name or email address. The project is free under the Apache 2.0 license and is a Linux Foundation project; its repository says it is being prepared for version 1.0. The project directs technical questions to GitHub issues and offers a community Slack channel.