Skip to main content
View Markdown ↗

Copy this page

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

On this page

Bring evidence you already have

Most teams arrive with evidence that already exists: signed provenance from a build system, scanner output in a CI artifact, test reports, policy documents in a GRC tool. The platform does not treat these as one kind of thing. What a record can prove depends on who signed it and what that signer actually observed, and a new signature never adds facts the signer did not see.

Pick the path by asking two questions: is the record already signed, and is it machine-readable output from a tool you can run again?

You havePathWho signsWhat the signature proves
A DSSE envelope signed by your own build or toolingUpload the signed envelopeThe original producer. The platform adds no signature.Whatever the original producer's signature proves. The upload keeps those bytes and that signature unchanged.
Unsigned scanner, SBOM, test, or JSON output from a command you can runRecapture it under CI/lockThe credential cilock signs with: your key, your CI identity, or the platform signer you configuredThat this credential signed cilock's claim that the command ran and produced these exact bytes. Not that the data is true or complete, and not who operated the command unless the credential identifies them.
A narrative document: policy, procedure, contract, audit letterKeep it in your GRC system, optionally upload a copyThe platform, for a receipt onlyThat the platform received a file with a given SHA-256 at a given time. Not who wrote it or whether it is accurate.
A format or source that none of the above fitsAsk for an assisted evaluationNot applicable until a supported path existsNothing yet. Treat it as unsupported until TestifySec confirms a path in writing.

There is no general import for arbitrary JSON or files you already hold. A file that existed before a CI/lock run is not a product of that run, and the attestors that read results refuse it.

Upload a signed envelope

Use this when a tool you trust already produced a signed DSSE envelope, such as an attestation collection from an earlier cilock run that could not reach the platform at the time.

  • Send the envelope bytes to your platform's /archivista/upload endpoint with an API token that carries the attestation:upload scope. When cilock run cannot store an envelope, it keeps it on disk and prints the exact upload command.
  • The platform refuses an envelope with no signature, an empty signature, or an empty key ID. Admission checks that the signature fields are present and does not check the signature cryptographically.
  • Verification happens when a policy evaluates the evidence: a step counts it only if the signature verifies against a signer that step trusts. An uploaded envelope from a signer your policy does not name is stored and searchable, and it does not satisfy a gate.
  • What is preserved: the original envelope, byte for byte, including the original signature and the producer identity it carries. The platform does not re-sign it, so provenance stays with the original producer.

The Archivista storage guide shows the same upload against a standalone Archivista.

Recapture an unsigned result

Use this when you have unsigned output from a tool you can run again: a SARIF report, an SBOM, JUnit-style test results, a Trivy scan, or JSON from an API.

Run the producing command under cilock run with the matching attestor, so the output is written during the run. The SARIF, SBOM, test results, and structured-data attestors all read from the run's products, the files the wrapped command created or changed. Prefer a format-specific attestor over structured-data when one exists, because it validates the format instead of treating it as opaque JSON.

  • What the new signature proves: the signing credential signed cilock's record that this command, in this environment, wrote these exact bytes. Subjects and digests bind the claim to the content. The signature identifies the credential, so it names the operator only if the credential does: a keyless CI identity ties the claim to a pipeline, while a shared key file does not tie it to a person.
  • What it does not prove: that the scanner was configured well, that the results are complete, or anything about an earlier run. An old report copied into a new run becomes a product of the new run, and the attestation then records only the copy.
  • Original provenance: if the upstream tool signs its own output, keep and verify that signature separately. Recapture does not carry it forward.

Keep documents in your GRC system

Policies, procedures, contracts, and audit letters stay in your existing GRC system as the system of record. They are not machine output a command can reproduce, so recapture does not apply.

You can upload a copy to the platform's document repository for search and control mapping. Know exactly what that gives you:

  • The platform signs a receipt recording the file's SHA-256, name, MIME type, tenant, and upload time. It is signed with the platform's own key, so it proves receipt by the platform, not authorship, approval, or accuracy.
  • Extraction, classification, and control mapping that follow are each recorded as further platform-signed statements. Classification and mapping are generated by the configured model provider. Treat them as suggestions for a reviewer, not as an assessment.
  • The receipt does not replace the document's approval trail in your GRC system.

Ask for an assisted evaluation

If your evidence is in a format no attestor reads, comes from a system you cannot run under CI/lock, or needs a decision about what to trust, contact TestifySec before relying on it. An assisted evaluation decides which of the paths above applies, or records that none does yet. Until then, do not count the evidence toward a gate.