Secure supply chain and continuous delivery
Know which software, models and data are in your release.
In this lesson · P11 of 12
All 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.
The video explains the main idea. Use the sources, instructions and checks below to complete the practice.
Captions appear here during playback.
Secure supply chain and continuous delivery
Know which software, models and data are in your release.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the 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
- Inventory code, model, data, dependency, and image artifacts.
- Verify hashes, provenance, licenses, and scan results.
- 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.