atelier/domains/compliance/evidence.md

Evidence — Derived Rules

Derives from domains/compliance/first-principles.md. Covers P6 (Evidence is Collected Continuously), P5 (Policy is a Gate, so decisions are evidence), P7 (Identity Attributable, so evidence has provenance), and P10 (Posture Observable, so evidence is queryable). Referenced by audit-logs.md (logs are evidence) and data-retention.md (evidence has a lifecycle).

Evidence is Collected Continuously (P6 Evidence is Collected Continuously)

• Evidence of compliance — logs, configs, scans, attestations, policy decisions, access reviews — is gathered as a byproduct of operation, not assembled manually at audit time. The audit-time scramble is the anti-pattern: it is expensive, it is incomplete, and it produces evidence that is reconstructed rather than recorded.
• Continuous evidence collection means the audit packet is a query over already-collected artifacts, not a forensic reconstruction. The auditor asks "show me the access reviews for Q3" and the answer is a query against the evidence store, not a six-week project.
• This is the compliance angle on domains/observability/tracing.md for distributed evidence (a trace spans the request that produced the evidence) and domains/observability/metrics.md for posture signals (a metric is a continuous evidence stream).

Evidence is a Byproduct, Not a Deliverable

• Evidence collected as a byproduct is trustworthy: it records what happened, when it happened, recorded by the system that did it. Evidence assembled at audit time is less trustworthy: it records what someone remembered to write down, when they wrote it, after the fact.
• The mechanism: every significant action (audit-logs.md) emits its record to an evidence store; every policy decision (policy-as-code.md) emits its decision; every deployment emits its signed attestation; every access review emits its result. The store is append-only (audit-logs.md P1), queryable (P10), and retention-bound (data-retention.md).

Provenance and Identity (P7 Identity is Attributable)

• Evidence has provenance: which system produced it, when, from what input. An evidence artifact with no provenance is anecdote, not evidence — it cannot be attributed to a source, so it cannot be trusted.
• Provenance includes the identity of the producer (a workload identity, a service account) and the chain of custody (who has had access to the artifact since it was produced). Cross domains/security/authorization.md: the producer's identity is authenticated, not assumed.

Signed Attestations (IDEATE-29)

• A signed attestation is evidence with a cryptographic signature binding the artifact to its producer. The signature is the provenance: it can be verified independently of the producer, and it cannot be forged without the producer's key. Cross domains/security/supply-chain.md for the supply-chain angle.

• Cosign (Sigstore) and in-toto are the canonical patterns: a builder signs an artifact (container image, deployable, evidence bundle) at production time; a verifier checks the signature at consumption time. The signature is the evidence that the artifact came from where it claims to have come from.

• Illustrative signed attestation (Cosign / Sigstore format, NOT a real signature — illustrative only, no live keys):

  // Cosign attest — bind an attestation to an image digest
  // (illustrative; not a real signature)
  $ cosign attest --type spdxjson \
      --predicate sbom.spdx.json \
      my-registry/app@sha256:5a3e1c...f9b2
  
  // The attestation is stored as a signature in the registry,
  // bound to the image digest. The payload is a DSSE envelope:
  
  {
    "payloadType": "application/vnd.in-toto+json",
    "payload": "eyJfdHlwZSI6ImF0dGVzdGF0aW9uIn0...",
    "signatures": [
      {
        "sig": "MEUCIQDx...illustrative-base64-signature...==",
        "keyid": "cosign-key-2024-q4"
      }
    ]
  }
  
  // The decoded payload (an in-toto statement binding the
  // attestation to the image digest):
  {
    "_type": "https://in-toto.io/Statement/v0.1",
    "predicateType": "https://spdx.dev/Document",
    "subject": [
      {
        "name": "my-registry/app",
        "digest": { "sha256": "5a3e1c...f9b2" }
      }
    ],
    "predicate": {
      "SPDXID": "SPDXRef-DOCUMENT",
      "creationInfo": {
        "created": "2024-11-07T15:03:22Z",
        "creators": ["Tool: atelier-build-pipeline"]
      }
    }
  }
  
  // Verification (independent of the producer):
  $ cosign verify-attestation --type spdxjson \
      --certificate-identity-regexp '.*atelier-build.*' \
      my-registry/app@sha256:5a3e1c...f9b2
  // Verification succeeded for: my-registry/app@sha256:5a3e1c...f9b2
  // SBOM attestation found for subject
  

• The attestation is illustrative — the signatures and digests are not real. The shape (DSSE envelope, in-toto statement, subject + predicate, verify-by-identity) is what evidence-as-attestation looks like. A real attestation carries a real signature from a real key held by the builder.

Audit-Ready Export

• The evidence store is queryable at any time, not only at audit time. The audit packet is a query (a date range, a data class, a subject) over the store; the export is a dump of the matching artifacts with their provenance and signatures.
• An audit-ready export that requires six weeks of forensics is a P6 violation dressed as a success: the evidence was not collected continuously, it was reconstructed. The export should be a query that runs in minutes, not a project that runs for weeks.

Evidence Lifecycle

• Evidence has a retention lifecycle (data-retention.md): an evidence artifact is retained for the audit cycle it supports, then ages out. The retention rule for evidence is itself audited (deletion of evidence is a meta-audited action, like deletion of audit logs).
• A legal hold suspends evidence deletion for a defined set — the same mechanism as audit-log holds.

What Violates Evidence Discipline

Violation	Principle
Evidence assembled by hand the week before an audit	P6 Evidence is Collected Continuously
An evidence artifact with no provenance (no producer, no timestamp)	P7 Identity is Attributable
An audit packet that requires six weeks of forensics to produce	P6 Evidence is Collected Continuously
An attestation with no signature (provenance asserted, not proven)	P7 Identity is Attributable
Evidence store not queryable between audits	P10 Compliance Posture is Observable
Evidence deleted before its retention period with no meta-audit	P6 Evidence is Collected Continuously
Policy decisions not recorded as evidence	P5 Policy is Evaluated as a Gate
A deployment with no signed attestation of its build provenance	P7 Identity is Attributable

Relationship to Other Domains

• domains/security/supply-chain.md — signed attestations are the supply-chain integrity primitive; evidence.md is the compliance consumer of the same artifact.
• domains/observability/metrics.md — posture metrics are a continuous evidence stream.
• domains/observability/tracing.md — distributed traces provide evidence that spans a request across services.
• domains/compliance/audit-logs.md — audit logs are a primary evidence artifact; the append-only guarantee is what makes them admissible.
• domains/compliance/policy-as-code.md — policy decisions are evidence of enforcement; the policy code itself is evidence of the rule.
• domains/compliance/data-retention.md — evidence has a retention lifecycle tied to the audit cycle.