Secure supply chain and continuous delivery

Know which software, models and data are in your release.

Visual lessons: 1 · 1:38 total Read estimate: 5 min Practice estimate: 12 hr Updated: 2026-10-03
In this lesson · P11 of 12All lessons in this track →

Progress for this track is saved in this browser only. No completion badge is issued. View your learning.

Start with the idea

Know which software, models and data are in your release.

Inventory the parts loaded at runtime and their origins. Check exact versions and bytes. Matching a hash proves identity, not that the item is trustworthy or suitable.

Hash: A fingerprint of file contents used to check whether the bytes match.

See the example and check your understanding

A made-up teaching example

The supplied release record contains a changed model hash and a flagged training dependency. The pipeline blocks release, records why, and checks the corrected bundle.

Ask yourself

Does a matching file hash prove the file’s source is safe?

Show the explanation

No. Verify origin and relevant security evidence separately. Keep unknown-origin items out of use pending review.

Start with these checks

  • Inventory every runtime-loaded part.
  • Check both byte identity and origin.
  • Keep release evidence reproducible.

Use the different practice case below and check every requirement in its full instructions.

Go to the practice task ↓

The video explains the main idea. Use the sources, instructions and checks below to complete the practice.

Visual lesson1:38

Captions appear here during playback.

Secure supply chain and continuous delivery

Know which software, models and data are in your release.

Download transcriptOpen video file

Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.

Read the descriptive transcript

0:00 · What you will learn

Know which software, models and data are in your release.

What appears on screen

Know which software, models and data are in your release.

0:06 · The idea

Inventory the parts loaded at runtime and their origins. Check exact versions and bytes. Matching a hash proves identity, not that the item is trustworthy or suitable.

What appears on screen

Inventory the parts loaded at runtime and their origins. Check exact versions and bytes. Matching a hash proves identity, not that the item is trustworthy or suitable.

0:21 · One useful term

Hash. A fingerprint of file contents used to check whether the bytes match.

What appears on screen

A fingerprint of file contents used to check whether the bytes match.

0:29 · A worked example

The supplied release record contains a changed model hash and a flagged training dependency. The pipeline blocks release, records why, and checks the corrected bundle.

What appears on screen

The supplied release record contains a changed model hash and a flagged training dependency. The pipeline blocks release, records why, and checks the corrected bundle.

0:42 · Your turn to think

Does a matching file hash prove the file’s source is safe? Pause and decide before continuing.

What appears on screen

Does a matching file hash prove the file’s source is safe? Pause the video if you need more time.

0:59 · Why this answer works

No. Verify origin and relevant security evidence separately. Keep unknown-origin items out of use pending review.

What appears on screen

No. Verify origin and relevant security evidence separately. Keep unknown-origin items out of use pending review.

1:10 · Check 1

Inventory every runtime-loaded part.

What appears on screen

Inventory every runtime-loaded part.

1:16 · Check 2

Check both byte identity and origin.

What appears on screen

Check both byte identity and origin.

1:21 · Check 3

Keep release evidence reproducible.

What appears on screen

Keep release evidence reproducible.

1:26 · Now try a different case

Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.

What appears on screen

Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.

Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →

What you will be able to do

  1. Inventory code, model, data, dependency, and image artifacts.
  2. Verify hashes, provenance, licenses, and scan results.
  3. Gate changes on evaluation and rollback evidence.

Prerequisites: Builder-level interface validation, Python, testing, metadata logging and state-transition tracing. Hardware benchmarks and model accounts are not required.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

An AI release contains more than source code. Inventory dependencies, container/base image, model identifier and checksum, prompt/config versions, dataset/eval manifests, licenses, and build provenance. A hash proves byte identity, not trust or authorization. CI classifies the change and runs required gates: unit/security tests, dependency policy, model/data hash approval, evaluation slices, configuration validation, and rollback availability. A signed bundle is useful only when the signer, key custody, verification process, and source inputs are governed.

Mechanism and implementation

A release includes source, dependencies, images, prompts, model/adapter revisions, index manifests and evaluators. Verify provenance/licensing separately from checksums. Mutable aliases can change outside your commit; monitor and reevaluate them. Classify changes to choose appropriate gates.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

import hashlib
artifact = b"synthetic-model-v1"
expected = hashlib.sha256(artifact).hexdigest()
def gate(payload, origin_approved, license_reviewed):
    return hashlib.sha256(payload).hexdigest() == expected and origin_approved and license_reviewed
assert gate(artifact, True, True)
assert not gate(artifact, False, True)
assert not gate(b"changed", True, True)
print("identity plus provenance gates passed")

Engineering decisions

  • Define the release artifact set.
  • Map change classes to required gates.
  • Block unknown provenance or changed critical hashes pending review.

Worked example

The supplied manifest contains one changed model hash and a vulnerable synthetic dependency flag. The pipeline blocks release, records causes, then passes a corrected, independently reproducible bundle.

Diagnose the failure

Hashes establish byte identity only. Unknown origins remain quarantined. Inventory every runtime-loaded artifact before relying on signed bundles.

Part 2 Guided practice

Predict why unchanged unapproved bytes fail. Make a release manifest including prompt/tool/eval revisions. Independently change only the prompt and map it to required behavior/security tests.

Answer criteria and feedback: Hashes establish byte identity only. Unknown origins remain quarantined. Inventory every runtime-loaded artifact before relying on signed bundles.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Verify one artifact hash manually. If provenance is unknown, quarantine the artifact rather than adding it to the allowlist. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.

Lesson status:PRACTICE REVIEW REQUIRED

Review your practice