How to Automate Code Signing in CI/CD
Automate software signing as part of your build and release process while keeping private keys protected. This guide covers signing architecture, secure credentials, Windows, macOS and Java workflows, verification gates, and release controls.
How Code Signing Automation Works
Automated code signing connects signing with the build, testing and release process so approved artifacts can be signed, verified and prepared for distribution.
The signing stage should run only after required build and testing checks pass. Verification should happen before publication, with failures handled according to the release policy. The exact implementation depends on the operating system, software format, CI/CD platform and signing infrastructure.
Build and test
Compile the application, run automated tests and generate release artifacts.
Authorize signing
Confirm the build is permitted to request a signature from the production signing system.
Sign and timestamp
Use the approved signing identity and a suitable timestamp service where applicable.
Verify and release
Check signature integrity and required trust conditions before publishing the final artifact.
Choose the Right Signing Architecture
Before writing pipeline scripts, decide how the signing operation will access the private key.
| Approach | How it works | Suitable for |
|---|---|---|
| Protected certificate store | The signing process accesses a certificate and its protected private key. | Controlled build agents |
| HSM based signing | The private key remains within a hardware security module. | Enterprise release infrastructure |
| Remote signing service | The pipeline requests signing from a separate service. | Distributed teams and automated releases |
| Cloud managed signing | An authorized workflow calls a managed signing service. | Cloud native CI/CD environments |
How to Protect Signing Credentials in CI/CD
A CI/CD workflow needs permission to request signing operations, but it should not expose the private key to every job.
For GitHub Actions, encrypted secrets can store sensitive configuration. Where the signing service supports it, OpenID Connect (OIDC) can provide short lived authentication without storing long lived cloud credentials in GitHub secrets. Restrict access using explicit trust conditions and appropriate environment protection rules.
Restrict workflow access
Allow signing only from approved branches, release tags or protected environments.
Protect credentials
Keep secrets out of console output, source files and build artifacts.
Use short lived identity
Use federated authentication where supported, instead of distributing long lived credentials.
Audit signing requests
Maintain records of which workflow requested a signature and for which artifact.
OIDC authenticates a workflow to a supported service. It does not itself perform code signing or guarantee that a service can use a particular certificate.
Choose a certificate for Windows releases
Match the signing certificate to the Windows software you distribute. Review certificate options before configuring the production signing job.
Windows Code Signing Automation Example
This example illustrates signing and verification in a Windows pipeline. It assumes SignTool is installed and the authorized runner can access the signing certificate and private key.
$artifact = "release.exe"
$certificateThumbprint = "YOUR_CERTIFICATE_THUMBPRINT"
$timestampUrl = "https://timestamp.example.com"
# Sign the release artifact
signtool sign `
/sha1 $certificateThumbprint `
/fd SHA256 `
/tr $timestampUrl `
/td SHA256 `
$artifact
if ($LASTEXITCODE -ne 0) {
throw "Code signing failed."
}
# Verify the signed artifact
signtool verify /pa /v $artifact
if ($LASTEXITCODE -ne 0) {
throw "Signature verification failed."
}Replace the placeholder thumbprint and timestamp URL with values from your signing environment. The certificate must be available to the process, and its private key must be accessible to the authorized signing operation.
The command sequence is not a complete CI/CD workflow. In production, also configure runner permissions, certificate access, error handling, release approvals and artifact retention.
The Windows step above uses SignTool to sign the release artifact and verify the resulting signature. For file-specific command details, review the implementation for signing an EXE file.
Automating macOS Signing and Notarization
macOS applications distributed outside the Mac App Store may require a workflow that includes Developer ID signing and notarization. A typical pipeline follows this order:
Submit the prepared archive
xcrun notarytool submit MyApp.zip \
--keychain-profile "notary-profile" \
--waitThe notary-profile must already be configured with appropriate authentication for Apple's notary service.
Staple and validate the ticket
xcrun stapler staple "MyApp.app"xcrun stapler validate "MyApp.app"Use the packaging and notarization sequence appropriate to your distribution format. Review Apple's notarization log and test the final artifact before release. Keep signing identity and notarization credentials available only to the authorized release job.
The macOS workflow should keep signing, notarization and final validation within the authorized release job. Follow the platform steps for signing macOS applications.
Automating Java JAR Signing
Java applications can use jarsigner in a controlled build pipeline. The signing identity should be accessed securely, and the pipeline should verify the resulting archive before publishing it.
Sign the archive
jarsigner \
-keystore "$KEYSTORE_PATH" \
-signedjar MyApplication-signed.jar \
MyApplication.jar \
"$SIGNING_ALIAS"This example assumes the keystore is securely provisioned and the signing operation has access to required authentication. Do not store a keystore password directly in the script.
Verify the signed archive
jarsigner -verify -verbose -certs MyApplication-signed.jarReview verification output and warnings before publishing the archive. The exact configuration depends on the Java version, signing algorithms and key management approach.
Plan signing for macOS distribution
For macOS releases, choose a signing identity that fits your distribution model and keep notarization credentials separate from general build access.
Verify Signed Artifacts Before Release
A pipeline should not publish software merely because the signing command completed.
After signing, verify the artifact using the tool appropriate for its format. For Windows, use SignTool. For Java, use jarsigner. For macOS, use codesign and the applicable Gatekeeper assessment and notarization checks.
Ensure that the artifact verified is the exact artifact being published. If packaging, copying or modifying files happens after verification, verify the final output again where appropriate.
When a deployment process includes packaging or release-stage changes, add a final verification before deployment check for the exact artifact that will be published.
Managing Signing Failures and Certificate Renewal
| Issue | What to check |
|---|---|
| Certificate expiration | Monitor expiry dates and plan renewal before the release pipeline is affected. |
| Private key access failure | Check permissions, key availability, token connectivity or remote signing service authentication. |
| Timestamp failure | Check the timestamp URL, network connectivity and supported algorithms. |
| Verification failure | Inspect the signature, certificate chain and diagnostic output. Do not bypass a mandatory failure to complete a release. |
| Notarization rejection | Review Apple's result and resolve the reported signing or software issue before distributing the artifact. |
When a signing job fails, use a repeatable process for code signing error troubleshooting before rerunning or approving the release.
Code Signing Automation Checklist
Use this implementation checklist before enabling production signing.
Set up signing for enterprise release pipelines
Teams with multiple products or controlled release environments can compare certificate options against their identity, governance and key-protection requirements.
Frequently Asked Questions About CI/CD Code Signing
What is automated code signing?
Automated code signing integrates signing commands or signing service requests into the software build and release process. It reduces manual steps while preserving controlled access to signing keys.
Can code signing be automated in GitHub Actions?
Yes. GitHub Actions can run signing and verification commands or call an authorized signing service. Protect production signing access and restrict which workflows can request signatures.
Should the private key be stored in CI/CD secrets?
Avoid storing raw private key material as an ordinary pipeline secret when a protected key store, HSM or remote signing service is available. The appropriate design depends on the signing platform and threat model.
Does automated code signing require timestamping?
Timestamping is generally recommended for publicly distributed signed software where the platform supports it. The exact method depends on the file format and signing tool.
What happens when automated signing fails?
The pipeline should capture the error, stop the release when signing is mandatory and prevent the affected artifact from being published until the issue is resolved.
Can code signing automation include notarization?
Yes. macOS distribution workflows can automate signing, submission to Apple's notary service, ticket stapling and verification using supported tools.
Automate Signing While Maintaining Control
Protect credentials, verify every required artifact, and release only software that meets your signing policy.