GHSA-H829-5CG7-6HFF: Improper Tag Signature Verification in Gitverify

The gitverify utility (package github.com/supply-chain-tools/gitverify) provides cryptographic signature verification for Git objects. It operates by validating the integrity of commits and tags against defined security policies. The tool is commonly integrated into continuous integration and continuous deployment (CI/CD) pipelines to prevent unauthorized code modifications from entering production environments.

A logic inversion vulnerability exists within the tag verification routines of the tool. Specifically, the vulnerability affects the evaluation of security policies designed to enforce cryptographic signatures on annotated tags. This flaw allows unsigned annotated tags to pass validation checks, completely undermining the primary security function of the affected module.

The vulnerability is classified under CWE-347 (Improper Verification of Cryptographic Signature) and CWE-697 (Incorrect Comparison). The impact is directly tied to supply chain security, as automated systems relying on gitverify for integrity enforcement will accept unauthorized, unsigned state changes as legitimate.

The root cause of this vulnerability is a logic inversion within the validateTag function located in gitverify/verify.go. The verification engine analyzes a Git tag, determines its signature status, and assigns it a classification type. When a tag lacks any signature, it is correctly identified as SignatureTypeNone.

The engine then checks the repository configuration to determine if the security policy requires signed tags. The configuration variable repoConfig.requireSignedTags is a boolean value indicating this policy state. The logic block handling the SignatureTypeNone case uses the condition !repoConfig.requireSignedTags to determine if an error should be returned.

Due to the negation operator, the conditional check is inverted. If the policy requires signed tags (requireSignedTags == true), the negated condition evaluates to false. The error reporting block is subsequently skipped, and the unsigned tag is permitted to pass verification. Conversely, if the policy does not require signatures (requireSignedTags == false), the condition evaluates to true, and the code incorrectly raises a validation error.

The following diagram illustrates the flawed logic path during verification:

The vulnerability resides entirely within a switch statement in the validateTag function of gitverify/verify.go. The code evaluates the signature type of a provided plumbing.Reference object representing the tag. The specific defect exists within the case SignatureTypeNone: block.

The vulnerable implementation is shown below. The use of the ! operator introduces the critical logic flaw that enables the bypass.

case SignatureTypeNone:
    if !repoConfig.requireSignedTags { // Logic Inversion Bug
        return fmt.Errorf("unsigned annotated tag: %s", t.Name)
    }

The patch addresses the vulnerability by removing the negation operator. This single-character change aligns the conditional execution with the intended security policy. The fix ensures that an error is returned exclusively when the configuration explicitly mandates signed tags.

--- a/gitverify/verify.go
+++ b/gitverify/verify.go
@@ -711,7 +711,7 @@ func validateTag(tag *plumbing.Reference, state *gitkit.RepoState, repoConfig *R
 					return err
 				}
 			case SignatureTypeNone:
-				if !repoConfig.requireSignedTags {
+				if repoConfig.requireSignedTags {
 					return fmt.Errorf("unsigned annotated tag: %s", t.Name)
 				}
 			default:

Exploitation of this vulnerability requires the target environment to utilize gitverify with the requireSignedTags configuration enabled. This configuration is standard for organizations implementing strict supply chain security controls. The attacker must possess sufficient privileges to push tags to a repository monitored by the vulnerable instance.

The attacker initiates the exploit by creating a malicious, unsigned annotated tag within the target Git repository. The tag can be associated with unauthorized commits or altered release artifacts. Once the tag is pushed, the gitverify utility processes the repository state during the next automated run or manual invocation.

During processing, the validateTag function correctly identifies the attacker's tag as unsigned (SignatureTypeNone). However, the logic inversion causes the policy check to evaluate to false, bypassing the enforcement mechanism. The tool validates the repository state without errors, allowing the malicious references to enter downstream deployment or release pipelines.

The primary impact of this vulnerability is the compromise of supply chain integrity controls. Organizations relying on gitverify to prevent the dissemination of unsigned code will unknowingly accept unverified Git references. This facilitates the injection of malicious code or the manipulation of release versions without triggering security alarms.

Automated systems, particularly CI/CD pipelines that gate deployments based on the output of gitverify, are highly susceptible to this flaw. An attacker who successfully pushes an unsigned tag can trigger automated builds or deployments of unverified code. The vulnerability breaks the chain of trust established by cryptographic signatures.

The vulnerability is specific to tag verification and does not directly affect the verification of underlying commit signatures if they are evaluated independently. The scope of impact is limited to the bypass of the tag signature policy, resulting in a CVSS v3.1 score of 5.3 (Moderate) based on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.

The vulnerability is resolved by updating the github.com/supply-chain-tools/gitverify dependency to a version that includes commit c2c60da05d5c73621d0ce7ea02770bacd79ec8b1. All versions prior to this commit contain the logic inversion and should be considered vulnerable. Developers must rebuild and redeploy any binaries that statically link the vulnerable package.

In environments where immediate patching is not feasible, organizations can implement compensating controls. CI/CD pipelines should be configured to independently verify the cryptographic signatures of the underlying commits associated with a tag. This secondary validation step mitigates the risk by ensuring that the code itself is signed, even if the tag verification is bypassed.

Security and development teams should review automated testing procedures to ensure that negative test cases are implemented for security configurations. A unit test asserting that an unsigned tag fails validation when the policy is enabled would have prevented this regression.