# Push verification

Source: https://www.testifysec.com/docs/pushgate/trust/push

How Pushgate binds a Git push to signed evidence and a policy decision before GitHub delivery.

The gate verifies identity, evidence, and policy context for the exact proposed update before delivery.

 

**Diagram: Push verification sequence**

The agent sends refs and a Git pack to Pushgate. Pushgate verifies the request, asks the platform to evaluate the exact commit and policy, verifies the returned signed decision, and forwards an accepted update to GitHub.

Policy admission is complete before Pushgate sends an accepted update to GitHub.

**Mermaid source**

```
sequenceDiagram
    participant A as Agent
    participant P as Pushgate edge
    participant T as TestifySec platform
    participant G as GitHub
    A->>P: git push (refs + pack)
    P->>P: Verify push identity and bindings
    P->>T: Evaluate exact commit and policy
    T-->>P: Stored, signed VSA
    P->>P: Verify VSA signature and bindings
    P->>G: Forward accepted update
    G-->>P: Terminal upstream result
```

 

## Request binding

 

A push certificate authenticates the actor who sent the ref update. Pushgate then evaluates every proposed non-deletion commit against the repository’s policy snapshot. Multi-ref pushes are judged as a set; evidence for one commit is not replayed as evidence for another.

 

## Edge verification

 

Pushgate verifies at Cloudflare’s edge so the decision stays on the Git push path. This is a consumption-time admission point: the [CNCF Secure Software Factory architecture](https://tag-security.cncf.io/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory/) calls for downstream systems to verify attested metadata before using an artifact. Before acting on a platform VSA, the Worker checks:

 

1. the DSSE envelope and certificate chain;
 2. the exact authorized platform signer and issuer;
 3. the repository tenant, canonical route, and immutable repository ID;
 4. the commit, fresh nonce, nonce scope, and policy digest; and
 5. the signed `PASSED` or `FAILED` outcome.

 

## Admission and delivery

 

A passing policy decision authorizes Pushgate to deliver; it is not proof that GitHub applied the refs. Pushgate forwards the accepted update with a repository-scoped GitHub installation token and records the validated terminal upstream result separately. This preserves the distinction between policy enforcement and source-control delivery.

 

## Decision semantics

 

| State | Meaning | Gate action |
| --- | --- | --- |
| `PASSED` | The signed policy decision and every binding verified. | Eligible for delivery. |
| `FAILED` | The signed policy decision found unmet requirements. | Apply the repository’s configured enforcement or exact approved override. |
| Unavailable | No complete, trustworthy signed decision exists. | Do not treat it as a policy pass. |

Reference generated from the product documentation. Match commands and support details to your installed release.