Wire the Pipeline to the Package

Two systems, one wire

Lesson 6.1 located the process gap precisely: evidence arrives continuously, then waits for humans to assemble it into a package on a calendar. This lesson closes that gap with a wire between two systems this training’s ecosystem already built.

On one side: the evidence push pipeline — this site’s DevSecOps Foundations training and its capstone pattern (Evidence as a Push Pipeline — in short, for readers starting here: every pipeline run pushes a bundle — scan outputs, test results, provenance — mapped to control IDs, into an append-only store; evidence models declared as data say what-proves-what with freshness contracts). On the other side: this training’s catalog-driven assessment machinery (2.1’s evidence contracts, 3.1’s collectors and verdicts, 2.3’s deterministic exports). The wire:

pipeline run completes (build/scan/test/deploy)
  -> evidence bundle pushed: outputs + control-ID manifest + provenance
       (commit, pipeline, artifact hashes)          [the DevOps push]
  -> bundle lands in the evidence store (3.2): content-addressed,
       WORM, provenance digests
  -> the CATALOG's evidence contracts (2.1) recognize the bundle:
       these entries name pipeline-pushed evidence types alongside
       collector-pulled ones - push and pull are PEERS feeding one
       contract
  -> the evaluator (3.1) re-runs affected controls: strict-AND,
       800-53A vocabulary, coverage accounting updated
  -> the EXPORTS regenerate (2.3): OSCAL, docs site, Word package
  -> byte-equality gate: if nothing assessment-relevant changed,
       output is byte-identical -> NO-OP. If something changed ->
       a DIFF, routed to humans as a reviewable change

Read the last step twice, because it’s the design’s center of gravity: determinism (2.3) is what makes a self-updating package safe. Without it, every pipeline run would churn the package and reviewers would drown in noise — automation would reduce assurance. With it, the package is quiet until reality changes, and when reality changes, the package diff is the change review: one firewall control’s verdict flipping to partial shows up as three legible lines in a generated SSP, not as a regenerated document nobody re-reads. The byte-equality gate is thereby promoted from CI hygiene to the release gate for compliance artifacts — package versions are cut exactly when reality diffs, at the cadence of change rather than the cadence of quarters. That’s authorization-as-stream’s engineering half: the stream is a sequence of small, reviewed, provenance-carrying package diffs.

Which humans stay in the loop

Automating the assembly line does not automate the judgments — and the design is honest only if it names which gates survive:

SURVIVES AUTOMATION (judgment gates):        AUTOMATED AWAY (assembly toil):
- implementation statements: authored          - collating evidence into
  by humans, always (2.2's line holds -          binders by hand
  the wire moves evidence, never claims)       - re-typing verdicts into
- verdict-flip review: a control changing        documents
  state is a human-reviewed diff before        - regenerating exports and
  the package version ships                      diffing them by eye
- the acceptance itself: the AO (or their      - noticing that evidence
  ongoing-authorization mechanism) decides;      went stale (freshness
  the wire feeds the decision a stream           contracts page someone
  instead of a quarterly binder                  instead)

The failure mode to design against is the middle one quietly disappearing: a package that re-versions on every verdict flip without review recreates 3.1’s automation theater one level up — tooling attesting to tooling, now with the AO’s signature downstream of it (2.2’s warning, industrialized). The verdict-flip review is cheap (it’s a diff), and it’s the human link that makes the stream trustworthy.

Prompt first: close the loop on one control

Wire one control end-to-end as our pilot - pick SC-7 (it has both
pipeline-pushed and collector-pulled evidence):
1) extend the catalog entry's evidence contract to name the pipeline
   bundle types (scan SARIF, deploy manifest) alongside the collector
   feeds - schema change reviewed like any code;
2) subscribe the evaluator to store events for those types; re-run
   SC-7's checks on arrival; verify strict-AND and coverage.md update;
3) regenerate exports on verdict change ONLY (byte-equality gate
   proves the only-ness); route the diff to the ISSO as a PR-style
   review titled with the control and the flip;
4) run the drill: introduce a deliberate misconfiguration in staging,
   watch the whole wire fire - push, verdict flip, package diff,
   review - and MEASURE the latency from pipeline event to reviewable
   diff. That number is your evidence-to-package lag; log it in the
   gap statement (6.1), because shrinking it IS closing the process leg.

One control first, drilled and measured, then scale by contract — the same pilot discipline every migration in this training family follows.

Key takeaway

The wire joins the DevSecOps Foundations training’s evidence push to this training’s catalog machinery: bundles land content-addressed, contracts recognize them, verdicts re-run, exports regenerate — and the byte-equality gate turns determinism into the release gate, so the package versions exactly when reality changes, as a reviewable diff. Keep the judgment gates (statements authored, flips reviewed, acceptance decided); automate only assembly. Pilot one control, drill it, measure the evidence-to-package lag — that number is the process leg closing. Next: naming the frameworks all this machinery already practices.