TDCTF Academy Logo TDCTF ACADEMY
@farishhz

SBOM (Software Bill of Materials)

Pendahuluan

SBOM atau Software Bill of Materials adalah daftar inventaris yang mencatat semua komponen - termasuk library open-source, framework, dan dependensi - yang digunakan dalam suatu perangkat lunak. Analoginya seperti daftar bahan makanan pada kemasan produk: konsumen bisa tahu apa saja yang terkandung di dalamnya.

Konsep SBOM menjadi sangat penting setelah serangan rantai pasok (supply chain attack) besar-besaran seperti SolarWinds (2020) dan Log4Shell (2021). Dalam insiden SolarWinds, attacker menyusupkan backdoor ke dalam update Orion, software monitoring yang digunakan oleh ribuan organisasi termasuk lembaga pemerintah AS. Jika para korban memiliki SBOM yang akurat, mereka bisa dengan cepat mengidentifikasi apakah mereka terpengaruh dan segera mengambil tindakan.

Setelah insiden SolarWinds, Executive Order 14028 yang dikeluarkan Presiden AS pada Mei 2021 secara eksplisit mewajibkan SBOM untuk semua perangkat lunak yang dijual ke pemerintah federal. Standar ini kemudian diadopsi secara global dan menjadi praktik terbaik dalam DevSecOps.

Mengapa SBOM Diperlukan?

SBOM memberikan visibilitas penuh terhadap rantai pasok perangkat lunak. Tanpa SBOM, sebuah organisasi tidak tahu:

  • Library apa saja yang digunakan aplikasi mereka.
  • Versi spesifik dari setiap library.
  • Lisensi dari setiap komponen.
  • Kerentanan mana yang berdampak pada aplikasi mereka.
  • Kapan dan bagaimana komponen tertentu diperbarui.

Manfaat utama SBOM meliputi:

  1. Vulnerability Management: Dengan SBOM, tim keamanan bisa langsung mencocokkan CVE baru dengan komponen yang terdaftar. Saat Log4Shell diumumkan, organisasi yang memiliki SBOM bisa mengidentifikasi aplikasi terpengaruh dalam hitungan jam, bukan minggu.
  2. License Compliance: SBOM mencatat lisensi setiap komponen, membantu tim legal memastikan kepatuhan terhadap lisensi seperti GPL, MIT, Apache, atau lisensi komersial.
  3. Supply Chain Risk Assessment: Sebelum mengadopsi library baru, organisasi bisa menilai risikonya berdasarkan asal, pemelihara, dan riwayat keamanannya.
  4. Incident Response: Saat terjadi insiden, SBOM mempercepat forensik dan analisis dampak.
  5. Regulatory Compliance: Memenuhi persyaratan regulasi seperti EO 14028, FDA Premarket Cybersecurity untuk perangkat medis, dan standar industri.

Format SBOM

Tiga format utama SBOM yang diakui secara internasional:

1. SPDX (Software Package Data Exchange)

Dikembangkan oleh Linux Foundation, SPDX adalah format yang paling matang dan paling banyak diadopsi. Versi terbaru adalah SPDX 2.3 (dengan SPDX 3.0 dalam pengembangan).

Karakteristik SPDX:

  • Struktur: Berbasis dokumen dengan field seperti creationInfo, packages, relationships, dan annotations.
  • Fleksibel: Mendukung berbagai jenis package - library, file, snippet, container image.
  • Hubungan: Bisa mendefinisikan hubungan antar package (DEPENDS_ON, CONTAINS, GENERATED_FROM).
  • Standar ISO/IEC: SPDX 2.1 telah diadopsi sebagai standar ISO/IEC 5962:2021.
  • Format file: JSON, YAML, XML, RDF, Tag/Value, XLSX.

Contoh SPDX sederhana dalam JSON:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "myapp-sbom",
  "creationInfo": {
    "created": "2026-07-22T10:00:00Z",
    "creators": ["Tool: syft-1.0.0"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-express-4.18.2",
      "name": "express",
      "versionInfo": "4.18.2",
      "supplier": "Organization: npm",
      "licenseConcluded": "MIT"
    }
  ]
}

2. CycloneDX

Dikembangkan oleh OWASP, CycloneDX adalah format yang lebih ringan dan dirancang khusus untuk keamanan aplikasi. Ini adalah format default yang digunakan oleh OWASP Dependency-Track.

Karakteristik CycloneDX:

  • Terstandardisasi: Spesifikasi formal dengan namespaces dan bom (Bill of Materials) sebagai root element.
  • Ekosistem: Terintegrasi dengan OWASP Dependency-Track, OWASP Dependency-Check, dan banyak tool SCA.
  • Keamanan: Mendukung field kerentanan, skor CVSS, dan advisories.
  • Komponen: Bisa mencakup aplikasi, container, library, file, firmware, dan perangkat keras.
  • Format file: JSON dan XML.

Contoh CycloneDX dalam JSON:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-07-22T10:00:00Z",
    "tools": [{"vendor": "anchore", "name": "syft", "version": "1.0.0"}]
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/[email protected]"
    }
  ]
}

3. SWID (Software Identification Tag)

Dikembangkan oleh ISO/IEC, SWID adalah standar untuk identifikasi perangkat lunak yang fokus pada manajemen aset.

Karakteristik SWID:

  • Format: XML-based menggunakan skema dari ISO/IEC 19770-2.
  • Tujuan: Awalnya untuk inventory dan license management, kemudian diperluas untuk keamanan.
  • Adopsi: Banyak digunakan oleh vendor perangkat lunak komersial (Microsoft, Adobe) untuk tagging produk mereka.
  • Keterbatasan: Kurang fleksibel untuk dependensi open-source dibandingkan SPDX dan CycloneDX.

Standar dan Regulasi

NTIA Minimum Elements

National Telecommunications and Information Administration (NTIA) menetapkan elemen minimum yang harus ada dalam SBOM:

  1. Supplier Name: Nama pembuat komponen.
  2. Component Name: Nama komponen (library, framework).
  3. Version: Versi spesifik dari komponen.
  4. Other Unique Identifiers: Seperti PURL (Package URL) atau CPE (Common Platform Enumeration).
  5. Dependency Relationship: Hubungan antar komponen (dependency tree).
  6. SBOM Author Name: Pembuat SBOM.
  7. Timestamp: Tanggal pembuatan.

Executive Order 14028

EO 14028 mewajibkan:

  • Setiap vendor perangkat lunak yang menjual ke pemerintah AS harus menyediakan SBOM.
  • SBOM harus dalam format mesin-bisa-baca (SPDX, CycloneDX, atau SWID).
  • SBOM harus diperbarui setiap kali ada perubahan pada perangkat lunak.

Tools SBOM

Syft

Syft adalah tool open-source dari Anchore untuk menghasilkan SBOM dari container image, file system, dan repository. Mendukung format SPDX, CycloneDX, dan Syft JSON.

Cara menggunakan Syft:

  1. Generate SBOM dari container image:
# Generate SBOM dalam format CycloneDX JSON
syft packages nginx:latest -o cyclonedx-json > nginx-sbom.json

# Generate SBOM dari direktori proyek
syft packages /path/to/project -o spdx-json > project-sbom.json

Contoh output untuk Node.js project:

syft packages ./myapp -o cyclonedx-json

Output akan mencakup semua dependency dari package-lock.json atau yarn.lock, termasuk versi, lisensi, dan PURL.

Trivy

Trivy oleh Aqua Security adalah scanner keamanan serbaguna yang juga bisa menghasilkan SBOM. Trivy mendukung format SPDX dan CycloneDX.

Cara menggunakan Trivy untuk SBOM:

# Generate SBOM dari image
trivy image --format cyclonedx --output app-sbom.json alpine:3.19

# Generate SBOM dari filesystem
trivy filesystem --format spdx-json --output fs-sbom.json /app

# Generate SBOM dari repository Git
trivy repository --format cyclonedx https://github.com/org/repo.git

Trivy juga bisa membandingkan SBOM dengan database kerentanan untuk menghasilkan laporan kerentanan:

trivy sbom app-sbom.json

CycloneDX Plugin Maven/Gradle

Untuk project Java, CycloneDX memiliki plugin resmi:

Maven:

<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.8.0</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>makeAggregateBom</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Generate SBOM:

mvn package
# SBOM akan berada di target/bom.json

Gradle:

plugins {
  id 'org.cyclonedx.bom' version '1.9.0'
}
gradle cyclonedxBom
# SBOM di build/reports/bom.json

SBOM di CI/CD

Integrasi SBOM generation ke dalam pipeline CI/CD adalah praktik terbaik DevSecOps. Contoh konfigurasi GitHub Actions:

name: Generate SBOM
on:
  push:
    branches: [main]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate SBOM with Syft
        uses: anchore/sbom-action@v0
        with:
          path: ./
          format: cyclonedx-json
      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.spdx.json

SBOM Validation dan Vulnerability Correlation

Menghasilkan SBOM tidak cukup - SBOM harus divalidasi dan dikorelasikan dengan database kerentanan.

SBOM Validation

Validasi memastikan SBOM memenuhi format standar dan NTIA minimum elements:

  • CycloneDX CLI: cyclonedx-cli validate --input-file bom.json
  • SPDX Tools: java -jar spdx-tools.jar Validate bom.spdx.json
  • Dependency-Track: Platform manajemen SBOM yang memvalidasi secara otomatis saat upload.

Vulnerability Correlation

Setelah validasi, SBOM harus dicocokkan dengan database CVE:

  • Dependency-Track: Platform open-source yang menerima upload SBOM dan secara otomatis mengkorelasikannya dengan database kerentanan (NVD, GitHub Advisories, OSS Index).
  • Trivy: trivy sbom bom.json - memindai SBOM langsung tanpa perlu image atau filesystem.
  • Grype: Dari Anchore, bisa membaca SBOM Syft dan mencocokkan dengan kerentanan.

Workflow lengkap:

# 1. Generate SBOM
syft packages ./myapp -o cyclonedx-json > bom.json

# 2. Validasi format
cyclonedx-cli validate --input-file bom.json

# 3. Upload ke Dependency-Track
curl -X POST "https://dtrack.example.com/api/v1/bom" \
  -H "X-Api-Key: $API_KEY" \
  -F "[email protected]" \
  -F "projectName=myapp" \
  -F "projectVersion=1.0.0"

# 4. Scan dengan Trivy untuk correlation langsung
trivy sbom bom.json

Kesimpulan

SBOM adalah fondasi dari supply chain security yang baik. Dengan SBOM, organisasi mendapatkan visibilitas penuh terhadap komposisi perangkat lunak mereka - siapa yang membuatnya, versi apa yang digunakan, lisensi apa yang berlaku, dan kerentanan apa yang mengintai.

Mulailah dengan langkah sederhana:

  1. Integrasikan Syft atau Trivy ke dalam pipeline CI/CD untuk menghasilkan SBOM otomatis.
  2. Gunakan format CycloneDX untuk kompatibilitas maksimal dengan tool keamanan (OWASP ecosystem).
  3. Upload SBOM ke Dependency-Track untuk manajemen kerentanan yang berkelanjutan.
  4. Wajibkan SBOM di setiap rilis dan simpan sebagai artifact untuk audit dan incident response.

SBOM bukan sekali jadi - ini adalah proses berkelanjutan yang harus diperbarui setiap kali ada perubahan pada dependensi.

← Sebelumnya 12.5 Supply Chain Security Selanjutnya → Dependency Management
PADA HALAMAN INI