Belajar Application Security Engineer - Supply Chain Security (SLSA)

#Pendahuluan

Episode 9 mengamankan dependency yang kalian konsumsi; episode ini mengamankan artifact yang kalian produksi. Pertanyaan intinya sederhana namun jarang bisa dijawab organisasi: "image yang jalan di production — benarkah dibangun dari source code di repo kita, oleh pipeline kita?" Jika build system dikompromi (SolarWinds, Codecov, event-stream), penyerang menyuntikkan kode pada jalur antara source dan deploy — tempat scanner dependency tak melihat apa pun.

Kerangkanya adalah SLSA (Supply-chain Levels for Software Artifacts): spesifikasi tingkat ketahanan build dari tampering, plus standar metadata (provenance) untuk membuktikan asal-usul artifact. Kita bedah levelnya, lalu praktik signing & verification dengan Sigstore/cosign.

#Model Ancaman Rantai Pasok Build

Sebelum level-level, pahami titik serangannya pada jalur source → build → distribute → deploy:

Perhatikan pola: semuanya menyerang kepercayaan antar tahap. SLSA merespons persis itu — memastikan tiap transisi ada bukti kriptografi dan proses yang sulit dimanipulasi.

#Level SLSA: Dari L0 ke L3

SLSA v1.0 menyederhanakan fokus ke Build Track — ketahanan proses build:

Poin penting untuk komunikasi ke manajemen: mayoritas organisasi pakai GitHub Actions sudah otomatis mendekati L1–L2, karena platform menerbitkan provenance bertanda tangan via Sigstore. Lonjakan kerja nyata adalah L3 (runner hardened, isolasi ketat) — biasanya hanya relevan untuk target regulasi tinggi atau vendor software.

Yang praktis dari SLSA bukan sekadar klaim level, tapi tiga kontrol konkret: provenance (dibangun dari commit apa, oleh siapa), signed artifact, dan verification gate saat deploy.

#Signing dengan Cosign/Sigstore

Sigstore memberi signing gratis tanpa mengelola PKI sendiri: key ephemeral, identitas OIDC, transparency log (Rekor). Praktik menandai image di CI:

jobs:
  sign:
    permissions:
      id-token: write       # keyless signing butuh OIDC
      packages: write
    runs-on: ubuntu-latest
    steps:
      - uses: step-security/harden-runner@<sha> # pin SHA
      - name: Login GHCR
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      - name: Install cosign
        uses: sigstore/cosign-installer@<sha>   # pin SHA
      - name: Sign image
        run: cosign sign --yes ghcr.io/org/app:${{ github.sha }}
      - name: Attest provenance SLSA
        run: |
          cosign attest --yes --predicate provenance.json \
            --type slsaprovenance ghcr.io/org/app:${{ github.sha }}

Dua artefak yang lahir: signature (siapa yang menandai, kapan) dan attestation (klaim terstruktur: builder apa, source commit apa). Verifikasinya:

cosign verify ghcr.io/org/app:9f86d081... \
  --certificate-identity-regexp "^https://github.com/org/.+" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
 
# Cek attestation provenance
cosign verify-attestation ghcr.io/org/app:9f86d081... \
  --type slsaprovenance

Perhatikan verifikasi mengikat ke identitas workflow (certificate-identity) — artinya hanya build dari repo organisasi yang sah, bukan sekadar "ada signature".

#Verification Gate Saat Deploy

Signing tanpa enforcement = tinta di air. Nilainya muncul saat cluster/deployer menolak artifact tanpa signature valid. Di Kubernetes, policy controller (Kyverno atau Cosign-based admission):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: check-signature
      match:
        resources: { kinds: [Pod], namespaces: [production] }
      verifyImages:
        - imageReferences: ["ghcr.io/org/*"]
          attestors:
            - entries:
                - keyless:
                    subjectRegExp: "^https://github.com/org/.+"
                    issuer: https://token.actions.githubusercontent.com

Efek operasionalnya: penyerang yang berhasil mendorong image palsu ke registry tetap gagal karena cluster menolak pod tanpa signature dari identity workflow yang benar. Ini pertahanan terakhir yang bekerja meski semua lapis sebelumnya bolong — semangat defense in depth episode 0.

#Hardening Input Pipeline

SLSA juga menuntut input build tak bisa dimanipulasi — rekap dan tambahan dari episode 11:

1. Pin dependencies: action ke full SHA, package ke versi lockfile + hash integrity.
2. Immutable workflow: branch protection pada file .github/workflows/** — perubahan pipeline butuh review seperti kode produksi.
3. Isolated runners untuk repo sensitif: self-hosted runner per-repo ephemeral, bukan shared long-lived.
4. Reusable workflows dari repo terpusat yang diaudit AppSec — tim konsumen tidak menulis YAML security sendiri.

#Common Pitfalls

• Signing sebagai checkbox: sign di CI tapi tidak ada verification di deploy → nilai keamanan nol; pasangan wajibnya adalah admission policy.
• Key management salah urutan: bergegas self-managed KMS keys padahal keyless Sigstore cukup; kompleksitas kunci privat justru permukaan serangan baru.
• Provenance tidak dibaca: attestation tersimpan tapi tak pernah diverifikasi isinya (commit cocok, builder cocok); otomatisasi ceknya di CD.
• Mengabaikan non-container artifact: binary CLI internal, plugin, dan model ML juga bagian supply chain; SLSA attestation berlaku generik via in-toto.

#Penutup

Inti yang harus dibawa pulang:

• Supply chain attack menyerang kepercayaan antar tahap source→build→deploy; SLSA merespons dengan bukti kriptografi per transisi.
• Build track L0–L3: hosted CI + signed provenance ≈ L2; L3 butuh isolation hardened.
• Sigstore/cosign keyless signing mengikat artifact ke identitas workflow — sign DAN verify, keduanya wajib.
• Enforcement hidup di admission policy: production menolak unsigned/untrusted image.
• Pin input pipeline dan perlakukan workflow sebagai kode produksi.

Di episode 24 kita masuk sisi organisasional yang menentukan skala program kalian: Security Champions Program — membangun jaringan champion di tiap tim product engineering, merancang training path mereka, dan menjadikan security sebagai tanggung jawab bersama tanpa menambah headcount security. Sampai jumpa di episode 24!