Belajar MLOps - Supply Chain & Model Trust

#Pendahuluan

Setelah episode 19 mengamankan secrets dan data, ada satu pertanyaan yang jarang ditanyakan tapi sangat menentukan: bagaimana kalian tahu bahwa model yang berjalan di produksi benar-benar model yang kalian build? Bukan versi yang di-modify, bukan image yang disusupi, bukan dependensi yang sudah dibajak.

Mengapa supply chain penting? Karena serangan rantai pasok — seperti insiden xz-utils dan SolarWinds — menunjukkan bahwa attacker tidak perlu menembus kalian; cukup menyusup di salah satu komponen yang kalian percaya: base image, library, atau model artifact. Untuk ML, rantainya lebih panjang: kode, dependensi Python, base image, dataset, dan model artifact itu sendiri. Episode ini membangun kepercayaan di seluruh rantai itu.

#Kenapa Supply Chain ML Lebih Panjang

Rantai pasok ML tidak berhenti di binary. Satu model produksi bergantung pada:

Base image — OS dan runtime tempat model berjalan.
Dependensi Python — numpy, torch, scikit-learn, dan ribuan transitive.
Kode training — commit yang menghasilkan model.
Dataset — hash dan provenance (episode 6).
Model artifact — file yang di-deploy ke serving.

Setiap tautan adalah permukaan serangan. Kepercayaan harus dibangun di seluruh tautan, bukan hanya di kode.

#SLSA: Kerangka Provenance

SLSA (Supply-chain Levels for Software Artifacts) memberi level kematangan 0-4:

Level	Arti	Contoh praktik
0	Tanpa proteksi	Build manual, tanpa dokumentasi
1	Provenance ada	Build script menghasilkan bukti asal-usul
2	Provenance terverifikasi	Build di-hosting; bukti ditandatangani
3	Hardened build	Isolasi build, tidak ada akses manual
4	Full reproducibility	Build bisa diverifikasi dari source

Untuk ML, target realistis tim baru adalah SLSA level 2: build di CI, provenance otomatis, dan ditandatangani.

#Model Signing & Verifikasi

Signing menjawab pertanyaan: "apakah artifact ini benar-benar dari tim kami, dan tidak berubah sejak ditandatangani?" Alat yang umum adalah cosign dari Sigstore.

Tanda tangani model artifact

cosign sign --key cosign.key \
  registry.example/ml/churn-model@sha256:abc123
 
cosign verify --key cosign.pub \
  registry.example/ml/churn-model@sha256:abc123

Tanda tangan digital melekat pada hash artifact: siapa pun yang mengubah model, tanda tangan menjadi tidak valid. Signing berlaku untuk image container, model artifact di registry, dan bahkan dataset.

#SBOM untuk ML

SBOM (Software Bill of Materials) adalah daftar inventaris semua komponen yang membentuk artifact. Untuk ML, SBOM mencakup: versi library, base image, tooling, dan — jika memungkinkan — dataset yang dipakai training.

Generate SBOM dengan syft

syft registry.example/ml/train:2.4.0 \
  -o cyclonedx-json > sbom.json

SBOM yang baik memungkinkan tim menjawab cepat ketika CVE ditemukan: "apakah kita terkena?" — tanpa harus menelusuri dokumentasi yang tidak ada. Format standar: CycloneDX dan SPDX.

#Provenance & Attestation

Provenance mencatat siapa membuat apa, dari apa. in-toto memperluas ini menjadi attestation yang bisa diverifikasi dalam pipeline: setiap langkah (build → test → sign → deploy) menyatakan dengan jelas masukan dan keluarannya.

text

attestation (in-toto):
  predicate_type: SLSA-Provenance-v1
  subject: registry.example/ml/churn-model@sha256:abc123
  build_definition: github.com/ml-team/churn/.github/workflows/train.yml
  builder: GitHub Actions
  materials:
    - src: git+https://github.com/ml-team/churn@8f3d2a1
    - data: dvc://s3/mlops-bucket/datasets/v2026-08-01-abc

Attestation menjadikan seluruh riwayat build bisa dipertanggungjawabkan — dan bisa diverifikasi otomatis sebelum deploy.

#Praktik: Supply-Chain Checks di CI

Kunci implementasi: verifikasi sebagai gate, bukan sebagai laporan. Di GitHub Actions, tambahkan job supply chain yang memblokir pipeline bila gagal:

Supply chain gate di CI

jobs:
  supply-chain:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Verify model signature
        run: cosign verify --key cosign.pub model@sha256:abc123
      - name: Generate SBOM
        run: syft dir:./model -o cyclonedx-json > sbom.json
      - name: Scan vulnerabilities
        run: trivy fs --severity HIGH,CRITICAL .

Alur lengkap yang disarankan:

text

Build → Sign artifact → Attest provenance → Verify di pipeline → Scan SBOM → Deploy

Setiap langkah "verify" yang gagal menghentikan pipeline sebelum model mencapai produksi.

Note

Model trust adalah sistem, bukan satu alat: signature tanpa provenance tidak lengkap, SBOM tanpa kebijakan verifikasi tidak berfungsi. Bangun rantai yang utuh — build, sign, attest, verify, deploy — dan jadikan verification sebagai gate pipeline (episode 8), bukan dokumen yang hanya disimpan.

#Common Pitfalls

Hanya menandatangani image, model artifact tidak — model yang di-deploy bisa berbeda dari yang ditest.
SBOM di-generate tapi tidak dipakai — inventaris tanpa mekanisme verifikasi = pajangan.
Pin dependensi tua dengan CVE — reproduktibel (episode 4) tapi tidak aman; kombinasikan pinning dengan scan.
Verifikasi manual — manusia lupa; jadikan gate otomatis di CI.
Tanpa attestation dataset — provenance model tidak lengkap jika data training tidak tercatat.

#Penutup

Pada episode 20 ini, kalian telah membangun kepercayaan rantai pasok ML.

Inti yang harus dibawa pulang:

Rantai pasok ML lebih panjang: kode, dependensi, base image, dataset, model artifact.
SLSA memberi level provenance dari 0-4; target awal level 2.
cosign untuk signing & verifikasi; SBOM untuk inventaris; in-toto untuk attestation.
Verifikasi sebagai gate otomatis di CI, bukan laporan.
Model trust adalah sistem yang utuh, bukan satu alat.

Di episode 21 selanjutnya kita akan membahas LLMOps & GenAI platforms — fine-tuning dengan LoRA, infrastruktur RAG, vector database, dan manajemen prompt untuk model bahasa besar. Sampai jumpa di episode 21!