Push verification

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

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 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