Google mencadangkan SLSA untuk melindungi daripada perubahan berniat jahat semasa pembangunan

Google memperkenalkan rangka kerja SLSA (Tahap Rantaian Bekalan untuk Artifak Perisian), yang meringkaskan pengalaman sedia ada dalam melindungi infrastruktur pembangunan daripada serangan yang dijalankan pada peringkat menulis kod, menguji, memasang dan mengedarkan produk.

Proses pembangunan menjadi semakin kompleks dan bergantung pada alat pihak ketiga, yang mewujudkan keadaan yang menggalakkan untuk kemajuan serangan yang berkaitan bukan untuk mengenal pasti dan mengeksploitasi kelemahan dalam produk akhir, tetapi untuk menjejaskan proses pembangunan itu sendiri (serangan rantaian bekalan, biasanya bertujuan untuk memperkenalkan perubahan berniat jahat dalam proses menulis kod, penggantian komponen yang diedarkan dan kebergantungan).

Rangka kerja ini mengambil kira 8 jenis serangan yang berkaitan dengan ancaman membuat perubahan berniat jahat pada peringkat pembangunan kod, pemasangan, ujian dan pengedaran produk.

Google mencadangkan SLSA untuk melindungi daripada perubahan berniat jahat semasa pembangunan

  • A. Termasuk perubahan dalam kod sumber yang mengandungi pintu belakang atau ralat tersembunyi yang membawa kepada kelemahan.

    Contoh serangan: β€œHypocrite Commits” - percubaan untuk mempromosikan patch dengan kelemahan ke dalam kernel Linux.

    Kaedah keselamatan yang dicadangkan: semakan bebas bagi setiap perubahan oleh dua pembangun.

  • B. Kompromi platform kawalan kod sumber.

    Contoh serangan: suntikan komit berniat jahat dengan pintu belakang ke dalam repositori Git projek PHP selepas kata laluan pembangun dibocorkan.

    Kaedah perlindungan yang dicadangkan: Peningkatan keselamatan platform pengurusan kod (dalam kes PHP, serangan itu dilakukan melalui antara muka HTTPS yang sedikit digunakan, yang membenarkan perubahan dihantar apabila log masuk menggunakan kata laluan tanpa menyemak kunci SSH, walaupun fakta bahawa MD5 yang tidak boleh dipercayai telah digunakan untuk mencincang kata laluan).

  • C. Membuat perubahan pada peringkat pemindahan kod ke binaan atau sistem integrasi berterusan (kod yang tidak sepadan dengan kod dari repositori dibina).

    Contoh serangan: Menyuntik pintu belakang ke dalam Webmin dengan membuat perubahan pada infrastruktur binaan, mengakibatkan penggunaan fail kod yang berbeza daripada fail dalam repositori.

    Kaedah perlindungan yang dicadangkan: Memeriksa integriti dan mengenal pasti sumber kod pada pelayan pemasangan.

  • D. Kompromi platform pemasangan.

    Contoh serangan: serangan SolarWinds, di mana pemasangan pintu belakang ke dalam produk SolarWinds Orion telah dipastikan semasa peringkat pemasangan.

    Kaedah perlindungan yang dicadangkan: pelaksanaan langkah keselamatan lanjutan untuk platform pemasangan.

  • E. Promosi kod berniat jahat melalui kebergantungan berkualiti rendah.

    Contoh serangan: pengenalan pintu belakang ke dalam perpustakaan aliran acara popular dengan menambahkan kebergantungan yang tidak berbahaya dan kemudian memasukkan kod hasad dalam salah satu kemas kini kebergantungan ini (perubahan hasad tidak ditunjukkan dalam repositori git, tetapi telah hadir hanya dalam pakej MNP siap).

    Kaedah perlindungan yang dicadangkan: gunakan keperluan SLSA secara rekursif kepada semua kebergantungan (dalam kes aliran peristiwa, semakan akan mendedahkan pemasangan kod yang tidak sepadan dengan kandungan repositori Git utama).

  • F. Memuat naik artifak yang tidak dicipta dalam sistem CI/CD.

    Contoh serangan: menambahkan kod hasad pada skrip CodeCov, yang membenarkan penyerang mengekstrak maklumat yang disimpan dalam persekitaran sistem penyepaduan berterusan pelanggan.

    Kaedah perlindungan yang dicadangkan: kawalan ke atas sumber dan integriti artifak (dalam kes CodeCov, boleh didedahkan bahawa skrip Bash Uploader yang dihantar daripada tapak web codecov.io tidak sepadan dengan kod daripada repositori projek).

  • G. Kompromi repositori pakej.

    Contoh serangan: Penyelidik dapat menggunakan cermin beberapa repositori pakej popular untuk mengedarkan pakej berniat jahat melaluinya.

    Kaedah perlindungan yang dicadangkan: Pengesahan bahawa artifak yang diedarkan disusun daripada kod sumber yang diisytiharkan.

  • H. Mengelirukan pengguna untuk memasang pakej yang salah.

    Contoh serangan: menggunakan typosquatting (NPM, RubyGems, PyPI) untuk meletakkan pakej dalam repositori yang serupa secara bertulis kepada aplikasi popular (contohnya, skrip kopi dan bukannya skrip kopi).

Untuk menyekat ancaman yang dibenderakan, SLSA menawarkan satu set pengesyoran, serta alat untuk mengautomasikan penciptaan metadata audit. SLSA meringkaskan kaedah serangan biasa dan memperkenalkan konsep lapisan keselamatan. Setiap peringkat mengenakan keperluan infrastruktur tertentu untuk memastikan integriti artifak yang digunakan dalam pembangunan. Lebih tinggi tahap SLSA yang disokong, lebih banyak perlindungan dilaksanakan dan lebih baik infrastruktur dilindungi daripada serangan biasa.

  • SLSA 1 menghendaki proses binaan diautomatikkan sepenuhnya dan menjana metadata (β€œprovenan”) tentang cara artifak dibina, termasuk maklumat tentang sumber, kebergantungan dan proses binaan (contoh penjana metadata untuk pengauditan disediakan untuk Tindakan GitHub). SLSA 1 tidak termasuk elemen perlindungan terhadap pengubahsuaian yang berniat jahat, sebaliknya hanya mengenal pasti kod dan menyediakan metadata untuk pengurusan kelemahan dan analisis risiko.
  • SLSA 2 - melanjutkan tahap pertama dengan memerlukan penggunaan kawalan versi dan perkhidmatan pemasangan yang menjana metadata yang disahkan. Penggunaan SLSA 2 membolehkan anda mengesan asal usul kod dan menghalang perubahan tanpa kebenaran pada kod dalam kes perkhidmatan binaan yang dipercayai.
  • SLSA 3 - mengesahkan bahawa kod sumber dan platform binaan memenuhi keperluan piawaian yang menjamin keupayaan untuk mengaudit kod dan memastikan integriti metadata yang disediakan. Diandaikan bahawa juruaudit boleh memperakui platform terhadap keperluan piawaian.
  • SLSA 4 ialah tahap tertinggi, menambah tahap sebelumnya dengan keperluan berikut:
    • Semakan mandatori semua perubahan oleh dua pembangun yang berbeza.
    • Semua langkah binaan, kod dan tanggungan mesti diisytiharkan sepenuhnya, semua tanggungan mesti diekstrak dan disahkan secara berasingan, dan proses binaan mesti dilakukan di luar talian.
    • Menggunakan proses binaan boleh berulang membolehkan anda mengulang sendiri proses binaan dan memastikan bahawa boleh laku dibina daripada kod sumber yang disediakan.

    Google mencadangkan SLSA untuk melindungi daripada perubahan berniat jahat semasa pembangunan


    Sumber: opennet.ru

Tambah komen