Selama bertahun-tahun, penyerang menargetkan aplikasi satu per satu. Mereka telah mengubah taktik: mengapa membahayakan satu aplikasi jika Anda dapat membahayakan seluruh aplikasi? pipeline yang membangun banyak? Xygeni's Peringatan Dini Malware (MEW) terdeteksi 4,452 paket berbahaya pada tahun 2025 ke 1,281 lagi pada tahun 2026 sejauh iniSetiap insiden penting dalam beberapa tahun terakhir telah mengenai mata rantai yang berbeda dalam proses pengiriman perangkat lunak:
- Angin Surya (2020): kompromi lingkungan pengembangan; pembaruan dengan pintu belakang dikirimkan ke 18,000 pelanggan.
- Codecov (2021)Sebuah citra Docker yang salah konfigurasi memungkinkan penyerang memodifikasi skrip pengunggah bash, sehingga mencuri rahasia CI dari lebih dari 23,000 pelanggan.
- CircleCI (2023)Pencurian cookie sesi di laptop seorang insinyur berubah menjadi token akses produksi; setiap pelanggan diberitahu untuk mengganti setiap rahasia secara berkala.
- Pintu belakang XZ Utils (2024) :sebuah kampanye rekayasa sosial selama bertahun-tahun yang hampir menjangkau setiap distribusi Linux.
- tj-actions (2025) — sebuah rangkaian efek rantai pasokan GitHub Actions yang merusak komponen yang digunakan oleh lebih dari 23,000 repositori.
- Serangan pada Aqua Trivy ke tanda centang (2026) — Kampanye TeamPCP mengubah dua pemindai keamanan yang banyak digunakan menjadi vektor serangan, lalu menggunakan data yang dicuri CI/CD kredensial untuk diteruskan ke npm, OpenVSX, dan PyPI.
Setiap serangan mengeksploitasi bagian yang berbeda dari pipeline: lingkungan build, alat CI, dependensi, kredensial pengembang, kepercayaan pengelola, referensi yang dapat diubah ke artefak. Sebagian besar organisasi merespons dengan kontrol titik, pemindai di CI, 2FA pada IdP, perlindungan cabang pada mainYang biasanya hilang adalah cara untuk bertanya. Apakah kita terlindungi secara sistematis? daripada Apakah kita ingat untuk mengaktifkan X setelah insiden terakhir?
Para vendor keamanan aplikasi berada tepat di sasaran, karena jika salah satu vendor terkompromikan, dampaknya akan terasa pada setiap pelanggan yang mempercayai artefak mereka. Tekanan untuk beralih dari kontrol reaktif ke pendekatan sistematis bukanlah teori semata. Itu sudah menjadi kenyataan.cisapa yang memotivasi adopsi OWASP SPVS standard sebagai proyek prioritas utama.
Apa Itu SPVS, dan Mengapa Struktur Tersebut Penting
Kisah asal-usulnya sederhana. Di LASCON 2023, Farshad Abasi dan Cameron Walters terus saling mengajukan pertanyaan yang sama: di mana ASVS untuk... pipelineOWASP ASVS telah memberikan keamanan aplikasi yang komprehensif dan dapat diverifikasi. standardTidak ada yang setara untuk itu CI/CD.
Ada OWASP Top 10. CI/CD Risiko, yang berorientasi pada kesadaran, tidak dapat diuji; SLSA, yang hanya berfokus pada asal usul build; S2C2F, yang hanya berfokus pada konsumsi dependensi; dan OpenSSF Kartu penilaian, yang mencakup pemeriksaan repositori spesifik. Masing-masing mencakup satu bagian. Tidak satu pun yang mencakup keseluruhan.
| Kerangka Kerja atau Proyek | Ruang Lingkup Utama |
|---|---|
| 10 Teratas OWASP CI/CD Risiko | Berorientasi pada kesadaran CI/CD panduan risiko, bukan verifikasi yang dapat diuji standard. |
| SLSA | Membangun asal usul dan integritas artefak. |
| S2C2F | Konsumsi dependensi yang aman. |
| OpenSSF Kartu Skor | Pemeriksaan keamanan spesifik tingkat repositori. |
Kesenjangannya: setiap kerangka kerja mencakup bagian penting dari software supply chain securityNamun, tidak satu pun yang menyediakan pendekatan ujung-ke-ujung yang dapat diverifikasi. standard untuk keseluruhan CI/CD pipeline.
Percakapan itu berujung pada kerja selama dua tahun, dan pada Oktober 2025 kelompok kerja SPVS merilis v1.0: 127 persyaratan di seluruh siklus hidup, Rencana, Pengembangan, Integrasi, Rilis, Operasi, yang dikelompokkan menjadi tiga tingkat kematangan: L1 Dasar, L2 Standard, dan L3 Tingkat Lanjut. Setiap persyaratan dipetakan ke NIST SP 800-53, OWASP CI/CD 10 Besar, dan CWE.
Struktur adalah intinya. Dalam kata-kata para penulis SPVS sendiri:
“Verifikasi seluruh data Anda” pipelineBukan hanya satu bagian. Di sinilah sebagian besar organisasi mengalami kesulitan. Mereka memindai dependensi tetapi mengabaikan tata kelola rilis. Mereka menandatangani artefak tetapi tidak membuat model ancaman untuk artefak mereka. pipeline arsitektur. Mereka memantau produksi tetapi tidak memantau lingkungan pengembangan mereka.”
Di sinilah sebagian besar organisasi mengalami kesulitan. Mereka memindai dependensi tetapi mengabaikan tata kelola rilis. Mereka menandatangani artefak tetapi tidak membuat model ancaman untuk artefak mereka. pipeline arsitektur. Mereka memantau produksi tetapi tidak memantau lingkungan pengembangan mereka.
Inilah tesis yang membenarkan upaya tersebut. Kekuatan di satu tahap tidak mengimbangi kelemahan di tahap lain. Penyerang hanya membutuhkan satu mata rantai untuk dihancurkan. Sebuah siklus hidup. standard SPVS memaksa Anda untuk memeriksa semuanya, dan progresi L1 ke L2 ke L3 memungkinkan Anda melakukannya tanpa harus bersusah payah. SPVS tidak menggantikan SLSA, S2C2F, Scorecard, atau Sigstore; SPVS memberi Anda kerangka kerja yang memberi tahu Anda di mana masing-masing dari mereka cocok.
Mengadaptasi Standard untuk Organisasi Anda
Langkah pertama yang wajar adalah audit langsung terhadap organisasi dan infrastruktur perangkat lunak Anda terhadap setiap persyaratan. Sebuah Google Sheet yang diisi dari sumber resmi. Persyaratan SPVS CSV Berfungsi dengan baik sebagai titik awal. Tiga tampilan yang berguna adalah: matriks persyaratan dengan status dan pemilik per kontrol, peta panas per repositori, dan sebuah dashboard tentang kemajuan berdasarkan tahapan dan level. Hasilnya secara alami terintegrasi ke dalam peta jalan teknis, sebuah dokumen dinamis yang mencakup setiap tahapan dari perencanaan hingga pengoperasian.
Sebagian besar organisasi teknik yang sudah mapan akan mendapati diri mereka sudah berada di level L2 ketika melakukan pemetaan awal ini. Itu sebenarnya posisi yang baik: artinya fase pertama dapat fokus pada menutup kesenjangan spesifik daripada membangun fondasi dari awal.
Namun, spreadsheet hanyalah sebuah cuplikan, dan SPVS meminta lebih dari itu. V1.1.7 mewajibkan audit triwulanan terhadap administrator VCS; V5.1.1 hingga V5.1.3 menambahkan audit pengguna reguler, tinjauan log akses, dan pemantauan akses istimewa; beberapa kontrol V2.1.x, V3.3.x, dan V4.2.x memerlukan pemeliharaan alur kerja-YAML yang berkelanjutan. Jika dilakukan secara manual di seluruh organisasi, itu membutuhkan waktu setengah hari untuk pelacakan klik setiap triwulan dengan risiko nyata adanya kelalaian yang tidak disadari. Ini adalah jenis pekerjaan yang akan diotomatisasi atau hanya ditinjau setelah sesuatu yang buruk terjadi.
Beberapa kontrol SPVS bukanlah item daftar periksa sekali saja. Kontrol tersebut memerlukan tinjauan berkala, bukti audit, dan deteksi penyimpangan di seluruh repositori, pengguna, alur kerja, dan akses istimewa.
| Area SPVS | Jenis Persyaratan |
|---|---|
V1.1.7 | Audit triwulanan terhadap administrator VCS. |
V5.1.1–V5.1.3 | Audit pengguna secara berkala, peninjauan log akses, dan pemantauan akses istimewa. |
V2.1.x, V3.3.x, V4.2.x | Pemeliharaan alur kerja YAML yang berkelanjutan. |
Jawabannya adalah membangun atau mengadopsi perangkat yang berjalan di bawah identitas pemilik organisasi dan menghasilkan paket triwulanan yang terstruktur: daftar admin, perlindungan cabang, cakupan CODEOWNERS, kebersihan YAML alur kerja dengan tindakan yang disematkan, izin eksplisit, pull_request_target Pengaturan akses, otentikasi dua faktor (2FA) anggota, aplikasi GitHub yang terpasang, dan kunci penyebaran. Apa yang dulunya memakan waktu setengah hari untuk menelusuri spreadsheet kini hanya membutuhkan satu perintah yang menghasilkan JSON dan Markdown. Tinjauan triwulanan antara... CISO dan administrator organisasi menjadi decisPertemuan ini lebih berfokus pada diskusi daripada pengumpulan data, dan temuan yang dapat ditindaklanjuti menjadi masalah yang tertunda dengan SLA berbasis tingkat keparahan.
Kebijakan daftar izin, termasuk admin yang disetujui, aplikasi yang disetujui, dan izin berdasarkan fungsi untuk repositori dan alur kerja, harus disimpan sebagai YAML dalam repositori yang dikontrol versinya, dan diawasi oleh tinjauan permintaan perubahan (PR) dari tim keamanan. Setiap perubahan daftar izin meninggalkan jejak tinjauan, sehingga bukti audit akan terbentuk dengan sendirinya. Efeknya adalah mengubah kontrol yang sebelumnya bersifat aspiratif, seperti "kita harus melakukan audit setiap kuartal," menjadi kontrol rutin, seperti "audit kuartal ini selesai pada hari Senin," dan memberikan organisasi mekanisme yang dapat diulang untuk mendeteksi penyimpangan yang dituntut oleh prinsip ujung-ke-ujung.
Gesekan yang Harus Anda Rencanakan
Kontrol teknis adalah bagian yang mudah. Mengendalikan orang jauh lebih sulit.
Contoh yang paling menonjol hampir selalu adalah CODEOWNERS. Menambahkan .github/workflows/ @your-org/security Menerapkan `merging` di setiap repositori terdengar sepele. Satu file, satu baris. Tetapi itu berarti para insinyur yang telah melakukan `self-merging` perubahan alur kerja selama bertahun-tahun sekarang membutuhkan tinjauan keamanan. Bahkan orang-orang yang sadar akan keamanan pun menolak: Saya yang menulis alur kerja ini, saya memahaminya, mengapa saya harus menunggu?
Diperlukan percakapan yang nyata untuk menetapkan alasannya. Alur kerja dapat membocorkan kredensial, mengalihkan artefak, dan meracuni konsumen hilir. Memiliki sepasang mata tambahan bukanlah ketidakpercayaan; itu adalah logika yang sama dengan empat mata pada perubahan basis data produksi. Memiliki insiden rantai pasokan yang konkret dan baru-baru ini untuk ditunjukkan, baik dari industri maupun lingkungan Anda sendiri, sangat membantu. Tidak ada yang lebih memperjelas suatu kontrol selain contoh nyata dari ketidakberadaannya.
Gesekan lainnya mengikuti bentuk yang sama:
- Izin eksplisit: Blok dalam alur kerja menyebabkan kegagalan CI hingga kontributor memahami izin lingkup. Ini bukan masalah izin, tetapi masalah model mental.
- Kekekalan tag: Mengganggu alat rilis yang telah melakukan penandaan ulang secara diam-diam selama bertahun-tahun.
- Menandatangani commits: Menciptakan hambatan dalam proses orientasi hingga kunci GPG atau SSH diatur dengan benar di seluruh workstation. SPVS mewajibkan hal ini di setiap repositori dan kontributor, bukan hanya yang utama.
- Menggantikan token akses pribadi klasik: Di berbagai repositori dan file alur kerja, hal ini menyentuh hampir setiap tim.
Pola yang berhasil: memperkenalkan setiap kontrol dengan ancaman spesifik yang diblokirnya, melakukan uji coba pada satu atau dua repositori, meluncurkan dengan pengecualian yang diizinkan, dan menghapus pengecualian tersebut pada jangka waktu yang ditentukan. Para insinyur yang paling keras menolak, seringkali menjadi pendukung terkuat setelah mereka memahami alasannya.
Satu poin yang lebih mendalam: prinsip ujung-ke-ujung berlaku di sini. Anda tidak bisa memilih-milih. Memperketat tahap pembangunan sambil membiarkan tata kelola rilis longgar memberikan rasa percaya diri yang palsu, yang justru merupakan mode kegagalan yang dikritik oleh penulis SPVS. Setiap tahap harus berjalan bersama, bahkan ketika kontrol tertentu terasa tidak proporsional jika dilakukan secara terpisah.
Biaya: Kurang lebih satu bulan waktu pengerjaan rekayasa untuk Fase 1, yang berfokus pada kepatuhan L2 untuk organisasi kecil, tersebar di antara tim DevOps, Keamanan, dan peninjau rekayasa. Investasi ini mudah terbayar kembali. Satu insiden rantai pasokan yang dicegah dapat menutupi biaya berkali-kali lipat. Organisasi yang lebih besar harus menganggarkan lebih banyak secara proporsional, tetapi struktur bertahap L1 ke L2 ke L3 berarti nilai sudah diberikan sebelum program selesai.
Apa selanjutnya
SPVS v1.5 akan segera hadir dengan kontrol terkait AI: asal usul kode yang dibantu AI, guardrails untuk alur kerja CI yang memanggil LLM, tinjau jejak untuk yang dihasilkan AI. pull requests, dan pertahanan terhadap ancaman baru seperti slopsquatting, di mana penyerang mendaftarkan nama paket yang dihalusinasi oleh asisten pengkodean AI, dan malware operasional yang dihasilkan AI yang dilaporkan CrowdStrike di lapangan. Organisasi yang sudah memberi tag pada aplikasi yang dibantu AI. commitPara s dan PR dalam pedoman pengembangan internal mereka akan menganggap adaptasi ini sebagai langkah bertahap dan bukan program kerja baru.
Versi 2.0 diharapkan dapat memperdalam pemantauan runtime dan persyaratan siklus hidup kredensial. Rencana kerja organisasi yang masuk akal: menutup kesenjangan L3 yang tersisa pada akhir kuartal kedua tahun 2026, termasuk... SLSA provenance diintegrasikan ke dalam standard CI/CD, gerbang manual untuk penerapan produksi, dan penyedia identitas terpusat, kemudian beralih ke mode pemeliharaan. Setiap repositori baru dimulai dengan kepatuhan, dan setiap audit triwulanan mendeteksi penyimpangan sejak dini.
Ucapan terima kasih yang tulus kepada Farshad Abasi, Cameron Walters, dan kelompok kerja OWASP SPVS. Proyek seperti ini menurunkan standar bagi setiap organisasi yang ingin melakukan keamanan rantai pasokan secara sistematis, bukan secara reaktif.
Ringkasan Utama
Beberapa hal yang dapat diterapkan di luar konteks spesifik kita:
- Untuk mencobanya: Unduh file CSV persyaratan SPVS dan petakan kontrol Anda saat ini ke dalam spreadsheet. Anda akan tahu dalam sehari apakah itu sesuai.
- Pilih satu level target dan selesaikan sebelum beralih ke level berikutnya. L1 ke L2 ke L3 adalah sebuah fitur, bukan keterbatasan.
- The pipeline adalah targetnya. Kontrol yang berpusat pada aplikasi diperlukan tetapi tidak cukup; perlakukan pipeline sebagai permukaan serangan kelas satu.
- Verifikasi keseluruhannya pipeline, tidak satu pun bagian. Kekuatan dalam pemindaian dependensi tidak dapat menutupi tata kelola rilis yang lemah atau lingkungan build yang tidak terpantau.
- Spreadsheet hanyalah cuplikan; pergeseran data bersifat berkelanjutan. Bangun otomatisasi, bahkan alat internal yang sederhana, untuk mendeteksi penyimpangan antar audit.
- Pekerjaan pengorganisasian lebih sulit daripada pekerjaan teknis. Sisihkan waktu untuk percakapan dan uji coba sebelum peluncuran, dan jelaskan ancaman spesifik yang diblokir oleh setiap kontrol.
Untuk Membaca Lebih Lanjut
- OWASP: Aman Pipeline Verifikasi Standard (SPVS) v1.0Halaman Proyek OWASP.
- Farshad Abasi: Mengapa Kami Membuat OWASP SPVSArtikel OWASP SPVS.
- Farshad Abasi: Pipeline Serangan Semakin Memburuk. Berikut Cara Mempersiapkan Diri.Artikel OWASP SPVS.
- Farshad Abasi: OWASP SPVS vs. Kerangka Kerja Rantai Pasokan LainnyaArtikel OWASP SPVS.
- OWASP: Top 10 CI/CD Resiko KeamananHalaman Proyek OWASP.
- SLSA: Tingkat Rantai Pasokan untuk Artefak Perangkat Lunak. slsa.dev.
- OpenSSF: Kartu Skor. securityscorecards.dev.
