How to Sign Software in a CI/CD Pipeline
Integrate code signing into your automated release process so approved software artifacts are signed, timestamped where appropriate, verified, and protected before publication or deployment.
How Code Signing Fits Into CI/CD
A pipeline should sign the intended release artifacts, protect the private key, add a trusted timestamp where appropriate, and verify the final files before publication.
The goal is not simply to automate a signing command. Only authorized artifacts should be signed, signing credentials must remain protected, and verification should happen before deployment. The implementation depends on the platform, software format, CI/CD provider, and signing infrastructure.
Windows EXE and MSI
Use Authenticode with SignTool.
DLL and PowerShell
Use Authenticode or applicable catalog signing for DLLs, and PowerShell script signing for scripts.
Java JAR
Use Java's jarsigner utility.
macOS applications
Use Apple's code signing tools, including codesign or Xcode where appropriate.
Prepare the Code Signing Environment
Identify the software artifacts that need signatures and select the correct signing mechanism before adding signing to a pipeline.
Install the required signing tools on the relevant runner or build agent. Confirm that the signing identity is available to the authorized signing process.
For Windows, SignTool is included in the Windows SDK and supports signing, timestamping, and signature verification. Make sure the pipeline uses the intended tool version and signing identity.
Protect the Signing Private Key
The private key is one of the most sensitive components of an automated signing workflow. Unauthorized access could allow someone to sign software that appears to come from your organization.
Do not place private keys, certificate passwords, or other signing credentials directly in source code, repository files, build scripts, or ordinary pipeline logs.
Protected CI/CD secrets
Store required credentials in the platform's secret management system. Restrict access to authorized workflows and avoid printing secret values during builds.
Hardware security modules
An HSM can protect signing keys and perform signing operations without exposing the private key as an ordinary file.
Remote signing services
A pipeline can request a signing operation from a separate signing service while the private key remains in a controlled environment.
Workload identity
Where supported, use short lived federated authentication to authorize a pipeline to access signing infrastructure instead of distributing long lived credentials.
GitHub's build security guidance discusses encrypted Actions secrets and OpenID Connect as options for protecting access to signing infrastructure.
A pipeline that delegates signing to a protected service can keep key material outside the build runner; private-key protection is especially important when build jobs execute code from different trust levels.
Sign Windows Software in the Pipeline
For a Windows release, the pipeline can call SignTool after the build and tests have completed. This example assumes the signing certificate is available in a protected certificate store accessible to the authorized signing process.
signtool sign /fd SHA256 /tr https://timestamp.example.com /td SHA256 /n "Your Organization" "release.exe"
if ($LASTEXITCODE -ne 0) {
throw "Code signing failed."
}Replace the example timestamp URL with the endpoint provided by your timestamp authority, and replace the certificate subject and file path with your actual values. The command uses SHA 256 for the file digest and timestamp digest, while /tr specifies an RFC 3161 timestamp service.
If multiple certificates match the specified subject, configure certificate selection more precisely so the pipeline uses the intended signing identity.
Verify the signed artifact
signtool verify /pa /v "release.exe"
if ($LASTEXITCODE -ne 0) {
throw "Signature verification failed."
}This checks the signature under the default Authenticode verification policy and reports detailed information. The pipeline should stop publication if verification fails or if a warning violates your release policy.
Choose a signing certificate for your release workflow
Match the certificate type to your software, publisher identity, and distribution requirements before you automate production signing.
Sign macOS Software in a CI/CD Pipeline
macOS application signing follows Apple's signing and distribution workflow. For apps distributed outside the Mac App Store, this commonly involves Developer ID signing, Hardened Runtime, secure timestamping, and notarization.
Verify the application bundle
codesign --verify --deep --strict --verbose=2 "MyApp.app"Apple's command line tools include notarytool and stapler, which can be integrated into an automated build and distribution workflow.
For macOS releases, the application signing and notarization workflow covers the platform-specific steps that follow a successful build.
Add Signing to Your CI/CD Workflow
Signing should normally happen after the artifact has been built and tested, but before it is published.
Build
Compile the application and produce release artifacts.
Test
Run automated tests and quality checks.
Approve
Confirm the artifact is eligible for signing.
Sign and timestamp
Use the authorized signing identity and timestamp where appropriate.
Verify
Validate the signature and required trust conditions.
Publish
Release only the approved final artifact.
For stronger release controls, separate ordinary build jobs from privileged signing jobs. Limit which branches, tags, users, and workflow definitions can request a production signature.
Automate Code Signing Safely
Automation reduces repetitive manual work, but it should not give every build unrestricted signing access.
These controls help reduce unauthorized signing and release artifact tampering. GitHub's build security guidance also recommends protecting the build process and access to signing credentials.
Teams that need separate build and signing permissions can use a dedicated CI/CD signing automation workflow to formalize access and release controls.
Verify Software Before Deployment
A successful signing command does not finish the release process. Verify the final artifact before deployment or publication.
For Windows, SignTool can verify signatures and report trust or revocation problems. For macOS applications, signature verification and Gatekeeper assessment can be separate steps. For Java archives, use the appropriate JAR verification command.
Before a release is published, a pre-deployment software verification checklist helps confirm the signed artifact meets the release policy.
Common CI/CD Code Signing Problems
| Problem | Possible cause | What to check |
|---|---|---|
| Signing identity unavailable | Certificate or key is not accessible to the runner. | Certificate store, key permissions, and signing service access. |
| Signing command fails | Incorrect parameters or unsupported configuration. | Tool version, command arguments, and certificate selection. |
| Timestamp request fails | Timestamp endpoint or network problem. | TSA URL, connectivity, and supported algorithms. |
| Signature verification fails | Artifact changed or signature is invalid. | Confirm the exact file and inspect verification output. |
| Pipeline cannot access credentials | Secret permissions or identity configuration. | Workflow permissions and access policy. |
| Notarization fails | macOS signing, entitlement, or notarization issue. | Apple submission logs and signing configuration. |
| Unsigned artifact gets published | Verification stage is missing or does not block release. | Pipeline dependencies and failure handling. |
When troubleshooting, preserve the original build artifact and inspect the full error output before retrying the signing operation.
When a signing or validation step fails, code signing error troubleshooting helps isolate certificate, timestamp, tool, and pipeline configuration issues.
CI/CD Code Signing Checklist
Use this release readiness checklist before enabling production signing.
Frequently Asked Questions
What is code signing in a CI/CD pipeline?
It is the integration of digital signing into an automated build and release workflow so approved software artifacts can be signed and verified before distribution.
At what stage should software be signed?
Usually after the relevant build and tests have completed and before the final artifact is published. The exact stage depends on the platform and release process.
Can code signing be fully automated?
Yes. Signing, timestamping, and verification can be automated. Production signing should still have controlled authorization, protected keys, and clear release policies.
Should the private key be stored in the CI/CD pipeline?
Avoid storing private key material directly in repository files or ordinary pipeline configuration. Depending on the platform, use protected secret storage, hardware backed signing, or a remote signing service.
What happens if code signing fails in the pipeline?
The release job should report the error and prevent publication when signing is mandatory. Investigate the failure before retrying or releasing the artifact.
Does code signing replace software testing?
No. Code signing helps establish signer identity and software integrity. Testing, dependency checks, security review, and release approval remain separate controls.
Should signed software be verified before deployment?
Yes. Verification confirms that the signature meets configured checks and helps ensure that the intended signed artifact is the one being deployed.
Related Code Signing Implementation Guides
Continue with signing automation, private key protection, release process controls, and deployment verification.
Plan certificate selection before production rollout
Review validation options, signing requirements, and operational considerations before choosing a certificate for your release pipeline.