Pengantar

Software modern tidak lagi dibangun sepenuhnya dari kode yang ditulis oleh satu tim. Sebuah aplikasi dapat menggunakan ratusan bahkan ribuan komponen dari berbagai sumber, seperti open-source library, framework, package, container image, dan dependency pihak ketiga.

Kondisi tersebut membuat keamanan software supply chain menjadi semakin penting. Satu komponen yang memiliki kerentanan dapat memberikan dampak terhadap aplikasi yang menggunakannya.

Di sinilah Software Bill of Materials (SBOM) berperan.

SBOM adalah daftar terstruktur yang berisi informasi mengenai komponen software serta hubungan antar-komponen yang digunakan untuk membangun sebuah aplikasi. NIST menjelaskan SBOM sebagai catatan formal yang mendokumentasikan detail dan hubungan supply chain dari berbagai komponen yang digunakan dalam pembuatan software (dikutip dari: NIST – Software Bill of Materials (SBOM)).

Secara sederhana, SBOM dapat dianalogikan seperti daftar bahan pada kemasan makanan. Pengguna dapat mengetahui apa saja yang digunakan untuk membuat sebuah produk software.

Apa Itu Software Bill of Materials (SBOM)?

Pengertian SBOM

Software Bill of Materials atau SBOM merupakan inventaris komponen yang terdapat dalam sebuah software.

Komponen tersebut dapat mencakup:

  • Open-source library.
  • Third-party dependency.
  • Framework.
  • Package.
  • Module.
  • Operating system component.
  • Container component.
  • Proprietary component.

Contohnya, sebuah aplikasi web mungkin menggunakan:

Aplikasi Web
│
├── Node.js
├── Express
├── JSON Library
├── Database Driver
├── Authentication Library
└── Third-Party Package

Tanpa SBOM, developer atau tim keamanan mungkin kesulitan mengetahui seluruh komponen tersebut.

Dengan SBOM, hubungan antar-komponen dapat didokumentasikan secara lebih terstruktur.

baca juga : Consistent Hashing: Cara Membagi Data Secara Efisien di Sistem Terdistribusi

Mengapa SBOM Penting?

Kompleksitas Software Supply Chain

Aplikasi modern sering menggunakan dependency dari banyak sumber.

Misalnya sebuah aplikasi hanya memiliki 100 package secara langsung. Namun, setiap package tersebut dapat memiliki dependency lain.

Hasilnya bisa menjadi:

Application
   │
   ├── Package A
   │     ├── Library X
   │     └── Library Y
   │
   ├── Package B
   │     ├── Library Z
   │     └── Library X
   │
   └── Package C
         └── Library Q

Jumlah dependency dapat bertambah dengan cepat.

Masalahnya, tim keamanan tidak hanya perlu mengetahui kode yang mereka tulis sendiri. Mereka juga perlu memahami komponen yang berasal dari pihak ketiga.

Risiko Kerentanan Dependency

Bayangkan sebuah aplikasi menggunakan library versi tertentu.

Beberapa bulan kemudian ditemukan vulnerability pada library tersebut.

Jika organisasi tidak mengetahui bahwa library tersebut digunakan, proses mitigasi dapat menjadi lambat.

Dengan SBOM, tim dapat melakukan pencarian:

CVE ditemukan
       ↓
Cari komponen terdampak
       ↓
Cari software yang menggunakannya
       ↓
Identifikasi versi
       ↓
Lakukan patch/update

Inilah salah satu manfaat utama SBOM dalam vulnerability management.

SBOM dan Transparansi Software

SBOM memberikan visibilitas terhadap isi sebuah software.

CISA juga menyediakan berbagai panduan SBOM yang membahas konsep, manfaat, implementasi, pembuatan, serta penggunaan SBOM dalam software supply chain (dikutip dari: CISA – SBOM Resources Library).

Dengan transparansi tersebut, organisasi dapat lebih mudah menjawab pertanyaan seperti:

  • Komponen apa yang digunakan?
  • Versi berapa yang digunakan?
  • Siapa pembuat komponennya?
  • Dari mana komponen berasal?
  • Apakah komponen memiliki vulnerability?
  • Software mana saja yang menggunakan komponen tersebut?

Komponen yang Biasanya Dicatat dalam SBOM

Nama Komponen

SBOM perlu mengidentifikasi nama komponen yang digunakan.

Contohnya:

openssl
curl
nginx
lodash
express

Nama yang jelas membantu proses inventarisasi.

Versi Komponen

Selain nama, versi juga sangat penting.

Contohnya:

Component: ExampleLibrary
Version: 2.4.1

Hal ini karena vulnerability sering kali hanya berdampak pada versi tertentu.

Identitas Supplier atau Author

Informasi mengenai pihak yang membuat atau menyediakan komponen juga dapat dicatat.

Hal ini membantu organisasi memahami asal-usul dependency.

Dependency Relationship

SBOM juga dapat menggambarkan hubungan antar-komponen.

Misalnya:

Application
   │
   └── Library A
         │
         └── Library B

Informasi ini membantu security team memahami bagaimana sebuah komponen masuk ke dalam software.

Format SBOM

SBOM bukan hanya berupa file teks biasa. Terdapat beberapa format yang digunakan untuk membuat data SBOM dapat diproses oleh tools.

SPDX

SPDX atau Software Package Data Exchange merupakan salah satu format standar yang digunakan untuk mendokumentasikan komponen dan metadata software.

Format ini banyak digunakan untuk kebutuhan software supply chain transparency.

baca juga : Cross-Site Request Forgery (CSRF): Cara Kerja Serangan dan Strategi Efektif untuk Melindungi Web

CycloneDX

CycloneDX merupakan format SBOM yang dirancang untuk berbagai kebutuhan seperti application security, supply chain security, dan dependency management.

Format ini juga mendukung penggunaan dalam ekosistem modern seperti aplikasi, container, dan cloud.

SWID

Software Identification Tags atau SWID merupakan standar untuk mendeskripsikan identitas software.

NIST mencantumkan SPDX, CycloneDX, dan SWID sebagai format standar yang dapat digunakan dalam konteks SBOM.

Bagaimana SBOM Dibuat?

SBOM dari Source Code

SBOM dapat dibuat dengan menganalisis dependency yang terdapat dalam source code.

Contohnya pada aplikasi Node.js:

package.json
      ↓
Dependency Analysis
      ↓
Component Identification
      ↓
SBOM Generation

Tool kemudian membaca dependency dan menghasilkan daftar komponen.

SBOM dari Build Process

SBOM juga dapat dibuat pada saat proses build.

Contohnya:

Source Code
     ↓
Build
     ↓
Dependency Resolution
     ↓
SBOM Generation
     ↓
Software Artifact

Pendekatan ini dapat membantu menghasilkan SBOM yang lebih dekat dengan software yang benar-benar dibangun.

SBOM dari Container

Pada aplikasi berbasis container, SBOM dapat digunakan untuk mengetahui komponen yang terdapat di dalam image.

Contohnya:

Container Image
│
├── Base OS
├── Runtime
├── Libraries
├── Packages
└── Application

Hal tersebut penting karena vulnerability tidak selalu berasal dari source code aplikasi.

Kerentanan dapat berasal dari package sistem operasi atau dependency lain di dalam container.

SBOM dalam Software Development Lifecycle

Tahap Development

Pada tahap development, SBOM dapat membantu developer mengetahui dependency yang digunakan.

Developer dapat memeriksa apakah package yang digunakan:

  • Sudah terlalu lama.
  • Memiliki vulnerability.
  • Tidak lagi dipelihara.
  • Memiliki dependency berisiko.

Tahap Build

Pada proses build, SBOM dapat dibuat secara otomatis.

Contohnya:

Git Commit
    ↓
CI Pipeline
    ↓
Build
    ↓
Security Scan
    ↓
SBOM Generation
    ↓
Artifact

Dengan otomatisasi, pembuatan SBOM tidak harus dilakukan secara manual.

Tahap Deployment

SBOM dapat digunakan untuk memeriksa software sebelum masuk production.

Misalnya organisasi memiliki kebijakan:

Critical Vulnerability
        ↓
   SBOM Scan
        ↓
    Ditemukan
        ↓
Build Ditolak

Pendekatan tersebut dapat menjadi bagian dari security gate pada CI/CD.

Tahap Production

SBOM tetap berguna setelah software dirilis.

Jika vulnerability baru ditemukan, security team dapat melakukan pencarian terhadap seluruh SBOM yang tersedia.

Contohnya:

New CVE
   ↓
Affected Package
   ↓
Search SBOM Database
   ↓
Affected Application
   ↓
Patch / Mitigation

Dengan demikian, organisasi tidak harus memeriksa setiap aplikasi dari awal.

SBOM dan Vulnerability Management

Mempercepat Identifikasi Dampak

Salah satu masalah terbesar ketika vulnerability baru ditemukan adalah mengetahui apakah organisasi terdampak.

Misalnya terdapat vulnerability pada:

Library-X 1.2.3

Tim keamanan dapat mencari:

Library-X 1.2.3

di seluruh inventory SBOM.

Jika ditemukan pada beberapa aplikasi, tim dapat segera memprioritaskan mitigasi.

SBOM Bukan Vulnerability Scanner

Hal penting yang perlu dipahami adalah SBOM bukan pengganti vulnerability scanner.

SBOM berfungsi untuk memberikan informasi mengenai komponen software.

Sedangkan vulnerability scanner digunakan untuk menganalisis apakah komponen tersebut memiliki vulnerability tertentu.

Hubungannya dapat digambarkan seperti:

SBOM
  ↓
Mengetahui komponen
  ↓
Vulnerability Database
  ↓
Mencocokkan vulnerability
  ↓
Risk Assessment

Dengan kata lain, SBOM menyediakan inventory, sementara sistem vulnerability management dapat menggunakan inventory tersebut untuk melakukan analisis risiko.

SBOM dan Software Supply Chain Attack

Serangan terhadap software supply chain dapat terjadi ketika attacker menyusupi komponen, dependency, build process, atau distribusi software.

Contohnya:

Developer
    ↓
Dependency
    ↓
Build System
    ↓
Software
    ↓
Customer

Jika salah satu bagian dikompromikan, dampaknya dapat menyebar ke banyak pengguna.

SBOM tidak secara otomatis mencegah serangan supply chain. Namun, SBOM dapat meningkatkan visibility terhadap komponen yang digunakan.

Dengan inventory yang jelas, organisasi memiliki informasi yang lebih baik untuk melakukan assessment ketika sebuah dependency atau supplier diketahui bermasalah.

SBOM untuk Third-Party Software

Mengurangi Blind Spot

Organisasi sering menggunakan software dari vendor eksternal.

Masalahnya, organisasi mungkin tidak mengetahui seluruh dependency yang digunakan vendor.

SBOM dapat membantu mengurangi blind spot tersebut.

Dalam proses procurement, organisasi dapat meminta vendor menyediakan SBOM untuk produk yang digunakan.

SBOM dan Open Source Software

Open-source software memberikan banyak manfaat bagi developer.

Namun, penggunaan open-source dalam jumlah besar juga dapat meningkatkan kompleksitas dependency.

SBOM membantu organisasi membuat inventory terhadap komponen tersebut.

Misalnya:

Open Source
     ↓
Library A
Library B
Library C
     ↓
SBOM
     ↓
Security Monitoring

Dengan begitu, organisasi dapat memantau dependency open-source secara lebih sistematis.

Tantangan Implementasi SBOM

Akurasi Data

SBOM yang tidak akurat dapat memberikan rasa aman palsu.

Jika dependency yang sebenarnya digunakan tidak tercatat, security team dapat mengambil keputusan berdasarkan informasi yang salah.

Karena itu, SBOM harus dibuat sedekat mungkin dengan proses build dan terus diperbarui.

Dependency Transitive

Masalah lain adalah transitive dependency.

Misalnya:

Application
   ↓
Library A
   ↓
Library B
   ↓
Library C

Developer mungkin hanya memasang Library A.

Namun, Library A membutuhkan Library B dan C.

Karena itu, SBOM sebaiknya mampu menggambarkan dependency secara lengkap.

Integrasi dengan Tool

SBOM akan lebih berguna jika dapat diintegrasikan dengan:

  • CI/CD.
  • Vulnerability scanner.
  • Dependency management.
  • Asset inventory.
  • SIEM.
  • Security dashboard.
  • Risk management platform.

Tanpa integrasi, SBOM berisiko hanya menjadi file dokumentasi yang jarang digunakan.

Best Practice Implementasi SBOM

Otomatiskan Pembuatan SBOM

Hindari proses manual jika memungkinkan.

SBOM sebaiknya dibuat secara otomatis pada pipeline build.

Gunakan Format Standar

Pilih format yang sesuai dengan kebutuhan organisasi, seperti:

SPDX
CycloneDX
SWID

Format standar membantu interoperabilitas dengan berbagai tool.

Simpan SBOM Secara Terpusat

Organisasi dapat menyimpan SBOM dalam inventory terpusat.

Contohnya:

SBOM Repository
│
├── Application A
├── Application B
├── Application C
└── Application D

Dengan begitu, pencarian terhadap dependency terdampak dapat dilakukan dengan lebih cepat.

Hubungkan SBOM dengan Vulnerability Management

SBOM sebaiknya tidak berdiri sendiri.

Hubungkan data SBOM dengan vulnerability database dan proses remediation.

Tujuannya adalah:

Discover
   ↓
Identify
   ↓
Assess
   ↓
Prioritize
   ↓
Remediate

Perbarui Setiap Release

Software berubah dari waktu ke waktu.

Dependency dapat diperbarui, ditambahkan, atau dihapus.

Karena itu, SBOM harus mengikuti perubahan software.

CISA dalam panduan minimum elements terbarunya menekankan bahwa setiap versi atau update software sebaiknya memiliki SBOM yang sesuai dengan perubahan komponennya.

Contoh Alur SBOM dalam CI/CD

Implementasi sederhana dapat terlihat seperti berikut:

Developer
    ↓
Git Repository
    ↓
CI/CD Pipeline
    ↓
Dependency Analysis
    ↓
SBOM Generation
    ↓
Vulnerability Scan
    ↓
Security Gate
    ↓
Build Artifact
    ↓
Production

Jika ditemukan vulnerability dengan tingkat risiko tinggi, pipeline dapat dikonfigurasi untuk menghentikan proses deployment sampai masalah ditangani.

Manfaat SBOM bagi Tim Keamanan

SBOM dapat memberikan beberapa manfaat penting:

Visibility
Tim keamanan mengetahui komponen yang digunakan.

Faster Response
Tim dapat lebih cepat mencari software yang terdampak vulnerability.

Risk Management
Dependency dapat dimasukkan ke dalam proses penilaian risiko.

Supply Chain Transparency
Organisasi memiliki gambaran lebih jelas mengenai asal dan hubungan komponen software.

Compliance
SBOM dapat membantu organisasi memenuhi kebutuhan transparansi software supply chain tertentu.

baca juga : Kernel Samepage Merging (KSM): Cara Linux Menghemat Memori dengan Berbagi Halaman yang Identik

Kesimpulan

Software Bill of Materials (SBOM) merupakan bagian penting dari strategi keamanan software supply chain modern. SBOM memberikan inventaris terstruktur mengenai komponen, dependency, versi, serta hubungan antar-komponen yang digunakan dalam sebuah software.

Dengan SBOM, organisasi dapat mengetahui apa yang terdapat di dalam software, bukan hanya siapa yang membuatnya.

Informasi tersebut menjadi sangat berharga ketika vulnerability baru ditemukan. Security team dapat mencari komponen yang terdampak, mengetahui aplikasi yang menggunakannya, kemudian menentukan langkah mitigasi.

Namun, SBOM bukan solusi tunggal untuk keamanan supply chain. Implementasinya perlu dikombinasikan dengan vulnerability management, secure software development, dependency management, CI/CD security, monitoring, dan risk assessment.

Semakin kompleks software yang dibangun, semakin penting pula organisasi memiliki visibility terhadap komponen di dalamnya. Karena itu, SBOM dapat menjadi salah satu fondasi penting untuk membangun software supply chain yang lebih transparan, terukur, dan aman.

Related Posts: