Plugin WordPress Kamu Punya Bom Dependensi Tersembunyi

Plugin atau theme WordPress kamu bisa lolos QA, rapi di dashboard, dan tetap menyimpan risiko yang nggak kelihatan: paket PHP, npm, library JS, font, build tool, bahkan file vendor yang sudah usang. Masalahnya, saat CVE baru muncul, timmu sering baru bertanya, “Kita pakai paket itu nggak?” Di situlah SBOM WordPress jadi pembeda antara audit yang tenang dan panic mode semalaman.

Apa Itu SBOM WordPress, dan Kenapa Sekarang Penting?

SBOM, atau Software Bill of Materials, adalah inventaris komponen software. Bayangkan seperti daftar bahan pada makanan, tetapi untuk kode. Untuk WordPress, SBOM menjawab pertanyaan penting: plugin atau theme kamu bergantung pada paket apa, versi berapa, lisensi apa, dan dari mana asalnya?

Karena ekosistem WordPress sering menggabungkan PHP, JavaScript, CSS framework, dan build pipeline, SBOM nggak cukup dibuat dari satu file saja. Kamu perlu melihat composer.lock, package-lock.json, yarn.lock, asset yang dibundel, serta library yang masuk manual ke folder vendor atau assets.

Masalah yang Diselesaikan SBOM untuk Plugin dan Theme

Tanpa SBOM, vuln tracking sering bergantung pada ingatan developer. Itu rapuh. Selain itu, saat klien enterprise meminta bukti kepatuhan, jawaban “kami rutin update” biasanya belum cukup.

• Pelacakan CVE lebih cepat: cocokkan paket dengan database seperti NVD atau advisory GitHub.
• Audit klien lebih ringan: kirim inventory komponen, lisensi, versi, dan hash.
• Compliance lebih siap: mendukung permintaan vendor risk assessment, SOC 2, ISO 27001, atau procurement enterprise.
• Supply chain lebih transparan: tim bisa tahu dependency langsung dan transitive dependency.

Kalau kamu menjual plugin premium, SBOM juga bisa jadi sinyal trust. Bukan sekadar fitur keamanan, tetapi bukti bahwa proses engineering kamu matang.

Format SBOM yang Paling Masuk Akal untuk WordPress

Dua format yang paling sering dipakai adalah CycloneDX dan SPDX. Keduanya bagus, namun untuk workflow plugin dan theme WordPress, CycloneDX biasanya lebih praktis karena tooling-nya ramah untuk Composer dan npm. SPDX tetap kuat kalau fokusmu banyak di lisensi open source.

• CycloneDX: enak untuk security automation, vuln scanning, dan CI/CD.
• SPDX: kuat untuk license compliance dan legal review.
• JSON: mudah diproses mesin.
• XML: cocok kalau tool audit lama masih memintanya.

Referensi resminya bisa kamu cek di CycloneDX dan SPDX.

Framework Praktis: Source, Build, Ship

Banyak tim membuat SBOM hanya dari source code. Kedengarannya benar, tetapi sering kurang akurat. Yang dipakai user bukan repo mentah, melainkan artefak rilis yang sudah dibuild, diminify, dan dibundel.

Pakai framework sederhana ini: Source, Build, Ship.

1. Source: baca dependency asli

Ambil data dari composer.lock, package-lock.json, pnpm-lock.yaml, atau yarn.lock. Selain itu, cari library manual yang sering luput, misalnya select2, dompurify, phpseclib, atau SDK pembayaran.

2. Build: catat yang berubah saat bundling

Webpack, Vite, atau Rollup bisa mengubah jejak dependency. Karena itu, simpan SBOM setelah proses build juga. Dengan begitu, kamu tahu library mana yang benar-benar masuk ke file produksi.

3. Ship: validasi paket rilis

Ini langkah yang sering dilewatkan. Generate SBOM dari ZIP final yang kamu kirim ke klien, WordPress.org, atau marketplace. Jadi, kalau ada file vendor lama yang ikut terbawa, SBOM akan menangkapnya.

Contoh Workflow SBOM di CI/CD

Kamu bisa mulai simpel. Jangan tunggu platform compliance besar. Untuk plugin atau theme WordPress, workflow dasar ini sudah cukup kuat.

composer install --no-dev --prefer-dist
npm ci
npm run build
cyclonedx-php-composer make-sbom --output-file sbom-composer.json
cyclonedx-npm --output-file sbom-npm.json
zip -r plugin-release.zip . -x "node_modules/*" ".git/*"

Setelah itu, simpan SBOM sebagai artefak rilis. Kemudian, scan dengan tool seperti OWASP Dependency-Track, GitHub dependency review, atau scanner internal. Kalau kamu butuh konteks risiko plugin, baca juga artikel internal ini: Plugin WordPress Bisa Jadi Bom Waktu, Skor Risikonya Dulu.

Data Minimum yang Harus Ada di SBOM

SBOM yang berguna bukan cuma daftar nama paket. Supaya bisa dipakai untuk audit dan vuln tracking, pastikan minimal memuat:

• Nama komponen dan versi.
• Package URL atau identifier yang jelas.
• Lisensi open source.
• Hash file atau artefak rilis.
• Relasi dependency langsung dan transitive.
• Tanggal generate, nama tool, dan versi tool.

Dengan data ini, tim security bisa memetakan risiko tanpa membongkar repo. Selain itu, tim sales enterprise bisa menjawab questionnaire klien lebih cepat.

Kesalahan Umum yang Bikin SBOM Kurang Bernilai

• Cuma generate dari Composer: padahal banyak risiko masuk dari npm dan asset frontend.
• SBOM nggak diikat ke versi rilis: akibatnya audit sulit membuktikan paket mana dipakai di versi tertentu.
• Mengabaikan library bundled: folder assets/lib sering menyimpan paket lama.
• Tidak menyimpan history: padahal diff antar SBOM membantu melihat risiko baru.

FAQ SBOM WordPress

Apakah semua plugin WordPress perlu SBOM?

Kalau plugin kamu dipakai klien bisnis, memproses data sensitif, atau memakai dependency eksternal, ya. Untuk plugin kecil pribadi, SBOM tetap berguna, tetapi prioritasnya bisa lebih rendah.

Apakah SBOM bisa mencegah serangan?

SBOM bukan firewall. Namun, SBOM mempercepat deteksi dampak saat ada kerentanan baru. Karena itu, respon incident jadi lebih cepat dan terukur.

Kapan SBOM harus dibuat?

Buat SBOM setiap rilis, terutama setelah update dependency, build asset, atau perubahan vendor library. Selain itu, simpan SBOM bersama artefak ZIP final.

Penutup: Jangan Audit Saat Sudah Panik

SBOM WordPress membuat dependency yang tadinya samar jadi terlihat. Untuk vendor plugin, agency, dan enterprise WP owner, ini bukan administrasi tambahan. Ini cara menjaga trust, mempercepat audit, dan mengurangi risiko supply chain sebelum jadi tiket darurat.

Kalau kamu ingin lebih banyak panduan WordPress security, supply chain, dan compliance yang praktis, subscribe newsletter Google kami di bawah ini.