Entri Jurnal
Software and Data Integrity Failures adalah kondisi di mana sistem gagal memverifikasi integritas software, data, atau kode sebelum menggunakannya — memungkinkan penyerang untuk menyisipkan kode berbahaya, memanipulasi update, atau mengeksekusi payload yang tidak sah melalui pipeline yang seharusnya tepercaya.
Kategori ini adalah pengembangan dari "Insecure Deserialization" di edisi 2017 — memperluas konsep dari sekadar masalah serialisasi ke seluruh spektrum kegagalan integritas: dari update mekanisme yang tidak diverifikasi, pipeline CI/CD yang tidak diamankan, hingga insecure deserialization yang dapat memicu eksekusi kode arbitrer.
Dalam bahasa bisnis: ini adalah kondisi di mana sistem tidak memverifikasi bahwa apa yang akan dieksekusi adalah benar-benar apa yang seharusnya dieksekusi — membuka peluang bagi penyerang untuk mengganti, memodifikasi, atau menyisipkan kode melalui jalur yang dianggap tepercaya.
Setiap artifact software yang masuk ke dalam sistem — library, update, plugin, container image, paket instalasi — berpotensi telah dimanipulasi sebelum sampai ke tangan Anda. Tanpa mekanisme verifikasi integritas yang kuat, sistem tidak dapat membedakan antara software yang sah dan software yang telah dikompromikan.
Skenario risiko:
Library yang diunduh dari registry publik yang telah diganti dengan versi berbahaya
Update software yang dimanipulasi dalam proses distribusi
Container image yang mengandung komponen yang dikompromikan
Build artifacts yang dimodifikasi dalam pipeline CI/CD yang tidak aman
Sistem yang memproses data yang datang dari luar — objek yang di-deserialize, konfigurasi yang dimuat dari storage eksternal, pesan dari queue — harus memverifikasi bahwa data tersebut tidak dimanipulasi dan berasal dari sumber yang tepercaya.
Skenario risiko:
Objek yang di-deserialize mengandung payload berbahaya yang dieksekusi saat deserialization
Konfigurasi yang di-load dari lokasi yang dapat dikontrol penyerang
Pesan antrian yang dimanipulasi untuk mengubah logika bisnis
Deserialization adalah proses mengubah data yang tersimpan (dalam format JSON, XML, binary, YAML, dll.) kembali menjadi objek dalam memori. Ketika data yang di-deserialize berasal dari sumber yang tidak tepercaya dan tidak divalidasi, penyerang dapat membuat payload serialized yang mengeksekusi kode arbitrer saat di-deserialize.
Bahaya deserialization berbeda berdasarkan bahasa:
Java: Gadget chains dalam library umum (Apache Commons Collections, Spring) dapat menghasilkan Remote Code Execution
PHP: Unserialize() dengan objek berbahaya dapat memanggil method arbitrary melalui magic methods
Python: pickle.loads() dari data tidak tepercaya adalah Remote Code Execution secara langsung
.NET: BinaryFormatter (deprecated) dan beberapa serializer lain rentan terhadap object injection
Mekanisme update yang mengunduh dan mengeksekusi kode tanpa memverifikasi integritas dan keasliannya — melalui signature kriptografis atau checksum:
Proses update yang rentan:
1. Aplikasi request update dari server → URL yang mungkin di-intercept
2. Server mengirim file update → tidak ada signature verification
3. Aplikasi langsung mengeksekusi → malicious update berjalan
Skenario serangan: man-in-the-middle attack yang menggantikan update yang sah dengan malware; DNS hijacking yang mengarahkan update request ke server berbahaya.
Pipeline CI/CD yang tidak diamankan adalah attack surface yang sangat berharga bagi penyerang. Kompromi pada tahap mana pun dalam pipeline dapat menyisipkan kode berbahaya ke dalam production build tanpa mengubah repository kode sumber.
Titik kerentanan dalam pipeline:
Secrets dalam environment variables yang dapat dibaca oleh script berbahaya
Build scripts yang mengunduh dependency dari lokasi tidak tepercaya pada runtime
Insufficient isolation antara build jobs
Over-privileged service accounts yang digunakan oleh CI/CD
Third-party GitHub Actions atau CI/CD plugins yang tidak diverifikasi
Mendistribusikan dan mengeksekusi code artifacts (binary, container images, library) tanpa tanda tangan kriptografis memungkinkan substitusi tanpa deteksi.
Memuat plugin, konfigurasi, atau kode eksekusi dari sumber yang tidak diverifikasi — CDN pihak ketiga, package registry publik, atau URL eksternal yang dapat dikontrol penyerang.
Contoh nyata: Serangan Magecart — skrip JavaScript berbahaya disisipkan ke CDN atau melalui kompromi third-party script provider, kemudian dimuat oleh ribuan website yang mempercayai CDN tersebut.
Aplikasi yang secara otomatis mengunduh dan mengeksekusi versi terbaru tanpa memverifikasi signature kriptografis dari update tersebut — rentan terhadap supply chain attack dan man-in-the-middle.
Pipeline CI/CD adalah proses yang mengubah kode sumber menjadi software yang berjalan di produksi. Ia adalah target yang sangat menarik bagi penyerang karena:
Akses luas: Pipeline biasanya memiliki akses ke repository kode, production infrastructure, secrets, dan deployment systems
Otomasi: Perubahan di pipeline dieksekusi secara otomatis — tidak ada manusia yang mereview setiap eksekusi
Kepercayaan implisit: Output pipeline sering diasumsikan aman karena berasal dari proses internal
Poisoned Pipeline Execution (PPE): Penyerang dengan akses minimal ke repository (misalnya hanya bisa membuat pull request) dapat memanipulasi pipeline configuration file (.github/workflows/, .gitlab-ci.yml) untuk mengeksekusi perintah berbahaya dalam konteks pipeline yang memiliki akses penuh.
Exposed Secrets: Credentials, API keys, dan token yang disimpan sebagai environment variables dalam pipeline dapat ter-ekspos melalui log, PR comments, atau script berbahaya yang mengekstraknya.
Third-party Actions Abuse: GitHub Actions atau CI/CD plugins dari pihak ketiga yang menggunakan @main atau @latestdapat berubah menjadi berbahaya jika akun publisher dikompromikan.
Software and Data Integrity Failures dan Software Supply Chain Failures (A06) berkaitan erat namun berbeda fokus:
A06 Supply Chain Failures | A08 Integrity Failures | |
|---|---|---|
Fokus | Komponen dan dependency yang digunakan | Mekanisme verifikasi dan integritas |
Pertanyaan kunci | "Apakah komponen ini mengandung kerentanan?" | "Apakah kita memverifikasi bahwa ini adalah yang seharusnya?" |
Contoh | Log4j yang rentan digunakan | Update Log4j yang telah dimanipulasi di-install tanpa verifikasi |
Solusi | SCA, dependency management | Code signing, integrity verification, secure pipeline |
Keduanya saling melengkapi, organisasi perlu menangani keduanya untuk supply chain security yang komprehensif.
SLSA (Supply chain Levels for Software Artifacts) adalah framework dari Google yang mendefinisikan empat tingkatan jaminan integritas:
Level | Persyaratan | Perlindungan yang Diberikan |
|---|---|---|
SLSA 1 | Build process terdokumentasi; SBOM tersedia | Dasar provenance |
SLSA 2 | Versioned build scripts; authenticated provenance | Proteksi terhadap modifikasi source |
SLSA 3 | Build environment terisolasi; non-forgeable provenance | Proteksi terhadap kompromis build |
SLSA 4 | Hermetic build; two-party review | Proteksi maksimal terhadap insider threat |
Mayoritas organisasi saat ini berada di SLSA Level 0 atau 1 — belum ada verifikasi formal terhadap integritas proses build.
Eksekusi Kode Berbahaya di Produksi
Insecure deserialization atau update mechanism yang dikompromikan dapat mengakibatkan Remote Code Execution langsung di server produksi — level kompromi tertinggi.
Silent Data Manipulation
Pesan atau konfigurasi yang dimanipulasi tanpa terdeteksi dapat mengubah perilaku bisnis secara subtle — mengubah nilai transaksi, memanipulasi logika persetujuan, atau mengubah data laporan.
Supply Chain Cascade Effect
Jika software yang Anda distribusikan kepada pelanggan terkompromi (seperti SolarWinds), tanggung jawab hukum dan reputasi Anda terhadap pelanggan menjadi sangat signifikan.
Breach yang Tidak Terdeteksi Lama
Kompromi melalui integrity failures — terutama yang menyisipkan backdoor dalam update yang sah — dapat bertahan berbulan-bulan hingga bertahun-tahun tanpa terdeteksi.
SolarWinds Orion (2020)
Kasus paling ikonik. Build system SolarWinds dikompromikan untuk menyisipkan backdoor SUNBURST ke dalam update Orion yang ditandatangani secara sah. Signature kriptografis yang valid dari SolarWinds sendiri membuat update terlihat sah — inilah kegagalan integritas yang paling canggih.
Codecov Bash Uploader (2021)
Script bash yang digunakan jutaan developer untuk mengunggah hasil coverage testing dikompromikan. Semua CI/CD pipeline yang menggunakan script ini secara otomatis mengekstrak environment variables — termasuk credentials cloud dan access tokens — dan mengirimkannya ke server penyerang.
Event-Stream npm Package (2018)
Package npm populer (event-stream, 2 juta download/minggu) diambil alih oleh kontributor baru yang menambahkan dependency berbahaya yang mencuri bitcoin wallet dari aplikasi cryptocurrency tertentu. Serangan yang sangat tertarget dan tersembunyi.
PHP Git Repository (2021)
Repository Git resmi PHP (php.git) disusupi secara langsung dan dua commit berbahaya ditambahkan yang mengandung backdoor. Ditemukan dalam beberapa jam namun menunjukkan bahwa bahkan repository resmi proyek besar pun bisa dikompromikan.
3CX Supply Chain Attack (2023)
Aplikasi desktop 3CX (digunakan oleh 600.000 perusahaan) dikompromikan melalui supply chain attack berlapis: attacker pertama kali mengkompromikan library pihak ketiga yang digunakan 3CX (Trading Technologies X_TRADER), yang kemudian menginfeksi build 3CX — supply chain attack di dalam supply chain attack.
Tanda Tangani Semua Artifacts Secara Kriptografis
Setiap build artifact — binary, container image, library release — harus ditandatangani menggunakan kunci privat yang terlindungi. Verifikasi signature sebelum eksekusi di setiap lingkungan.
Gunakan Sigstore / Cosign
Framework open-source untuk penandatanganan dan verifikasi artifacts software secara transparan. Semakin menjadi standar industri untuk container images dan package signing.
Amankan CI/CD Pipeline
Terapkan least privilege pada service accounts pipeline, gunakan ephemeral build environments, pin semua third-party actions ke commit hash spesifik (bukan @main), dan scan untuk secrets dalam logs.
Hindari Deserialization dari Untrusted Sources
Jika memungkinkan, ganti format serialisasi binary (Java serialization, PHP unserialize, Python pickle) dengan JSON atau format berbasis teks lainnya untuk data yang datang dari sumber tidak tepercaya. Jika tidak bisa dihindari, implementasikan deserialization allowlist.
Verifikasi Checksum
Untuk semua software yang diunduh dari sumber eksternal, verifikasi SHA-256 atau SHA-512 checksum terhadap nilai yang dipublikasikan secara terpisah dari file itu sendiri.
Implementasikan SLSA
Mulai dari SLSA Level 1 (dokumentasi dan SBOM) dan tingkatkan secara bertahap. Bahkan Level 1 memberikan visibilitas yang jauh lebih baik dibanding tanpa SLSA sama sekali.
Subresource Integrity (SRI) untuk CDN
Untuk skrip dan stylesheet yang dimuat dari CDN eksternal, gunakan Subresource Integrity attribute untuk memastikan konten yang dimuat sesuai dengan yang diharapkan:
<!-- Tanpa SRI — rentan jika CDN dikompromikan -->
<script src="https://cdn.example.com/library.js"></script>
<!-- Dengan SRI — browser memverifikasi hash sebelum mengeksekusi -->
<script src="https://cdn.example.com/library.js"
integrity="sha384-[hash]"
crossorigin="anonymous"></script>
Tool / Framework | Fungsi | Ketersediaan |
|---|---|---|
Sigstore / Cosign | Penandatanganan dan verifikasi artifact | Open-source |
SLSA Framework | Supply chain integrity levels | Framework (Google) |
in-toto | Framework attestasi supply chain | Open-source |
Syft | SBOM generation | Open-source |
Grype | Vulnerability scanning terhadap SBOM | Open-source |
GitHub Actions — pin SHA | Mencegah third-party action hijack | Built-in GitHub |
ggshield / GitGuardian | Secret scanning dalam code dan CI | Commercial / Free |
Semgrep | SAST termasuk deteksi insecure deserialization | Open-source |
ysoserial | Testing Java deserialization (authorized use) | Open-source |
Kategori | Vendor / Solusi | Kehadiran Indonesia |
|---|---|---|
CI/CD Security | GitHub Advanced Security | ✅ via GitHub |
CI/CD Security | GitLab Security | ✅ via GitLab |
Artifact Security | JFrog Artifactory + Xray | ⚠️ Terbatas |
Container Signing | Sigstore / Cosign | Open-source |
Supply Chain Platform | Palo Alto Prisma Cloud | ✅ Tier 1 |
Supply Chain Platform | Trend Micro Cloud One | ✅ Tier 1 |
Secret Scanning | GitGuardian | ⚠️ Terbatas |
SAST (Deserialization) | Checkmarx | ⚠️ Tier 3 |
SAST (Deserialization) | Semgrep (open-source) | Self-managed |
Consulting | IBM Security, Accenture Security | ✅ Tier 1/2 |
Catatan Indonesia: Praktik penandatanganan artifacts dan verifikasi integritas pipeline masih sangat jarang di Indonesia. Mayoritas tim engineering belum memiliki proses formal untuk memverifikasi integritas dependency dan build artifacts — ini adalah gap signifikan yang akan semakin terasa seiring meningkatnya serangan supply chain.
Entri Jurnal
Software and Data Integrity Failures adalah kondisi di mana sistem gagal memverifikasi integritas software, data, atau kode sebelum menggunakannya — memungkinkan penyerang untuk menyisipkan kode berbahaya, memanipulasi update, atau mengeksekusi payload yang tidak sah melalui pipeline yang seharusnya tepercaya.
Kategori ini adalah pengembangan dari "Insecure Deserialization" di edisi 2017 — memperluas konsep dari sekadar masalah serialisasi ke seluruh spektrum kegagalan integritas: dari update mekanisme yang tidak diverifikasi, pipeline CI/CD yang tidak diamankan, hingga insecure deserialization yang dapat memicu eksekusi kode arbitrer.
Dalam bahasa bisnis: ini adalah kondisi di mana sistem tidak memverifikasi bahwa apa yang akan dieksekusi adalah benar-benar apa yang seharusnya dieksekusi — membuka peluang bagi penyerang untuk mengganti, memodifikasi, atau menyisipkan kode melalui jalur yang dianggap tepercaya.
Setiap artifact software yang masuk ke dalam sistem — library, update, plugin, container image, paket instalasi — berpotensi telah dimanipulasi sebelum sampai ke tangan Anda. Tanpa mekanisme verifikasi integritas yang kuat, sistem tidak dapat membedakan antara software yang sah dan software yang telah dikompromikan.
Skenario risiko:
Library yang diunduh dari registry publik yang telah diganti dengan versi berbahaya
Update software yang dimanipulasi dalam proses distribusi
Container image yang mengandung komponen yang dikompromikan
Build artifacts yang dimodifikasi dalam pipeline CI/CD yang tidak aman
Sistem yang memproses data yang datang dari luar — objek yang di-deserialize, konfigurasi yang dimuat dari storage eksternal, pesan dari queue — harus memverifikasi bahwa data tersebut tidak dimanipulasi dan berasal dari sumber yang tepercaya.
Skenario risiko:
Objek yang di-deserialize mengandung payload berbahaya yang dieksekusi saat deserialization
Konfigurasi yang di-load dari lokasi yang dapat dikontrol penyerang
Pesan antrian yang dimanipulasi untuk mengubah logika bisnis
Deserialization adalah proses mengubah data yang tersimpan (dalam format JSON, XML, binary, YAML, dll.) kembali menjadi objek dalam memori. Ketika data yang di-deserialize berasal dari sumber yang tidak tepercaya dan tidak divalidasi, penyerang dapat membuat payload serialized yang mengeksekusi kode arbitrer saat di-deserialize.
Bahaya deserialization berbeda berdasarkan bahasa:
Java: Gadget chains dalam library umum (Apache Commons Collections, Spring) dapat menghasilkan Remote Code Execution
PHP: Unserialize() dengan objek berbahaya dapat memanggil method arbitrary melalui magic methods
Python: pickle.loads() dari data tidak tepercaya adalah Remote Code Execution secara langsung
.NET: BinaryFormatter (deprecated) dan beberapa serializer lain rentan terhadap object injection
Mekanisme update yang mengunduh dan mengeksekusi kode tanpa memverifikasi integritas dan keasliannya — melalui signature kriptografis atau checksum:
Proses update yang rentan:
1. Aplikasi request update dari server → URL yang mungkin di-intercept
2. Server mengirim file update → tidak ada signature verification
3. Aplikasi langsung mengeksekusi → malicious update berjalan
Skenario serangan: man-in-the-middle attack yang menggantikan update yang sah dengan malware; DNS hijacking yang mengarahkan update request ke server berbahaya.
Pipeline CI/CD yang tidak diamankan adalah attack surface yang sangat berharga bagi penyerang. Kompromi pada tahap mana pun dalam pipeline dapat menyisipkan kode berbahaya ke dalam production build tanpa mengubah repository kode sumber.
Titik kerentanan dalam pipeline:
Secrets dalam environment variables yang dapat dibaca oleh script berbahaya
Build scripts yang mengunduh dependency dari lokasi tidak tepercaya pada runtime
Insufficient isolation antara build jobs
Over-privileged service accounts yang digunakan oleh CI/CD
Third-party GitHub Actions atau CI/CD plugins yang tidak diverifikasi
Mendistribusikan dan mengeksekusi code artifacts (binary, container images, library) tanpa tanda tangan kriptografis memungkinkan substitusi tanpa deteksi.
Memuat plugin, konfigurasi, atau kode eksekusi dari sumber yang tidak diverifikasi — CDN pihak ketiga, package registry publik, atau URL eksternal yang dapat dikontrol penyerang.
Contoh nyata: Serangan Magecart — skrip JavaScript berbahaya disisipkan ke CDN atau melalui kompromi third-party script provider, kemudian dimuat oleh ribuan website yang mempercayai CDN tersebut.
Aplikasi yang secara otomatis mengunduh dan mengeksekusi versi terbaru tanpa memverifikasi signature kriptografis dari update tersebut — rentan terhadap supply chain attack dan man-in-the-middle.
Pipeline CI/CD adalah proses yang mengubah kode sumber menjadi software yang berjalan di produksi. Ia adalah target yang sangat menarik bagi penyerang karena:
Akses luas: Pipeline biasanya memiliki akses ke repository kode, production infrastructure, secrets, dan deployment systems
Otomasi: Perubahan di pipeline dieksekusi secara otomatis — tidak ada manusia yang mereview setiap eksekusi
Kepercayaan implisit: Output pipeline sering diasumsikan aman karena berasal dari proses internal
Poisoned Pipeline Execution (PPE): Penyerang dengan akses minimal ke repository (misalnya hanya bisa membuat pull request) dapat memanipulasi pipeline configuration file (.github/workflows/, .gitlab-ci.yml) untuk mengeksekusi perintah berbahaya dalam konteks pipeline yang memiliki akses penuh.
Exposed Secrets: Credentials, API keys, dan token yang disimpan sebagai environment variables dalam pipeline dapat ter-ekspos melalui log, PR comments, atau script berbahaya yang mengekstraknya.
Third-party Actions Abuse: GitHub Actions atau CI/CD plugins dari pihak ketiga yang menggunakan @main atau @latestdapat berubah menjadi berbahaya jika akun publisher dikompromikan.
Software and Data Integrity Failures dan Software Supply Chain Failures (A06) berkaitan erat namun berbeda fokus:
A06 Supply Chain Failures | A08 Integrity Failures | |
|---|---|---|
Fokus | Komponen dan dependency yang digunakan | Mekanisme verifikasi dan integritas |
Pertanyaan kunci | "Apakah komponen ini mengandung kerentanan?" | "Apakah kita memverifikasi bahwa ini adalah yang seharusnya?" |
Contoh | Log4j yang rentan digunakan | Update Log4j yang telah dimanipulasi di-install tanpa verifikasi |
Solusi | SCA, dependency management | Code signing, integrity verification, secure pipeline |
Keduanya saling melengkapi, organisasi perlu menangani keduanya untuk supply chain security yang komprehensif.
SLSA (Supply chain Levels for Software Artifacts) adalah framework dari Google yang mendefinisikan empat tingkatan jaminan integritas:
Level | Persyaratan | Perlindungan yang Diberikan |
|---|---|---|
SLSA 1 | Build process terdokumentasi; SBOM tersedia | Dasar provenance |
SLSA 2 | Versioned build scripts; authenticated provenance | Proteksi terhadap modifikasi source |
SLSA 3 | Build environment terisolasi; non-forgeable provenance | Proteksi terhadap kompromis build |
SLSA 4 | Hermetic build; two-party review | Proteksi maksimal terhadap insider threat |
Mayoritas organisasi saat ini berada di SLSA Level 0 atau 1 — belum ada verifikasi formal terhadap integritas proses build.
Eksekusi Kode Berbahaya di Produksi
Insecure deserialization atau update mechanism yang dikompromikan dapat mengakibatkan Remote Code Execution langsung di server produksi — level kompromi tertinggi.
Silent Data Manipulation
Pesan atau konfigurasi yang dimanipulasi tanpa terdeteksi dapat mengubah perilaku bisnis secara subtle — mengubah nilai transaksi, memanipulasi logika persetujuan, atau mengubah data laporan.
Supply Chain Cascade Effect
Jika software yang Anda distribusikan kepada pelanggan terkompromi (seperti SolarWinds), tanggung jawab hukum dan reputasi Anda terhadap pelanggan menjadi sangat signifikan.
Breach yang Tidak Terdeteksi Lama
Kompromi melalui integrity failures — terutama yang menyisipkan backdoor dalam update yang sah — dapat bertahan berbulan-bulan hingga bertahun-tahun tanpa terdeteksi.
SolarWinds Orion (2020)
Kasus paling ikonik. Build system SolarWinds dikompromikan untuk menyisipkan backdoor SUNBURST ke dalam update Orion yang ditandatangani secara sah. Signature kriptografis yang valid dari SolarWinds sendiri membuat update terlihat sah — inilah kegagalan integritas yang paling canggih.
Codecov Bash Uploader (2021)
Script bash yang digunakan jutaan developer untuk mengunggah hasil coverage testing dikompromikan. Semua CI/CD pipeline yang menggunakan script ini secara otomatis mengekstrak environment variables — termasuk credentials cloud dan access tokens — dan mengirimkannya ke server penyerang.
Event-Stream npm Package (2018)
Package npm populer (event-stream, 2 juta download/minggu) diambil alih oleh kontributor baru yang menambahkan dependency berbahaya yang mencuri bitcoin wallet dari aplikasi cryptocurrency tertentu. Serangan yang sangat tertarget dan tersembunyi.
PHP Git Repository (2021)
Repository Git resmi PHP (php.git) disusupi secara langsung dan dua commit berbahaya ditambahkan yang mengandung backdoor. Ditemukan dalam beberapa jam namun menunjukkan bahwa bahkan repository resmi proyek besar pun bisa dikompromikan.
3CX Supply Chain Attack (2023)
Aplikasi desktop 3CX (digunakan oleh 600.000 perusahaan) dikompromikan melalui supply chain attack berlapis: attacker pertama kali mengkompromikan library pihak ketiga yang digunakan 3CX (Trading Technologies X_TRADER), yang kemudian menginfeksi build 3CX — supply chain attack di dalam supply chain attack.
Tanda Tangani Semua Artifacts Secara Kriptografis
Setiap build artifact — binary, container image, library release — harus ditandatangani menggunakan kunci privat yang terlindungi. Verifikasi signature sebelum eksekusi di setiap lingkungan.
Gunakan Sigstore / Cosign
Framework open-source untuk penandatanganan dan verifikasi artifacts software secara transparan. Semakin menjadi standar industri untuk container images dan package signing.
Amankan CI/CD Pipeline
Terapkan least privilege pada service accounts pipeline, gunakan ephemeral build environments, pin semua third-party actions ke commit hash spesifik (bukan @main), dan scan untuk secrets dalam logs.
Hindari Deserialization dari Untrusted Sources
Jika memungkinkan, ganti format serialisasi binary (Java serialization, PHP unserialize, Python pickle) dengan JSON atau format berbasis teks lainnya untuk data yang datang dari sumber tidak tepercaya. Jika tidak bisa dihindari, implementasikan deserialization allowlist.
Verifikasi Checksum
Untuk semua software yang diunduh dari sumber eksternal, verifikasi SHA-256 atau SHA-512 checksum terhadap nilai yang dipublikasikan secara terpisah dari file itu sendiri.
Implementasikan SLSA
Mulai dari SLSA Level 1 (dokumentasi dan SBOM) dan tingkatkan secara bertahap. Bahkan Level 1 memberikan visibilitas yang jauh lebih baik dibanding tanpa SLSA sama sekali.
Subresource Integrity (SRI) untuk CDN
Untuk skrip dan stylesheet yang dimuat dari CDN eksternal, gunakan Subresource Integrity attribute untuk memastikan konten yang dimuat sesuai dengan yang diharapkan:
<!-- Tanpa SRI — rentan jika CDN dikompromikan -->
<script src="https://cdn.example.com/library.js"></script>
<!-- Dengan SRI — browser memverifikasi hash sebelum mengeksekusi -->
<script src="https://cdn.example.com/library.js"
integrity="sha384-[hash]"
crossorigin="anonymous"></script>
Tool / Framework | Fungsi | Ketersediaan |
|---|---|---|
Sigstore / Cosign | Penandatanganan dan verifikasi artifact | Open-source |
SLSA Framework | Supply chain integrity levels | Framework (Google) |
in-toto | Framework attestasi supply chain | Open-source |
Syft | SBOM generation | Open-source |
Grype | Vulnerability scanning terhadap SBOM | Open-source |
GitHub Actions — pin SHA | Mencegah third-party action hijack | Built-in GitHub |
ggshield / GitGuardian | Secret scanning dalam code dan CI | Commercial / Free |
Semgrep | SAST termasuk deteksi insecure deserialization | Open-source |
ysoserial | Testing Java deserialization (authorized use) | Open-source |
Kategori | Vendor / Solusi | Kehadiran Indonesia |
|---|---|---|
CI/CD Security | GitHub Advanced Security | ✅ via GitHub |
CI/CD Security | GitLab Security | ✅ via GitLab |
Artifact Security | JFrog Artifactory + Xray | ⚠️ Terbatas |
Container Signing | Sigstore / Cosign | Open-source |
Supply Chain Platform | Palo Alto Prisma Cloud | ✅ Tier 1 |
Supply Chain Platform | Trend Micro Cloud One | ✅ Tier 1 |
Secret Scanning | GitGuardian | ⚠️ Terbatas |
SAST (Deserialization) | Checkmarx | ⚠️ Tier 3 |
SAST (Deserialization) | Semgrep (open-source) | Self-managed |
Consulting | IBM Security, Accenture Security | ✅ Tier 1/2 |
Catatan Indonesia: Praktik penandatanganan artifacts dan verifikasi integritas pipeline masih sangat jarang di Indonesia. Mayoritas tim engineering belum memiliki proses formal untuk memverifikasi integritas dependency dan build artifacts — ini adalah gap signifikan yang akan semakin terasa seiring meningkatnya serangan supply chain.