Belajar Software Architect - Supply Chain & Compliance

#Pendahuluan

Setelah di episode 18 kalian membangun zero trust software — service identity, mTLS bertahap, dan least privilege lima lapis — pada episode ini kita mundur satu langkah ke hulu: sebelum aplikasi kalian jalan, ia tersusun dari ratusan artefak yang bukan karya tim kalian. Di situlah supply chain dimulai.

Serangan modern jarang memukul pintu depan. Mereka menyusup lewat dependensi yang dikompromikan, pipeline CI yang bocor, atau image base yang berisi malware — semua masuk melalui jalur resmi yang dipercaya penuh. Dan di sisi lain rantai, perusahaan e-commerce kita tidak bisa menghindari compliance: PCI DSS menyertai setiap kartu, GDPR/PDP Law menyertai setiap data pengguna Indonesia. Keduanya — supply chain security dan compliance — punya sifat sama: harus dirancang sejak awal, karena retrofit saat audit adalah proyek termahal yang pernah ada.

#Mengapa Supply Chain Jadi Medan Tempur

Beberapa insiden membentuk kesadaran industri:

Pola umumnya: kerusakan datang dari trust yang tidak diverifikasi. Jawaban arsitekturnya pun konsisten: buat setiap mata rantai dapat diaudit dan diverifikasi secara kriptografis.

#SBOM: Daftar Bahan Aplikasi

SBOM (Software Bill of Materials) adalah inventaris formal seluruh komponen dalam artefak kalian — seperti daftar bahan di kemasan makanan. Dua format standar: SPDX (Linux Foundation) dan CycloneDX (OWASP).

Nilainya baru terasa penuh saat insiden datang: ketika CVE baru meledak di openssl, pertanyaan "di mana saja kami terdampak?" terjawab dalam hitungan detik dengan query SBOM — bukan minggu audit manual lintas repo.

syft packages dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high   # gate: CVE high+ gagalkan build
cosign attest --predicate sbom.json \
    --type cyclonedx registry.acme.io/ordering@sha256:abc123

Tiga baris itu memberi kalian: inventaris otomatis tiap build, gate kerentanan sebelum deploy, dan SBOM yang di-attest menempel pada image — bisa diverifikasi siapa pun nanti.

#Signing & Verifikasi Artefak

SBOM menjawab "apa isinya"; signing menjawab "benarkah ini yang dibangun pipeline kami". Standar de facto-nya Sigstore: sign dengan identity OIDC (bukan key lama yang harus dijaga), disimpan di transparency log publik (rekor tak bisa dihapus), verifikasi murah:

CI build image        → cosign sign + SBOM attest
Admission controller  → hanya image signed oleh
                        workflow identitas resmi
                        yang boleh jalan di cluster
Runtime               → digest pin, tag latest ditolak

Hasil akhirnya: penyerang yang membobol registry tetap tidak bisa menjalankan image palsu — admission policy memverifikasi tanda tangan dan identitas pembuatnya sebelum container lahir. Ini zero trust (episode 18) diterapkan pada artefak.

#SLSA: Tangga Kematuran

SLSA (Supply-chain Levels for Software Artifacts) memberi tangga kemajuan yang bisa diukur:

Jangan berambisi L3 hari pertama. Untuk studi kasus kita, target realistis: L2 dalam enam bulan — GitHub Actions hosted + cosign signing + SBOM attestation sudah mencakup intinya.

#Compliance-Driven Design

Compliance sering diperlakukan sebagai beban administratif. Cara pandang architect yang benar: regulasi adalah kumpulan quality requirements yang bisa diterjemahkan menjadi desain.

#PCI DSS → Keputusan Arsitektur Payment

Studi kasus kita menerima kartu kredit; scope PCI DSS mengikuti data kartu. Keputusan struktural paling bernilai sudah kita ambil di episode 12: ekstraksi payment service + tokenisasi. PAN (nomor kartu) tidak pernah menyentuh database utama — gateway menyimpannya, kita simpan token. Konsekuensinya: scope audit menyempit dari "seluruh sistem" menjadi "payment service saja", menghemat biaya compliance berulang setiap tahun.

#GDPR / PDP Law → Data Minimization by Design

Undang-undang perlindungan data menuntut: dasar pemrosesan jelas, retensi terbatas, hak akses/hapus. Desainnya:

klasifikasi:
  pii_kritis: [email, phone, address]
    penyimpanan: encrypted field-level
    akses: via API PII service, audit per bacaan
  pii_operasional: [order_history, ip_login]
    retensi: 24 bulan -> anonimisasi otomatis
hak_hapus:
  mekanisme: crypto-shredding
  detail: PII dienkripsi per-user key;
          hapus request -> destroy key -> ciphertext
          jadi sampah tanpa bisa dibuka
audit:
  siapa_baca_pii: append-only log, review bulanan
cross_border: region penyimpanan eksplisit di ADR

Perhatikan solusi right-to-erasure: event sourcing episode 13 bertabrakan dengan hak hapus jika PII ikut masuk log event. Crypto-shredding menyelesaikannya — PII hidup terpisah, terenkripsi per user; menghapus kunci membuat jejak historisnya mati secara permanen tanpa merusak integritas event lainnya.

#Praktik: Checklist Pipeline Terpercaya Studi Kasus

Mari rangkum standar supply chain yang kita adopsi:

dependensi:
  lockfile: wajib, review diff dependency PR
  scan: grype fail-on=high di setiap build
  renovate: auto-update grup minor, window mingguan
build:
  runner: github-hosted (SLSA L2 path)
  reproducibility: docker build multi-stage pin digest base
artefak:
  sign: cosign keyless (OIDC workflow identity)
  sbom: cyclonedx attach per image
deploy:
  admission: verify signature + sbom attestation
  runtime: digest-only, latest ditolak
secrets_ci:
  model: oidc federation, tanpa long-lived key
review_gate:
  dependensi_baru: approval architect + cek lisensi

Checklist ini bukan dokumen aspirasi — setiap barisnya adalah konfigurasi CI/admission yang bisa diverifikasi, sejalan dengan filosofi fitness function episode 7: aturan yang tidak otomatis akan dilanggar tepat saat deadline.

#Kesalahan Umum

• Scan sekali di awal proyek — kerentanan baru lahir tiap minggu; scanning harus di setiap build dan berkala pada runtime inventory.
• Semua dependensi sama perlakuannya — library kripto dan CLI dev tool butuh tingkat scrutiny berbeda; klasifikasikan berdasarkan blast radius.
• Compliance sebagai proyek retrofit — menyiapkan audit 2 minggu sebelum deadline; hasilnya dokumentasi kosmetik yang runtuh saat penilaian sungguhan.
• Scope PCI melebar — menyimpan PAN di DB utama membuat seluruh sistem masuk audit; tokenisasi + isolasi service menjaga scope sempit.
• Signing tanpa verifikasi — menandatangani image tapi admission policy tidak memeriksa tanda tangan = upacara tanpa jaminan.
• Lupa pipeline sebagai attack surface — secret CI yang long-lived dan action third-party tanpa pinning commit adalah pintu belakang favorit.

#Penutup

Inti yang harus dibawa pulang:

• Supply chain attacks masuk lewat trust yang tak diverifikasi — jawabannya auditability + cryptographic verification di setiap mata rantai.
• SBOM (SPDX/CycloneDX) menjawab "apa isi aplikasi kami" dalam hitungan detik saat CVE datang; pasangkan dengan vulnerability gate di CI.
• Sigstore keyless signing + admission verification memastikan hanya artefak dari pipeline resmi yang bisa berjalan; SLSA memberi tangga kematuran — L2 target enam bulan yang realistis.
• Compliance = quality requirements: PCI DSS didorong keluar lewat tokenisasi + payment isolation; GDPR/PDP dilayani lewat minimization, tiered retention, dan crypto-shredding.
• Studi kasus kini punya dua artefak governance: data-governance map dan supply-chain checklist — keduanya executable configuration, bukan dokumen mati.

Di episode 20 selanjutnya kita bahas pola yang menentukan bentuk banyak produk SaaS modern: multi-tenancy & isolation — model silo/bridge/pool, noisy neighbor, strategi pemisahan data per tenant, dan bagaimana propagasi tenant context menembus seluruh stack. Sampai jumpa!