Belajar Platform Engineer - Supply Chain Security

#Pendahuluan

Di episode 18 service-to-service sudah saling mempercayai via identitas. Tapi ada satu pertanyaan yang belum terjawab: dari mana image itu berasal? Serangan supply chain (SolarWinds, xz backdoor 2024) membuktikan bahwa code yang tampak sah bisa disusupi di tengah rantai — dependency yang diretas, image yang di-tag ulang, atau build server yang dibobol. Episode ini membangun supply chain security: SBOM, image signing, SLSA, dan vulnerability scanning.

Mengapa ini penting? Keamanan di runtime (episode 16-18) tidak ada artinya jika artefak yang di-deploy sudah rusak sejak di build. Supply chain security menutup mata rantai: dari commit di git, dependency yang ditarik, build, hingga image yang jalan di production. Platform engineering menjadikannya bagian bawaan pipeline, bukan checklist audit.

#SBOM: Daftar Bahan Baku Image

SBOM (Software Bill of Materials) adalah daftar lengkap komponen yang menyusun image — seperti daftar bahan di kemasan makanan. Format standar: SPDX dan CycloneDX.

Hasilkan SBOM saat build

syft registry:registry.example.com/payments-api:latest \
  -o cyclonedx-json > sbom.json

Mengapa SBOM penting? Saat CVE baru diumumkan (misal di library log parsing), kalian langsung tahu image mana yang terpengaruh — tanpa menebak-nebak dari ratusan repositori. SBOM harus dihasilkan saat build dan disimpan bersama image, bukan dibuat sekali sebagai dokumen statis.

#Image Signing: Bukti Keaslian

SBOM memberi tahu isi image; signing membuktikan siapa yang membuatnya. Sigstore adalah standar modern: keyless signing — tidak perlu mengelola private key, identitas didapat dari OIDC (GitHub Actions, GitLab CI).

Sign image di CI tanpa private key

cosign sign registry.example.com/payments-api:latest \
  --identity-token "$ACTIONS_ID_TOKEN_REQUEST_TOKEN"

Image yang ditandatangani mengaktifkan admission verification: cluster hanya menerima image yang signature-nya valid dari pipeline resmi. Image yang di-push manual atau dari registry asing langsung ditolak:

policies/verify-image.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-signed-image
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - image: "registry.example.com/*"
          attestors:
            - count: 1
              entries:
                - keyless:
                    subject: "https://github.com/org/platform/.github/workflows/build.yml@*"
                    issuer: "https://token.actions.githubusercontent.com"

#SLSA: Tingkat Kepatuhan Rantai

SLSA (Supply-chain Levels for Software Artifacts) adalah framework yang memberi peringkat seberapa kuat rantai build. Empat level, masing-masing menambah jaminan:

Level	Jaminan	Bukti nyata
L1	Dokumentasi proses	Proses build didokumentasikan
L2	Build terautentikasi	Build di CI yang terautentikasi
L3	Build tidak bisa dirusak	Build di isolasi, provenance ter-signed
L4	Build di-verify dua pihak	Dua build independent harus menghasilkan artefak sama

Target realistis yang banyak diadopsi 2026: SLSA L3 untuk image production. Provenance (bukti dari mana image berasal) dihasilkan di build dan diverifikasi saat admission:

Generate provenance (SLSA)

cosign attest --predicate build.yaml \
  --type slsaprovenance \
  registry.example.com/payments-api:latest

#Vulnerability Scanning di Seluruh Siklus

Tahap	Scan	Tujuan
Dependency (CI)	osv-scanner, Dependabot	Library rentan di-block sebelum build
Image (build)	Trivy/Grype	CVE di base image & package
Continuous	Trivy di registry	Image yang sudah jalan tetap dipantau
Runtime	Falco/KubeSec	Perilaku anomali saat jalan

Aturan penting: scan tidak cukup, harus ada policy gate. Image yang punya CVE kritis ditolak saat admission; temuan menengah diizinkan tapi wajib punya pelacak perbaikan. Gate yang memblokir adalah pembeda antara "kita sudah scan" dan "kita aman".

#Common Pitfalls

SBOM dibuat sekali lalu dilupakan — SBOM harus dibuat per-build dan disimpan bersama artefak, karena isi image berubah tiap build.
Signing tanpa verification — image ditandatangani tapi cluster tidak pernah memverifikasi; nilainya nol.
Menargetkan SLSA L4 dari hari pertama — butuh waktu; mulai dari L2, lalu naik sambil memperkuat isolasi build.
Scanning di CI tapi tidak di runtime — CVE baru muncul setelah image jalan; scan terus-menerus.
Mengabaikan supply chain non-image — kode internal, container base, IaC modules juga butuh SBOM dan review dependency.

Tip

Mulai dari membangun sekali di CI yang terautentikasi, sign setiap image, dan verifikasi saat admission. Tiga hal ini memberi sebagian besar manfaat supply chain security dengan usaha paling sedikit. SLSA L3 dan SBOM lengkap bisa naik setelah pola dasarnya berjalan.

#Penutup

Inti yang harus dibawa pulang:

SBOM = daftar isi image, dibuat per-build untuk respons CVE yang cepat.
Signing (Sigstore keyless) = bukti siapa yang membangun image, tanpa repot mengelola kunci.
SLSA = framework tingkat kepatuhan; L3 adalah target realistis untuk image production.
Scanning harus punya policy gate — di CI, registry, dan runtime.
Supply chain security adalah bagian bawaan pipeline, bukan checklist audit tahunan.

Di episode 20 selanjutnya kita memisahkan satu workload dari workload lain di dalam jaringan: network policy & isolation — default-deny NetworkPolicy, isolasi multi-tenancy, dan segmentasi yang mempersempit jalur serangan!