In a previous blog post, we discussed what qualities are required in an enterprise code signing system. Most of the questions we received on that post were about hash validation of deterministic builds and device authentication.
Given the attention around the SolarWinds incident and broader software supply chain attacks, it’s worth taking a closer look at automated hash validation—how it works, what it requires, and how it improves both security and performance in enterprise code signing.
For a broader view of software supply chain protection, see our companion article on preventing malware injections.
The Core Problem: Code Signing Without Strong Ties to Source
In many organizations, software development and code signing operate as separate or loosely coupled systems. This disconnect creates a dangerous gap:
It becomes possible to sign binaries that did not originate from your approved source code repository or artifact repository.
To eliminate this potential threat, a secure code signing system must be able to:
-
Verify that what is being signed exactly matches what is in the repository, and
-
Confirm that what’s in the repository is actually worth signing (i.e., has passed your security and quality controls).
Automated hash validation is designed to address the first part in a scalable, enterprise-ready way—and to create a strong foundation for the second.
Prerequisites for an Enterprise-Ready Approach
To be both secure and scalable, the code signing system should adopt a client-side hashing (or hash signing) architecture.
Client-Side Hashing (Hash Signing)
Instead of sending full binaries over the network for signing, the client:
-
Computes a cryptographic hash of the code or artifact locally
-
Sends only that hash, along with context (project, revision, etc.), to the signing service
-
The signing service generates the digital signature over the hash, not over the entire artifact
Benefits:
-
Performance: Significantly reduced bandwidth usage
-
Scalability: Faster signing operations, especially in CI/CD and high-volume environments
-
Security: Creates a consistent, verifiable reference point (the hash) that can be checked against the source of truth
Deterministic / Reproducible Builds
Hash-based validation only works reliably if the same source code always produces the same binary output. That’s where reproducible (deterministic) builds come in.
A reproducible build means:
-
Given the same source, config, and dependencies, the build system produces bit-for-bit identical output every time.
Many modern compilers and build tools already support deterministic builds, often due to their security and traceability benefits. In most environments, enabling or tightening deterministic behavior is an achievable task, not a fundamental blocker.
Once client-side hashing and reproducible builds are in place, verifying that the artifact to be signed matches the repository becomes a question of verifying that the hashes match.
Learn how a client-side hash signing architecture can accelerate digital signatures for a variety of use cases throughout your enterprise’s environment.
Solution 1: Manual Approvals (Good Security, Limited Scale)
The most straightforward way to verify that the requested hash from a signing client matches the hash from the repository is to have humans check.
A typical manual approval workflow looks like this:
-
The signing request is placed into a pending state.
-
A quorum of approvers (e.g., release managers, security leads) must approve the request before a signature is generated.
-
Approvers are shown:
-
The hash to sign
-
The identity of the requesting client
-
The key to be used
-
Any relevant metadata (e.g., project, branch, environment)
-
Using this information, approvers manually validate the request before it’s signed. Meanwhile, the signing client polls for either:
-
A successful signature, or
-
A failure (e.g., a rejection by one or more approvers)
You can refine this model further by:
-
Defining tiers of approvers with independent quorum requirements (e.g., engineering first, then change advisory board).
-
Requiring approvers to manually re-enter the hash to discourage “rubber-stamp” approvals.
Manual approvals are highly effective for infrequent, high-risk operations, such as:
-
Quarterly production releases
-
Emergency hotfixes
-
Highly sensitive components
However, they do not scale when:
-
You sign artifacts continuously in a CI/CD pipeline
-
You have hundreds or thousands of signatures per day
For those environments, you need to move from manual to automated hash validation.
Solution 2: Automated Hash Validation (Security at CI/CD Speed)
An automated code signing system must validate that the hash requested by the client matches the hash computed from the canonical source—without human intervention.
How Automated Hash Validation Works
-
The signing client sends a request that includes:
-
The hash to sign
-
A project identifier
-
A source control revision (e.g., commit ID, tag, branch/ref)
-
-
A dedicated component of the code signing system uses this information to:
-
Retrieve the corresponding source code from the repository
-
Perform a deterministic build of that software
-
Compute the expected hash from the freshly built artifact
-
-
The code signing system compares:
-
Hash from the signing client vs. hash from the fresh build
-
-
Based on the result:
-
If the hashes match, the system proceeds (or continues) with signing.
-
If they do not match, the request is blocked or flagged for investigation.
-
This approach ensures that only artifacts that truly originate from, and match, the repository can be signed.
Garantir’s flagship product, was built with:
-
A client-side hashing architecture for performance, and
-
Automated hash validation for strong security guarantees
The combination makes it possible to scale secure code signing across large CI/CD estates without compromising speed.
Extending the Model: Code Signing Analysis
By the time the automated build and hash validation process completes, the code signing system has access to:
-
The source code
-
The built binaries for that specific revision
This creates an ideal vantage point for additional analysis. The system can:
-
Run third-party security scanners (SAST, DAST, static analysis, antivirus, etc.)
-
Evaluate code quality metrics
-
Feed the results back into the policy decision of whether to sign or reject
In other words, automated hash validation can become a backbone for policy-driven code signing, where signatures are conditional on:
-
Matching repository state
-
Passing security and quality checks
-
Meeting specific compliance or regulatory criteria
Performance Considerations: Pre-Sign vs. Post-Sign Validation
A common concern with automation is performance impact—especially in CI/CD environments where latency directly affects delivery velocity.
Pre-Sign Hash Validation (Preventive, Highest Assurance)
In pre-sign validation:
-
The system validates the hash before generating any signature.
-
If validation fails, the signature is never created.
Security benefits:
-
Strongest guarantee: nothing invalid gets signed
-
Ideal for high-risk releases or strict regulatory environments
Trade-off:
-
Additional time is added directly on the critical path of the CI/CD pipeline.
-
For frequent builds, this can become noticeable.
Post-Sign Hash Validation (Detective, CI/CD-Friendly)
In post-sign hash validation:
-
The system signs the hash immediately.
-
Hash validation runs after the signature has been generated.
-
If a mismatch is detected, the system:
-
Flags or quarantines the signed artifact
-
Triggers alerts and downstream responses
-
Security profile:
-
Slightly weaker than pre-sign: a mismatched build may be signed temporarily
-
However, any discrepancy is detected and can be acted on quickly
Operational advantages:
-
The CI/CD pipeline does not wait for validation to complete.
-
Signing remains effectively as fast as a system with no validation at all.
Going a Step Further: Improving Overall Build Time
With automated post-sign hash validation, the code signing system:
-
Retrieves its own copy of the source and binaries
-
Can take over tasks that would otherwise run on the main build server
-
Executes these tasks in parallel with the pipeline
This allows you to offload certain compute-heavy tasks (e.g., security scans, additional validations) to the code signing/verification infrastructure.
The result:
-
Wall-clock time for the full pipeline can actually decrease compared to a single-server, sequential build process.
-
Total CPU time across all systems increases, but that’s often an acceptable trade-off given modern cloud and elastic compute options.
In short, with smart architecture, automated hash validation doesn’t just maintain CI/CD performance—it can optimize it.
Now, here’s a CI/CD pipeline with code signing.
The general goal is to make code signing as secure as possible while minimizing Y, the additional time taken for code signing, to the greatest extent possible.
However, with Automated Post-Sign Hash Validation, the secure code signing system gets its own copy of the source and binaries, so it can offload some of the processing that the CI/CD pipeline would otherwise take on, and complete this process in parallel. Using this approach the CI/CD pipeline now looks like:
Now, the overall time to complete a build is less than the original time to build. This is, of course, measured in wall-clock time (aka, elapsed real time). The overall CPU time (aka, processing time) will increase.
Automated Hash Validation and the SolarWinds Attack
A frequent question is whether automated hash validation would have helped prevent or detect the SolarWinds Orion compromise.
According to SolarWinds, the malware
“was not present in the source code repository” of the affected Orion products. This distinction is critical.
-
In this scenario, automated hash validation would compare:
-
Hash of the malicious build vs. hash built from the clean repository
-
-
Because the malware was injected after source control, the hashes would not match.
Outcome with hash validation:
-
In pre-sign mode, the malicious build would not be signed.
-
In post-sign mode, the mismatch would be detected and could trigger immediate investigation and incident response.
If, instead, attackers had managed to insert malware into the repository itself, the hash comparison would succeed (the signed artifact and repository-derived artifact would match). In that case:
-
Hash validation alone would not detect the compromise.
-
Detection would depend on:
-
Static/dynamic analysis tools
-
Code review
-
Behavioral or anomaly-based detection
-
In both scenarios, though, automated hash validation:
-
Dramatically reduces the attack surface
-
Makes it significantly harder to sign arbitrary binaries that don’t come from the repository
-
Creates a decisive control point for supply chain security
Regardless of its specific role in any given incident, automated hash validation is a high-value, high-leverage control that can be tuned for both security and performance.
For a deeper dive on secure software development, check out this post on preventing malware injections.
Putting It All Together with GaraTrust
Automated hash validation, combined with client-side hashing, allows enterprises to:
-
Ensure that only repository-backed code can be signed
-
Embed security and quality checks directly into the code signing decision
-
Maintain or even improve CI/CD performance
-
Strengthen defenses against supply chain attacks like those seen across the industry
GaraTrust, Garantir’s flagship product, is designed around these principles. It:
-
Uses client-side hashing to accelerate digital signatures
-
Implements automated hash validation to bind signing to source control
-
Secures private keys in HSMs or key managers
-
Supports strong authentication and fine-grained policy, including:
-
MFA
-
Device authentication
-
Approval workflows
-
Per-key and per-user controls
-
If you’re looking to harden your code signing process and improve your software supply chain security without slowing down your teams, GaraTrust can help.
