A signature binds an artifact to a signing key or identity and makes unauthorized changes detectable during verification. To make that useful, the receiving system has to enforce a trust policy. A release workflow should define the artifact format, the allowed signer, and the action to take when verification fails.
Start with the verifier
Cosign is a practical choice for signing OCI artifacts in container delivery workflows. With identity-based signing, verification can check the expected identity and OpenID Connect issuer. Use an immutable digest for the artifact reference so that the deployment policy evaluates the bytes that will actually run.
Microsoft SignTool supports signing, timestamping, and verification for Windows workflows. It is a natural fit when the build already runs in a Windows SDK environment and the receiving platform expects Authenticode.
Jsign also produces Authenticode signatures for supported Windows files and can fit pipelines that run on other operating systems. Test your exact installer format and signing provider, then verify the result using the receiving Windows environment.
Design the failure path
Put production signing behind a narrowly scoped release identity. Separate test and production signers, and let the release workflow use a protected key without exporting it wherever the supported signing provider allows. Keep an audit record connecting each signing event to its artifact and build.
Take one valid artifact through the full pipeline, then try an altered copy and a copy signed by a different identity. The deployment or distribution process should reject both. Finally, rehearse signer replacement so the team knows how to update trust policy and recover if the original signing identity becomes unavailable.