How to Verify Software Before Deployment

What Does Software Verification Before Deployment Mean?

Software verification before deployment is the process of checking that a release meets defined integrity, authenticity, security and operational requirements before it is promoted to production or distributed to users.

For code-signed software, verification helps establish whether the signature is valid under the selected verification policy and whether the signed content has changed. Certificate validation helps assess the signer's identity and trust chain. Additional checks establish whether the artifact passed testing and matches the approved release.

Verification generally covers five areas:

These checks complement one another. A valid signature does not prove that software is free of vulnerabilities, and a matching hash does not by itself establish who produced the artifact.

Software Verification Workflow Before Deployment

The exact checks depend on the software format and deployment environment. A Windows executable, macOS application, Java archive and Linux package may require different signature verification tools and trust policies.

Step 1: Confirm the Artifact Being Verified

Before running verification commands, establish exactly which file is being considered for release.

Record its filename, version, build identifier, source revision and intended deployment environment. If the release contains multiple files, identify which components require their own signatures and which package or installer will be distributed.

Check that:

• The artifact came from the expected build pipeline.
• The build completed successfully.
• The release version and package metadata are correct.
• All required changes were completed before signing.
• The file being verified is the one intended for deployment.

This step prevents a common release mistake: verifying one file and deploying another.

Step 2: Verify the Code Signature

The verification command depends on the platform and file type.

Verify a Windows executable

Microsoft SignTool can verify an Authenticode signature using the default Authenticode policy:

signtool verify /pa /v "MyApplication.exe"

Review the output for a successful verification result and inspect the certificate and timestamp details.

The /pa option selects the default Authenticode verification policy, and /v provides verbose output. Drivers and other specialized artifacts may require a different verification policy or additional checks.

If verification fails, investigate the exact error rather than assuming that the certificate is defective. The file may have changed after signing, the certificate chain may be untrusted, or the signing process may have used an unsuitable identity.

Verify a macOS application

Use Apple's code signing tools to inspect an application bundle:

codesign --verify --deep --strict --verbose=2 "/Applications/MyApp.app"

Review the command output and investigate any invalid or missing signatures. The --deep option can help with diagnostic checks, but it is not a replacement for correctly signing nested components.

Basic signature verification is separate from Gatekeeper assessment and notarization. Applications distributed under workflows requiring notarization should undergo those checks as well.

Verify a Java JAR archive

Use jarsigner to check the signatures in a Java archive:

jarsigner -verify -verbose -certs application.jar

Inspect the output for verification failures, unsigned entries and certificate warnings. Also check whether the signing certificate is trusted under the security policy of the target Java runtime.

A JAR that verifies cryptographically may still encounter trust or algorithm restrictions in a particular environment.

When command output is ambiguous, How to Verify a Code Signature provides a broader validation workflow, while How to Verify a Code Signature From the Command Line covers verification from a terminal or build script.

Step 3: Validate the Certificate and Publisher Identity

A successful signature check should be followed by a review of the signing identity and applicable trust requirements.

Confirm that:

• The publisher name matches the expected organization or developer.
• The certificate is appropriate for code signing.
• The certificate chain leads to a trusted root under the target system's policy.
• Certificate validity and revocation status meet the applicable requirements.
• The timestamp is present and valid when required by the release policy.
• The signature uses algorithms accepted by the target platform.

A certificate can be technically valid but belong to an unexpected publisher. Conversely, an unfamiliar publisher name does not automatically mean the signature is invalid. Compare the identity with the release record and the publisher information approved for that product.

Check the timestamp

A trusted timestamp can help establish when a signature was created. This can be important when a signing certificate expires, although the final validation result depends on the timestamp, revocation status and applicable policy.

Do not treat the presence of a timestamp alone as proof that the entire artifact is trustworthy. Verify the signature and certificate chain as well.

A timestamp helps establish when the signature was created, which can matter when a signing certificate expires; How to Timestamp Signed Software explains the timestamping step and its validation requirements.

Step 4: Verify Artifact Integrity With a Hash

A cryptographic hash provides a compact fingerprint of a file. Comparing the hash of a candidate artifact with a hash recorded by a trusted build or release process helps establish whether the file has changed.

For example, calculate a SHA-256 hash on Windows:

Get-FileHash "MyApplication.exe" -Algorithm SHA256

On Linux or macOS, use:

sha256sum MyApplication

On macOS, shasum is also available:

shasum -a 256 MyApplication

Compare the result with the hash recorded for the approved release artifact.

Hash verification and signature verification serve different purposes:

Use these checks together where appropriate.

Step 5: Test the Software and Its Dependencies

Code signing does not replace software quality assurance. Before deployment, run the tests required for the application's risk level and release policy.

Common checks include:

• Functional and regression tests.
• Dependency and software composition analysis.
• Static application security testing where applicable.
• Malware scanning of release artifacts.
• Configuration and secrets checks.
• Compatibility tests for supported operating systems and runtime versions.
• Installation, upgrade and rollback tests.
• Runtime smoke tests in a representative environment.

For installers, test the actual installation and uninstallation process. For application packages, verify that required files and dependencies are present. For containerized software, validate the image and its associated supply chain controls using the mechanisms appropriate to that environment.

A signed release can still contain vulnerable code, a compromised dependency or an unsafe configuration. Verification should therefore include both authenticity checks and the security controls required by your team.

Step 6: Verify Software Packages and Installers

If a release contains an installer and an application, verify the relevant artifacts individually.

For example, a Windows release might contain:

• MyApplication.exe, the main executable.
• MyInstaller.msi, the installer package.
• Supporting DLL files.
• Update utilities or additional executables.

The installer signature does not automatically sign every executable it contains. Similarly, signing an executable does not establish that the installer packaging or installation process is correct.

For macOS, verify the application bundle and any separately signed installer package using the relevant Apple tools. For Java, verify the signed JAR archive and check the certificate trust configuration of the intended runtime.

See How to Sign Software Packages and Installers for the signing side of this process.

Step 7: Enforce Verification in the Deployment Pipeline

Manual checks are useful during development, but production releases should enforce verification automatically wherever practical.

A secure deployment pipeline should fail closed when a mandatory signature, integrity or release policy check fails. It should not continue to deployment simply because the build succeeded.

Follow these practices when implementing the pipeline:

Promote the same artifact. Build once and promote the verified artifact through the release stages when your deployment architecture permits. If a later operation changes signed content, repeat the required signing and verification steps.

Protect signing credentials. Restrict signing access to authorized release jobs and identities. Keep private key material out of source code, ordinary build artifacts and unprotected variables.

Retain verification evidence. Record the artifact hash, build identifier, signature verification result, release approval and deployment outcome.

Block failed releases. Make signature and integrity verification mandatory checks when required by your release policy. Investigate failures before allowing deployment to proceed.

Related guides:

A repeatable release workflow connects signing to release approvals, while the CI/CD signing guide covers the pipeline implementation, and the software release process guide explains how to integrate signing into release stages.

Common Software Verification Failures

When verification fails, the error can point to a changed artifact, certificate trust issue or signing configuration problem; How to Troubleshoot Code Signing Errors covers those common failure modes.

Pre-Deployment Software Verification Checklist

Frequently Asked Questions