Code Signing for Open Source Software

Open source software does not become trustworthy simply because its source code is public. Users normally install compiled artifacts rather than compiling the exact source tree themselves, and those artifacts can be modified, replaced or redistributed independently of the public repository. Code signing adds a publisher identity and an integrity check to the release artifact, which gives users another way to distinguish an official release from an altered or unofficial copy.

The practical value is strongest when a project distributes desktop applications, installers, executables, libraries or packages that support signing, Java applications, scripts, plugins, drivers or release archives containing signed artifacts. The signing mechanism still depends on the platform and file format, so one certificate should not be treated as a universal solution for every open source distribution channel.

Open source projects often use several signing mechanisms at the same time because they protect different stages of the software lifecycle. Git commit signing can authenticate a contributor's commits. Release signing can authenticate the software artifact distributed to users. A package repository can apply its own signature or trust model to packages. These controls complement one another rather than replacing one another.

This distinction becomes important when a project has many contributors but only a small release team. A contributor can have a verified commit history without having permission to sign an official release. Conversely, an official release signer may not be the person who wrote every component in the release.

This is the main buying decision for an open source maintainer. There is no universal open source certificate that every project must use. The relevant option depends on who is legally or operationally responsible for the release, whether the project qualifies for a dedicated program and which platforms are being served.

Dedicated open source certificates can be useful where a CA has created a product or program specifically for qualifying public projects. Individual certificates can represent a maintainer when the release identity is personal. Organization validated certificates can represent a company, foundation or other eligible organization. EV certificates are a separate organization validation path where the project and applicant qualify.

An Open Source Code Signing Certificate is a certificate product intended for qualifying open source software publishers. The important part is the qualification relationship. The certificate is not automatically issued merely because a project is available on GitHub or because its license is open source.

The CA can require evidence that the project is publicly available, that the applicant is connected to the project and that the intended use matches the program's conditions. The resulting certificate still establishes a subscriber identity and signing key relationship. The project itself does not become a legal entity simply because it has a certificate.

Certum's current Open Source product describes the certificate as intended for programmers or developers who share software as open source. Its product page also describes certificate storage and verification requirements.

Open source projects create an identity problem that commercial software teams often solve through a company name. A project may have a public name, a repository organization, individual maintainers, a foundation and thousands of contributors. The certificate still needs a subscriber identity that a CA can validate.

That means the project name, the person maintaining the project, the organization behind the project and the certificate subject should be treated as four related but distinct concepts. The release process should explain why the certificate holder is authorized to publish official builds even when the broader project has many contributors.

The public nature of the source code does not make the private signing key public. The key is the credential that authorizes the signature, so anyone who obtains usable signing authority may be able to produce artifacts that appear to come from the project's official publisher identity.

For a small project, a hardware protected token can provide a straightforward local signing boundary. Projects with automated builds or distributed maintainers may need remote signing or cloud HSM infrastructure so that the private key does not need to be copied into each build environment. HSM based signing also creates a natural place to enforce authentication, access controls and audit logging.

Backup strategy requires care. A project should not casually create exportable copies of a production signing key just to make recovery easier. If the key cannot be recovered after loss, the incident plan should define how a replacement certificate and new signing identity will be introduced.

Active open source projects often release through GitHub Actions, GitLab CI/CD, Jenkins or Azure DevOps. Automation makes releases repeatable, but it also changes the signing security model because the build environment can become a target for anyone trying to obtain release credentials.

The safer architecture is to let the build system produce and test the artifact while a protected signing service performs the private key operation. The pipeline can authenticate to the signing boundary, submit the approved artifact, receive the signed result and continue with timestamping and release publication. The production key does not need to become an exportable file inside the runner.

Windows open source projects commonly use Authenticode for EXE, DLL, MSI and other supported Windows artifacts. SignTool can perform signing and verification, while the certificate chain and timestamp become part of the post-signing validation process.

The project should decide which artifacts are official release components and sign the final versions of those files. Signing an EXE does not automatically mean that an MSI installer containing that EXE is also signed. Similarly, a release package can contain multiple DLLs that may need signatures according to the project's distribution requirements.

macOS software follows Apple's signing ecosystem. A public CA code signing certificate for Windows is not a replacement for the Apple Developer ID certificates and platform controls used for direct macOS distribution. Projects distributing applications outside the Mac App Store may need Developer ID signing and notarization so that the release works within the Gatekeeper trust model.

The practical workflow can include codesign for application signing, Apple's notarization service and verification of the resulting application bundle before publication. Open source status does not remove these platform specific requirements. The project should therefore keep macOS signing credentials and procedures separate from its Windows certificate workflow.

Code signing is one control in a larger open source release security chain. Contributor authentication helps establish who changed the source. Code review helps maintain project quality. Build controls reduce unexpected transformations. Dependency controls address the software included in the release. Release signing then provides identity and integrity evidence for the artifact that leaves the build system.

Keeping these layers separate makes incident response easier. A compromised contributor account, a compromised build runner and a compromised signing key are different events with different containment actions. A mature project should know which control failed and which releases may have been affected.

A project can have hundreds of contributors and still have only two or three people authorized to publish official binaries. That distinction should be explicit. Contribution rights should not automatically grant release signing rights.

Practical controls include a dedicated release account, a protected signing key, release approval, a restricted CI/CD environment, maintainer authentication and audit logs. For larger projects, remote signing can further separate the build environment from the production signing credential.

A suspected signing key compromise should be treated as a release security incident. The project should stop further signing with the affected credential while it determines which systems, artifacts and release windows may have been exposed. The objective is to prevent additional artifacts from being signed under an identity that may no longer be controlled by the project.

The response then moves through certificate revocation where required, replacement key generation, certificate issuance, infrastructure updates and re-signing of affected releases. If users may have downloaded affected artifacts, the project should assess whether a public security advisory and explicit release replacement notice are appropriate.

A lightweight signing policy can prevent a project from making release security decisions ad hoc. It does not need to become a large compliance document. It should answer the practical questions a maintainer needs during a normal release and during an incident.

The appropriate signing model depends on project structure rather than project size alone. A small project with weekly releases can have different needs from a large project that releases every day, while a foundation backed project may need organizational ownership even if the actual release team is small.

Use the framework below to identify the main control you need. It is not a ranking. The purpose is to map project characteristics to the signing considerations that follow from them.