Belajar DevSecOps Engineer - SBOM & Software Supply Chain

#Pendahuluan

Setelah episode 11 menutup Fase 2, kita masuk Fase 3: software supply chain. Mulai episode ini hingga episode 13, kita menjawab satu ancaman besar: kode yang kalian deploy bukan hanya kode kalian — ia adalah gabungan ribuan dependency pihak ketiga yang tidak kalian audit satu per satu.

Kasus xz-utils (2024) adalah peringatan kerasnya: backdoor disusupi ke library kompresi yang dipakai SSH di banyak distro — berkat proses maintainance yang panjang dan sabar oleh penyerang. Ketika insiden seperti ini (atau sekadar CVE baru) meledak, organisasi siap menjawab dalam hitungan menit; organisasi tanpa persiapan butuh berhari-hari hanya untuk mencari tahu "apakah kita kena?".

Alat jawabannya adalah SBOM — Software Bill of Materials.

#Apa Itu SBOM dan Mengapa Wajib

SBOM adalah daftar isi resmi sebuah artefak software: semua package, versi, lisensi, dan hubungan dependensinya. Analoginya seperti label nutrisi di kemasan makanan — saat ada bahan tercemar (CVE baru), kalian tinggal cek label, bukan membongkar dapur.

Nilai praktisnya:

Regulasi juga mengarah ke sini: EO 14028 di AS dan EU CRA mendorong/mewajibkan SBOM untuk vendor tertentu — tren yang pada 2026 sudah menjadi ekspektasi standar enterprise.

#Format: SPDX vs CycloneDX

Dua format standar industri:

Praktik pragmatis: pilih satu format sebagai standar organisasi (CycloneDX populer untuk tim yang security-first), tapi pastikan toolchain bisa ekspor keduanya — biaya konversinya nyaris nol.

#Generate SBOM di Pipeline

Dengan tool yang sudah kalian punya:

trivy image --format cyclonedx --output sbom-image.cdx.json myapp:1.0.0
trivy fs --format cyclonedx --output sbom-fs.cdx.json .

syft myapp:1.0.0 -o cyclonedx-json > sbom.syft.cdx.json
syft myapp:1.0.0 -o spdx-json > sbom.spdx.json

Integrasikan ke build workflow — generate setiap rilis dan simpan sebagai artifact:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write        # untuk attestasi, dibahas episode 13
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Generate SBOM
        run: |
          trivy image --format cyclonedx \
            --output sbom-${{ github.sha }}.cdx.json \
            myapp:${{ github.sha }}
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.cdx.json

Poin penting: SBOM dibuat dari hasil build final, dengan tag SHA yang unik — bukan dari working directory yang bisa berbeda isinya.

#Validasi dan Konsumsi SBOM

SBOM tanpa validasi bisa kosong atau cacat diam-diam. Validasi minimum di CI:

cyclonedx validate --input-file sbom.cdx.json
# pastikan jumlah component masuk akal
jq '.components | length' sbom.cdx.json   # harusnya ratusan+, bukan 0

Lalu gunakan SBOM untuk pertanyaan dunia nyata — "apakah kita memakai lib X versi rentan?":

grype sbom:sbom.cdx.json                    # scan langsung dari SBOM
jq -r '.components[].name' sbom.cdx.json \
  | grep -x "xz"                            # cari paket spesifik

grype sbom: adalah pola kuat: analisis kerentanan bisa jalan dari SBOM historis tanpa image asli masih ada di registry.

#Dependency Risk: Pelajaran xz-utils

SBOM menyelesaikan visibility, tetapi risiko supply chain lebih dalam. Pelajaran dari xz-utils:

1. Social engineering pada maintainer — attacker menjadi co-maintainer selama dua tahun sebelum menyusupkan backdoor.
2. Build-time injection — kode berbahaya hanya aktif pada build tertentu (dengan ifunc, tersembunyi dari source biasa).
3. Target sempit tapi strategis — libssh via systemd chain.

Mitigasi praktis level organisasi:

• Kurangi permukaan: dependency minimal, hapus yang tak dipakai (depcheck, cargo udeps).
• Proksi registry internal (Artifactory/Nexus/Artifact Registry): cache + kontrol apa yang boleh masuk + proteksi jika upstream dicompromise.
• Pin + lockfile ketat, review bump major dengan hati-hati (commit author baru yang agresif = sinyal merah).
• VEX (Vulnerability Exploitability eXchange): dokumen machine-readable yang menyatakan "CVE ini tidak mempengaruhi kita karena fitur X tidak dipakai" — melengkapi SBOM agar triage tidak berulang tiap audit.

#Penutup

Inti yang harus dibawa pulang:

• SBOM = daftar isi resmi artefak; mengubah pencarian dampak CVE dari hari-harian menjadi hitungan detik.
• SPDX untuk compliance/lisensi, CycloneDX untuk security; pilih satu standar, dukung keduanya.
• Generate SBOM dari build final per-release, validasi strukturnya, simpan sebagai artifact.
• Visibility saja belum cukup: proksi registry internal, pinning, dan VEX menurunkan risiko nyata.

Di episode 13 selanjutnya kita lanjut supply chain dengan SLSA & Artifact Signing — framework SLSA untuk menilai integritas build pipeline kalian, signing cosign keyless, provenance/attestation GitHub, dan verifikasi signature sampai ke admission cluster. Sampai jumpa!