Evidence as a Push Pipeline

Cash the checks this training has been writing

Count what your pipelines now produce: SARIF from the IaC scanner (3.4, “emitted even though nothing consumes it yet”), the scan matrix’s control-ID column (3.5), test results (4.x), promotion manifests and hop verifications (5.1), SBOMs and attestations (5.2). Every one is evidence — proof a control operated — currently scattered across run artifacts where an auditor will never find it. Today every audit, customer security review, and incident retrospective begins with someone spending days reassembling proof the pipelines already produced. The pattern that cashes it, from the reference software factory: a push-model evidence pipeline — evidence doesn’t wait to be collected; the pipeline delivers it, so ‘prove it’ becomes a query instead of a quarter:

per run:  scan/test/build outputs
             │  package into a BUNDLE: the raw outputs + a manifest mapping
             │  each item -> control IDs (from the scan matrix) + run
             │  provenance (pipeline, commit, timestamp, artifact hashes)
             ▼
          POST the bundle manifest to the compliance/evidence API
             (or, floor version: an append-only evidence store - a
             blob container with immutability - if no API exists yet)

The properties that make this a system rather than a folder: evidence arrives continuously (every run, not quarterly panic), carries its provenance (which commit, which pipeline, which artifact — the 5.1 hashes binding proof to product), and — the design’s best idea — what-proves-what is declared as data:

// evidence-models/iac-scan.json - reviewable, versionable, diffable
{ "evidenceType": "iac-scan-sarif",
  "controls": ["CM-6", "SC-7", "RA-5"],
  "source": "checkov step, any pipeline extending starters@v1+",
  "freshness": { "expectedCadence": "per-PR", "staleAfterDays": 7 } }

A declarative evidence model per evidence type: which controls it supports, where it comes from, how fresh it must be. The compliance conversation transforms — “what proves CM-6?” is a query; “is our evidence current?” is a freshness check; and a gap (a control no model covers) is enumerable instead of discovered during an audit. This lesson owns the push mechanics; the catalog-and-collectors side is built out in Cloud Modernization’s closing lesson, and Zero Trust’s honest-grading lesson supplies the five-value vocabulary for what the evidence shows — three lessons, one system, each owning its lane.

Where this lands in practice — the buy-vs-build question leadership will actually ask: most commercial estates already own the endpoint, a GRC platform (governance, risk, and compliance — the tool category that tracks controls and evidence; the Vanta / Drata / Secureframe / ServiceNow class, each with an evidence-ingest API), and should push there rather than build a store. Federal and FedRAMP-bound estates should shape the bundle toward a machine-readable package format — OSCAL (NIST’s format for control catalogs, implementation statements, and assessment results) for the RMF and DoD lineage, FedRAMP’s own JSON for its rewritten lane — because structured evidence is where those programs are heading, even though most packages today still arrive as Word and Excel and the government systems of record do not yet ingest either format natively (the Federal Delivery training’s two-formats lesson covers that reality). The pipeline is the same either way; the endpoint is a purchasing decision, and the append-only blob container is the floor for estates that have neither yet.

Name what you already practice

Now the naming move, and it’s this lesson’s free money. Run the audit prompt below against your own estate and a strange thing surfaces — the reference estate’s version of it found: artifact integrity verified at every hop, provenance digests on builds, dependency pinning with review, secret scanning gates, two-person change control. That list is, nearly line for line, a set of practices from NIST’s Secure Software Development Framework (SSDF) — the federal government’s named list of secure-development practices, which the estate never cited anywhere. Same for supply-chain build-integrity levels (SLSA) it substantially met, and for federal DevSecOps reference designs it independently reinvented chunks of.

Why naming matters, concretely: an unnamed practice is invisible to procurement questionnaires, buyer security reviews, and federal solicitations that ask for the framework by name — you’re doing the work and forfeiting the credit. The naming exercise costs an afternoon and produces the mapping table that answers a year of questionnaires:

The artifact - three moves:
1. WIRE the push: the evidence-bundle step template (package outputs +
   control manifest + provenance, POST or append-only store), added to the
   starter pipelines' deploy stage - with the evidence models for our five
   existing evidence types declared as JSON
2. MAP the estate: for SSDF's practice groups, the SLSA build levels, and
   (if federal-adjacent) the DevSecOps reference design's tiers - which of
   our existing controls implements each, with the evidence model that
   proves it; honest five-value grading (the ZT scale) where coverage is
   partial; gaps enumerated, not padded
3. NAME it publicly: the one-page 'frameworks we practice' doc, each claim
   pointing at an evidence model, none at aspiration - the difference
   between this and marketing is that every line is a query someone
   can run

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Push evidence per-run — bundles carrying outputs, control mappings, and provenance — into a store where proof is a query; declare what-proves-what as versioned evidence models with freshness contracts; and name the frameworks your estate already practices so the work you’re doing earns the credit it’s owed. Owned, CI-checked, alarm-witnessed: compliance machinery is machinery. One module remains: the team that runs all of this as a product.

LEADERSHIP DECISION   fund an evidence owner and an endpoint (GRC platform, or
                      OSCAL-shaped bundles for federal work) - not another
                      audit-season scramble
PRACTITIONER ACTION   add the evidence-bundle step to the starter pipelines,
                      declare evidence models as JSON, map the estate to
                      SSDF/SLSA with honest grades
SUCCESS MEASURE       audit and questionnaire response time drops from days of
                      reassembly to a query; every 'frameworks we practice'
                      line points at a runnable check