Skip to main content
View Markdown ↗

Copy this page

Select and copy the Markdown below, then paste it into your LLM.

System architecture

TestifySec connects three jobs: record the work, evaluate the evidence, and act on the decision. CI/lock, Pushgate, and the platform participate at different points. You can start with the part your workflow needs.

Read the trust model alongside this page. Architecture explains where a record travels; the trust model explains what a reviewer can conclude from it.

CI/lock records work as signed evidence. The Platform evaluates it against the selected policy, and Pushgate enforces the decision. Delivery to the Git host is a separate result.

Scroll horizontally to explore the diagram, or open the full-size SVG.

From work to a gate decision. CI/lock records work as signed evidence. The Platform evaluates it against the selected policy, and Pushgate enforces the decision. Delivery to the Git host is a separate result.
Open full-size SVG ↗Download Mermaid source
Diagram source (Mermaid)
flowchart TB
  W[Developer or agent runs a workflow] --> C[CI/lock captures observations]
  C --> E[Signed evidence]
  E --> P[Platform evaluates selected requirements]
  R[Exact policy release] --> P
  P --> G[Pushgate enforces the decision]
  G -->|If accepted and forwarded| U[Upstream Git host]
  U --> D[Separate delivery observation]

One system, different responsibilities

ComponentResponsibilityWhat it does not establish by itself
CI/lockCollect configured workflow observations and produce signed execution evidence.That every supplied report is truthful, the collector is uncompromised, or the code is safe.
TestifySec PlatformManage repository gates, policies, identities, evidence, and mappings between technical results and controls. Evaluate evidence against the selected requirements.That an unsigned description is authoritative or a passing technical check satisfies a whole compliance program.
PushgateEnforce the configured repository decision at the Git push boundary.That direct paths around the gate are protected or that an accepted push was delivered upstream.
Software applianceRun the platform within an agreed customer-operated environment.A different trust model with no operator responsibilities or external dependencies in every configuration.

Follow a repository change

  1. Record the work. Run the required build, test, or scan under the intended collection boundary. CI/lock captures the configured observations. The record needs the subject and identity information required by the policy.
  2. Make the evidence available. Store the signed record where the verifier can retrieve it. Upload authority and signing authority are separate; being allowed to upload a record does not make its producer trusted.
  3. Select the requirements. The repository's configured assignment identifies the policy to evaluate. A display name or a mutable latest label is not the policy's immutable identity.
  4. Evaluate the evidence. The platform checks the selected requirements and records the decision with its required repository, commit, policy, and evidence bindings.
  5. Enforce at the gate. Pushgate uses that bounded decision for the push. Protect alternate routes at the Git host as part of the repository configuration.
  6. Inspect the result. Distinguish a policy decision, gate acceptance, and downstream delivery. A delivery record must be interpreted according to what its deployed receipt version actually binds.

A signed policy artifact, a published release, and a repository assignment are separate objects. Signing a policy does not activate it for a repository. An assignment approval does not make the approving account the policy author.

Continue with Pushgate setup and its security coverage.

Follow a technical-control assessment

A recovery rehearsal, remediation verification, or configuration check can use the same evidence foundations without involving a Git push.

  1. Define the technical requirement and the test that observes it.
  2. Run the test with CI/lock under the intended collection boundary.
  3. Inspect the signed result and its subject, producer, and scope.
  4. Map the result to the technical control it supports in the platform.
  5. Review the assessment's coverage, remaining gaps, and freshness.

The mapping expresses a relationship between evidence and a control. It does not expand the test's scope. A successful recovery rehearsal for one service does not prove recovery works for every system.

Start with one part, reuse the same concepts

Starting pointImmediate taskWhat can follow
CI/lockRecord and verify one workflow.Reuse accepted evidence in a repository gate or a technical-control assessment.
PushgateProtect one repository's push path.Manage additional connected gates and their requirements through the platform.
Technical controlsReview the result of a real operational check.Build repeatable assessments from scoped tests and configured mappings.
Platform deploymentAgree the operating and trust boundary.Configure identity, evidence storage, policies, repository connections, and support for that environment.

Deployment changes who operates the boundary

Hosted and appliance deployments need explicit answers about the trusted roots, signing services, evidence storage, administrator authority, updates, backups, and recovery. A customer-operated deployment moves operating responsibility; it does not remove it.

Some workflows can verify portable evidence offline. That is a specific verification capability, not a promise that every connected repository, identity provider, or deployment workflow operates without a network.

Choose a workflow, then review what the system proves and what it assumes.