The Pembangun Google membentangkan "SLSA" (Tahap rantai bekalan untuk Artifak Perisian) yang mempunyai tujuan untuk mengurus perlindungan infrastruktur pembangunan serangan yang dilakukan pada peringkat pengekodan, pengujian, pembinaan dan pengedaran produk.
Pemaju sebutkan bahawa proses pembangunan semakin kompleks dan bergantung pada alat pihak ketiga, yang mewujudkan keadaan yang baik untuk mempromosikan serangan yang tidak berkaitan dengan pengenalpastian dan eksploitasi kerentanan dalam produk akhir, tetapi dengan komitmen proses pengembangan itu sendiri.
Mengenai SLSA
Disebutkan bahawa SLSA memfokuskan pada dua prinsip asas berikut:
Bukan Satu Sisi - Tidak ada orang yang boleh mengubah artifak perisian di mana sahaja di rantaian bekalan perisian tanpa semakan dan kelulusan eksplisit daripada sekurang-kurangnya satu "orang yang dipercayai" yang lain. [^ 1] Tujuannya adalah pencegahan, pencegahan atau pengesanan awal risiko / perubahan buruk.
Dapat diaudit - Artifak perisian dapat dikesan dengan selamat dan telus ke sumber asli dan pergantungan yang dapat dibaca manusia. Tujuan utamanya adalah analisis sumber dan ketergantungan automatik, serta penyelidikan ad-hoc.
Untuk menyekat ancaman yang ditandai, SLSA menawarkan sekumpulan panduan dan alat untuk mengautomasikan pembuatan metadata untuk pengauditan. SLSA merangkum kaedah serangan biasa dan memperkenalkan konsep lapisan perlindungan.
Setiap lapisan mempunyai keperluan infrastruktur khusus untuk memastikan integriti artifak yang digunakan dalam pembangunan, yaitu, semakin tinggi tahap SLSA yang disokong, semakin banyak pertahanan akan dilaksanakan dan infrastruktur akan dilindungi dengan lebih baik dari serangan biasa.
Tahap 1 SLSA
Pada peringkat ini memerlukan proses membina sepenuhnya automatik dan menghasilkan metadata ("Provenance") tentang bagaimana artifak dikumpulkan, termasuk sumber, ketergantungan, dan membangun proses maklumat (contoh metadata generator untuk pengauditan disediakan untuk tindakan GitHub). SLSA 1 tidak termasuk elemen perlindungan terhadap perubahan berbahayaIni hanya mengenal pasti kod dengan cara paling mudah dan menyediakan metadata untuk pengurusan kerentanan dan analisis risiko.
Tahap 2 SLSA
Di sini lapisan pertama dilanjutkan dengan memerlukan penggunaan sistem kawalan sumber dan membina perkhidmatan yang menghasilkan metadata yang disahkan. Penggunaan SLSA 2 membolehkan anda mengesan asal kod dan mencegah perubahan yang tidak dibenarkan dalam kod anda, sekiranya menggunakan perkhidmatan pemasangan yang boleh dipercayai.
Tahap 3 SLSA
Dari sudut iniatau kod sumber dan platform binaan disahkan memenuhi kehendak piawaian untuk memastikan bahawa kod dapat diaudit dan integriti metadata yang disediakan terjamin. Juruaudit seharusnya dapat mengesahkan platform untuk mematuhi kehendak piawaian.
Tahap 4 SLSA
Ini adalah tahap tertinggi dan juga melengkapkan tahap sebelumnya dengan menambahkan syarat-syarat yang lebih ketat yang merupakan tinjauan wajib terhadap semua perubahan oleh dua pembangun yang berbeza, serta semua langkah penyusunan, kod dan pergantungan. Mereka mesti dinyatakan sepenuhnya, semua kebergantungan mesti diperiksa dan diperiksa secara berasingan, dan proses membina mesti dilakukan di luar talian.
Menggunakan proses penyusunan berulang juga memberikan kemampuan untuk mengulangi proses penyusunan dan memastikan bahawa pelaksanaan dapat disusun dari sumber yang disediakan.
Selain itu kerangka ini mengambil kira 8 jenis serangan berkaitan dengan ancaman perubahan berbahaya dalam peringkat pengembangan, penyusunan, pengujian dan pengedaran kod produk.
Jenis-jenis serangan yang diambil kira adalah seperti berikut:
1.- Penyertaan dalam kod sumber perubahan yang mengandungi jalan belakang atau kesalahan laten yang menyebabkan kerentanan.
2.- Komitmen platform kawalan sumber.
3.- Buat perubahan pada tahap pemindahan kod ke kompilasi atau sistem penyatuan berterusan (kod yang tidak sesuai dengan kod repositori dikumpulkan).
4.- Komitmen platform pembinaan
5.- Promosi kod jahat melalui pergantungan berkualiti rendah.
6.- Memuatkan artifak yang tidak dihasilkan dalam sistem CI / CD.
7.- Kompromi dari repositori pakej.
8.- Kekeliruan dalam pengguna untuk memasang pakej yang salah.
Akhirnya sekiranya anda ingin mengetahui lebih lanjut mengenainya, anda boleh menyemak perinciannya Dalam pautan berikut.