Keamanan Rantai Pasok Software: SBOM dan Sigstore

Pada tahun 2020, penyerang membobol server build SolarWinds dan menyisipkan backdoor ke dalam update Orion yang sudah ditandatangani, dan pembaruan itu sampai ke sekitar 18.000 pelanggan, termasuk lembaga federal Amerika Serikat. Pada tahun 2024, seorang maintainer menghabiskan waktu bertahun-tahun membangun kepercayaan pada pustaka kompresi xz-utils sebelum diam-diam menambahkan backdoor SSH ke berkas rilisnya. Kedua serangan itu tidak mengeksploitasi bug pada kode aplikasi. Keduanya mengeksploitasi kenyataan bahwa kebanyakan tim tidak punya cara yang bisa diandalkan untuk menjawab pertanyaan sederhana: apa sebenarnya yang kita rilis, dan bisakah kita membuktikan tidak ada yang mengutak-atiknya antara baris kode terakhir sampai container yang berjalan di produksi.

Menutup celah itu butuh tiga hal yang bekerja bersamaan: software bill of materials yang mendaftar setiap komponen dalam sebuah artifact, tanda tangan kriptografis yang membuktikan artifact itu berasal dari pipeline milikmu bukan dari penyerang, dan atestasi provenance yang membuktikan bagaimana artifact itu dibangun. Tulisan ini membahas cara membuat SBOM dengan Syft, menandatangani image container tanpa kunci privat lewat Sigstore cosign, memahami level SLSA yang menggambarkan integritas proses build, dan menghubungkan ketiganya menjadi satu gate CI yang menolak artifact yang belum ditandatangani atau belum diverifikasi sebelum masuk ke produksi.

Kenapa keamanan rantai pasok jadi masalah pipeline build

Aplikasi modern itu dirakit, bukan sekadar ditulis. Layanan Node.js yang biasa saja menarik ratusan dependency transitif, satu base image container, dan sejumlah CI action yang dikunci berdasarkan tag bukan hash. Setiap input itu adalah celah bagi penyerang untuk menyisipkan kode tanpa pernah menyentuh repository milikmu. Permukaan serangan sudah bergeser dari pertanyaan apakah ada orang yang menemukan bug di kodemu, menjadi apakah ada orang yang bisa merusak salah satu dari seratus hal yang menjadi ketergantungan buildmu.

• Dependency confusion: mempublikasikan paket berbahaya dengan nama sama seperti paket privat internal, sehingga resolver malah menarik versi publiknya.
• Typosquatting: mendaftarkan paket dengan nama yang hanya beda satu huruf dari pustaka populer, berharap ada yang salah ketik saat menjalankan perintah install.
• Akun maintainer yang diretas: penyerang mendapatkan hak publish pada paket sah yang banyak dipakai, lalu menyisipkan kode berbahaya di rilis yang terlihat rutin.
• Build artifact yang tidak ditandatangani: image container atau binary tanpa tautan kriptografis ke commit, pipeline, atau identitas yang menghasilkannya, sehingga artifact yang ditukar di registry tidak bisa dibedakan dari yang asli.

Tidak satu pun dari masalah ini bisa diselesaikan dengan menulis kode aplikasi yang lebih baik. Solusinya adalah membuat pipeline build itu sendiri menghasilkan bukti: daftar apa saja yang masuk ke artifact, tanda tangan yang membuktikan siapa yang membangunnya, dan catatan bagaimana proses build itu berlangsung yang bisa diperiksa secara independen oleh pihak ketiga.

Membuat SBOM dengan Syft dan CycloneDX

Software bill of materials adalah daftar terstruktur dan dapat dibaca mesin dari setiap paket, pustaka, dan versi yang dipanggang ke dalam sebuah artifact. Dua format yang paling dominan adalah CycloneDX, standar OWASP yang dirancang terutama untuk alur kerja keamanan dan kerentanan, dan SPDX, standar Linux Foundation yang awalnya dibuat untuk kepatuhan lisensi dan kemudian menambahkan field keamanan. Kebanyakan tooling mendukung keduanya, jadi pilih format sesuai kebutuhan pemindai kerentanan atau proses kepatuhan yang kamu pakai.

Syft adalah generator SBOM open source yang paling banyak dipakai. Alat ini bisa memindai image container, filesystem, atau arsip, dan secara otomatis mendeteksi package manager untuk kebanyakan ekosistem umum, termasuk npm, pip, Go modules, dan paket OS di dalam base image. Buat SBOM dari image persis yang akan kamu push, lalu masukkan SBOM itu ke pemindai kerentanan seperti Grype supaya CVE baru terhadap versi dependency yang sudah tetap tetap muncul walau image itu sudah lama dirilis.

# Generate a CycloneDX SBOM for a container image with Syft
syft packages docker:myorg/myapp:1.4.0 \
  --output cyclonedx-json=sbom.cdx.json

# Or scan a source directory directly
syft packages dir:. \
  --output spdx-json=sbom.spdx.json

# Scan the generated SBOM for known CVEs with Grype
grype sbom:sbom.cdx.json --fail-on high

Menandatangani artifact dengan Sigstore dan cosign

Sigstore adalah kumpulan infrastruktur publik gratis untuk menandatangani dan memverifikasi software: Fulcio menerbitkan sertifikat penandatanganan berumur pendek yang terikat pada identitas OpenID Connect, bukan kunci privat berumur panjang, dan Rekor mencatat setiap tanda tangan dalam log transparansi append-only yang bisa diaudit siapa saja. Cosign adalah klien command-line yang menyatukan semua ini untuk image container dan artifact lainnya.

Manfaat praktisnya adalah keyless signing. Alih-alih membuat, merotasi, dan menjaga kunci privat yang harus disimpan oleh runner CI, cosign meminta sertifikat dari Fulcio menggunakan token OIDC milik job CI itu sendiri, menandatangani artifact dengan kunci sementara yang langsung dibuang setelah dipakai, lalu mempublikasikan tanda tangan beserta entri log transparansi Rekor. Tidak ada rahasia berumur panjang yang bisa bocor, dan tanda tangan itu terikat pada identitas yang bisa diverifikasi, misalnya file workflow GitHub Actions dan branch persis yang menghasilkannya.

# Keyless signing inside GitHub Actions (OIDC identity, no private key to manage)
- name: Sign image with cosign
  run: |
    cosign sign --yes \
      ${{ steps.build.outputs.digest }}

# Attach the SBOM as a signed attestation on the same digest
cosign attest --yes \
  --predicate sbom.cdx.json \
  --type cyclonedx \
  myorg/myapp@sha256:${DIGEST}

# Verify later, from any machine, against the recorded identity
cosign verify \
  --certificate-identity="https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  myorg/myapp@sha256:${DIGEST}

Kamu bisa melangkah lebih jauh dengan melampirkan SBOM itu sendiri sebagai atestasi yang ditandatangani pada digest image yang sama memakai cosign attest. Satu perintah itu menghasilkan satu objek yang bisa diverifikasi secara kriptografis dan menyatakan: SBOM persis ini menggambarkan image persis ini, dan ditandatangani oleh identitas pipeline persis ini.

Memverifikasi provenance dengan SLSA

SBOM menjelaskan apa isi sebuah artifact dan tanda tangan membuktikan siapa yang mempublikasikannya, tapi keduanya tidak menjelaskan bagaimana artifact itu dibangun atau apakah proses buildnya sendiri bisa saja dimanipulasi. Itulah yang dijawab oleh SLSA, Supply-chain Levels for Software Artifacts. Kerangka ini mendefinisikan build track dengan empat level, masing-masing menambahkan jaminan yang lebih kuat soal integritas platform build dan provenance yang dihasilkannya.

Kebanyakan tim yang membangun di GitHub Actions atau GitLab CI dengan runner ter-hosting dan langkah provenance yang ditandatangani sudah berada di sekitar Build L2. Mencapai L3 biasanya berarti mengadopsi layanan build khusus yang dirancang untuk isolasi, seperti fitur attestations bawaan GitHub atau platform build yang sudah diperkeras, bukan sekadar runner CI serbaguna.

Menerapkannya sebagai gate CI

Semua ini tidak melindungi apa pun kalau hasilnya cuma artifact yang tidak pernah diperiksa siapa pun. Nilainya baru terasa kalau verifikasi tanda tangan dan SBOM dijadikan gate yang keras, baik di CI sebelum merge maupun saat deploy sebelum image sampai ke cluster.

1. Buat SBOM segera setelah langkah build image, dari digest yang sudah dipush, dan gagalkan job kalau pemindai menemukan kerentanan tingkat high atau critical yang sudah ada perbaikannya.
2. Tandatangani image dan lampirkan atestasi SBOM dengan cosign sebagai langkah terakhir CI, sehingga hanya image yang lolos semua pemeriksaan sebelumnya yang pernah mendapat tanda tangan valid.
3. Tambahkan pemeriksaan policy-controller atau admission-webhook di cluster deployment yang menolak image apa pun tanpa tanda tangan cosign valid yang cocok dengan identitas OIDC yang sudah masuk allow-list, misalnya path dan branch spesifik dari workflow rilismu.
4. Kirim peringatan, bukan diam saja meloloskan, saat sebuah image dideploy dengan tanda tangan dari identitas yang tidak diharapkan, misalnya push manual dari laptop bukan dari pipeline CI, meskipun tanda tangannya sendiri secara teknis valid.

Langkah terakhir ini lebih penting dari yang terlihat. Tanda tangan cosign yang valid hanya membuktikan bahwa image ditandatangani oleh identitas apa pun yang meminta sertifikat itu. Kalau gate-mu menerima tanda tangan valid apa saja bukan hanya dari identitas yang secara eksplisit masuk allow-list, penyerang yang berhasil membobol lingkungan satu developer yang punya akses OIDC tetap bisa menandatangani dan merilis image berbahaya.

Menyatukan semuanya

SBOM, penandatanganan, dan provenance bukan tiga inisiatif terpisah, ketiganya adalah satu pipeline: buat SBOM dari artifact yang sudah dibangun, pindai kerentanan yang sudah dikenal, tandatangani artifact dan SBOM-nya bersamaan lewat alur keyless cosign, lalu jadikan setiap deployment tergantung pada verifikasi tanda tangan itu terhadap identitas yang secara eksplisit kamu percayai. Tidak ada satu pun komponen ini yang lagi jadi teknologi eksotis. Yang kebanyakan tim belum punya hanyalah menghubungkan semuanya jadi gate, bukan membiarkannya sebagai laporan opsional yang tidak pernah dibaca siapa pun.