Ancaman terhadap supply chain software

Vektor serangan untuk supply chain software adalah berbagai cara di mana seseorang dapat secara sengaja atau tidak sengaja membahayakan software Anda.

Risiko software yang rentan meliputi kebocoran kredensial atau data rahasia, kerusakan data, penginstalan malware, dan pemadaman aplikasi. Masalah-masalah ini mengakibatkan hilangnya waktu, uang, dan kepercayaan pelanggan.

Titik entri untuk ancaman menjangkau seluruh siklus proses software dan dapat berasal di dalam atau di luar organisasi Anda.

Diagram yang menunjukkan titik masuk untuk serangan supply chain software

Legenda diagram mencakup dua kumpulan ancaman:

  • Huruf A hingga H menunjukkan vektor serangan dalam supply chain software yang digambarkan sebagai ancaman ancaman dalam framework Supply chain Levels for Software Artifacts (SLSA).
  • Angka 1 sampai 4 menunjukkan vektor serangan tambahan yang tidak dijelaskan secara langsung oleh framework SLSA.

Software Delivery Shield, solusi keamanan supply chain software yang terkelola sepenuhnya di Google Cloud, menggabungkan praktik terbaik untuk membantu Anda memitigasi kedua rangkaian ancaman.

Sub-bagian dalam dokumen ini menjelaskan ancaman dalam konteks sumber, build, deployment, dan dependensi.

Ancaman sumber

Ancaman ini memengaruhi integritas kode sumber Anda.

  • 1: Tulis kode yang tidak aman. Kurangnya praktik coding yang aman dapat menyebabkan penulisan kode secara tidak sengaja menyebabkan kerentanan. Workstation developer yang tidak aman juga dapat memasukkan kode berbahaya atau tidak aman. Mitigasi mencakup:

    • Menetapkan kebijakan untuk workstation developer. Cloud Workstations menyediakan workstation yang telah dikonfigurasi sebelumnya dan terkelola sepenuhnya yang dapat disesuaikan dengan kebutuhan Anda.
    • Pemindaian kode secara lokal. Cloud Code source Protect (pratinjau pribadi) menyediakan masukan keamanan real-time, termasuk informasi kerentanan dan lisensi untuk dependensi. Developer juga dapat menggunakan On-Demand Scanning API untuk memindai image container guna mendeteksi kerentanan paket OS dan paket bahasa.
    • Edukasi tentang praktik untuk membuat kode lebih aman.
  • A: Mengirim kode buruk ke repositori sumber. Hal ini tidak hanya mencakup kode berbahaya, tetapi juga kode yang secara tidak sengaja menyebabkan kerentanan terhadap serangan seperti pembuatan skrip lintas situs. Mitigasi mencakup:

    • Mewajibkan peninjauan manual untuk perubahan kode sumber.
    • Menggunakan alat pemindaian kode dan analisis lint yang terintegrasi dengan IDE dan sistem kontrol sumber.
  • B: Membobol sistem kontrol sumber. Membatasi akses ke sistem kontrol sumber dan sistem lainnya di pipeline build Anda, serta menggunakan autentikasi multi-faktor akan membantu mengurangi risiko ini.

Saat mengevaluasi integritas sumber, periksa juga skrip dan konfigurasi pendukung yang Anda gunakan untuk mem-build serta men-deploy software. Sertakan modul-modul tersebut dalam sistem kontrol sumber dan proses peninjauan kode, sehingga Anda dapat mengambil risiko dari kerentanan dalam file ini.

Lihat Mengamankan sumber untuk mempelajari lebih lanjut cara melindungi sumber Anda.

Membuat ancaman

Ancaman ini membahayakan software saat Anda mem-build atau mengemasnya, atau mengelabui konsumen software agar menggunakan versi yang buruk.

  • C: Mem-build dengan sumber yang bukan dari sistem kontrol sumber tepercaya. Mitigasi yang membantu mengurangi risiko ini meliputi:
    • Menggunakan layanan build, seperti Cloud Build, yang menghasilkan informasi provenance, sehingga Anda dapat memvalidasi bahwa build Anda menggunakan sumber tepercaya.
    • Menempatkan infrastruktur CI/CD di perimeter jaringan untuk mencegah pemindahan data yang tidak sah dari build Anda. Untuk layanan Google Cloud, gunakan Kontrol Layanan VPC.
    • Menyimpan dan menggunakan salinan dependensi open source tepercaya yang Anda perlukan di penyimpanan artefak pribadi seperti Artifact Registry.
  • D: Membobol sistem build. Mitigasi yang membantu mengurangi risiko ini meliputi:
    • Ikuti prinsip hak istimewa terendah dengan membatasi akses langsung ke sistem build untuk individu yang memerlukannya. Di Google Cloud, Anda dapat memberikan peran standar yang sesuai atau membuat peran khusus.
    • Gunakan layanan build terkelola seperti Cloud Build. Cloud Build menjalankan build ephemeral build dengan menyiapkan lingkungan VM untuk setiap build dan menghancurkannya setelah build.
    • Tempatkan infrastruktur CI/CD di perimeter jaringan untuk mencegah pemindahan data yang tidak sah dari build Anda. Untuk layanan Google Cloud, gunakan Kontrol Layanan VPC.
  • F: Kemas dan publikasikan software yang di-build di luar proses resmi. Sistem build yang membuat dan menandatangani provenance build memungkinkan Anda memvalidasi bahwa software Anda dibuat oleh sistem build tepercaya.
  • G: Mengganggu repositori tempat Anda menyimpan software untuk pengguna internal atau eksternal. Mitigasi yang membantu mengurangi risiko ini meliputi:
    • Menyimpan dan menggunakan salinan dependensi open source tepercaya yang Anda perlukan di penyimpanan artefak pribadi, seperti Artifact Registry.
    • Memvalidasi asal build dan sumber.
    • Membatasi izin upload untuk administrator repositori dan akun non-manusia khusus. Di Google Cloud, akun layanan bertindak atas nama layanan dan aplikasi.

Ancaman deployment dan runtime

  • H: Menyelesaikan dependensi dengan menentukan rentang versi atau tag yang tidak dikaitkan secara permanen ke versi build tertentu dapat menyebabkan beberapa masalah:

    • Build tidak dapat direproduksi karena dependensi yang digunakan build pertama kali dapat berbeda dengan dependensi yang digunakan build untuk eksekusi mendatang dari build yang sama.
    • Dependensi mungkin di-resolve ke versi yang disusupi, atau versi dengan perubahan yang merusak software Anda. Pihak tidak bertanggung jawab dapat memanfaatkan ketidakpastian ini untuk menyebabkan build Anda memilih versi paket mereka, bukan versi yang ingin Anda gunakan. Sejumlah praktik terbaik untuk dependensi dapat membantu mengurangi risiko kebingungan dependensi.
  • 2: Mengganggu proses deployment. Jika Anda menggunakan proses deployment berkelanjutan, mengorbankan proses tersebut dapat menyebabkan perubahan yang tidak diinginkan pada software yang Anda kirimkan kepada pengguna. Anda dapat mengurangi risiko dengan membatasi akses ke layanan deployment dan menguji perubahan di lingkungan praproduksi. Cloud Deploy dapat membantu Anda mengelola proses continuous delivery dan promosi antar-lingkungan.

  • 3: Men-deploy software yang disusupi atau tidak mematuhi kebijakan. Menegakkan kebijakan deployment dapat membantu memitigasi risiko ini. Anda dapat menggunakan Otorisasi Biner untuk memvalidasi bahwa image container mematuhi kriteria kebijakan dan memblokir deployment image container dari sumber yang tidak tepercaya.

  • 4: Kerentanan dan kesalahan konfigurasi dalam menjalankan software.

    • Kerentanan baru ditemukan secara berkala, yang berarti bahwa temuan baru dapat mengubah tingkat risiko keamanan untuk aplikasi Anda dalam produksi.
    • Beberapa konfigurasi meningkatkan risiko akses yang tidak sah, seperti menjalankannya sebagai pengguna root atau mengizinkan eskalasi hak istimewa pada eksekusi penampung.

    Dasbor postur keamanan GKE menampilkan informasi tentang kerentanan OS dan masalah konfigurasi pada workload yang sedang berjalan.

    Di Cloud Run, Anda juga dapat melihat insight keamanan tentang revisi yang di-deploy, termasuk kerentanan yang diketahui dalam image container yang Anda deploy.

Lihat Safeguard build untuk mempelajari lebih lanjut cara melindungi sumber Anda, dan Safeguard deployment untuk mempelajari cara melindungi deployment.

Ancaman ketergantungan

Dependensi mencakup dependensi langsung dalam build Anda serta semua dependensi transitif, pohon rekursif dependensi yang merupakan downstream dari dependensi langsung Anda.

Dalam diagram, E menunjukkan penggunaan dependensi yang buruk dalam build Anda. Dependensi yang buruk dapat mencakup:

  • Setiap software yang diandalkan aplikasi Anda, termasuk komponen yang Anda kembangkan secara internal, software pihak ketiga komersial, dan software open source.
  • Kerentanan yang berasal dari vektor serangan lainnya. Misalnya
    • Penyerang mendapatkan akses ke sistem kontrol sumber Anda dan mengubah versi dependensi yang digunakan project Anda.
    • Build Anda menyertakan komponen yang dikembangkan oleh tim lain di organisasi Anda. Mereka memublikasikan build dan memublikasikan komponen langsung dari lingkungan pengembangan lokalnya dan secara tidak sengaja menimbulkan kerentanan di library yang hanya digunakan secara lokal untuk pengujian dan proses debug.
  • Penghapusan dependensi open source secara sengaja dari repositori publik. Penghapusan ini dapat menyebabkan kerusakan pipeline yang sedang digunakan jika mengambil dependensi langsung dari repositori publik.

Lihat praktik terbaik dependensi untuk mempelajari cara memitigasi risiko.

Memitigasi ancaman

Integritas supply chain Anda secara keseluruhan akan sekuat bagian yang paling rentan. Mengabaikan vektor serangan meningkatkan risiko serangan di bagian supply chain Anda.

Pada saat yang sama, Anda tidak perlu mengubah semuanya sekaligus. Efek kumulatif, yang lebih populer sebagai model keju Swiss, berlaku untuk keamanan supply chain software. Setiap mitigasi yang Anda implementasikan akan mengurangi risiko, dan ketika Anda menggabungkan mitigasi di seluruh supply chain, Anda meningkatkan perlindungan dari berbagai jenis serangan.

  • Evaluasi postur keamanan Anda menggunakan framework dan alat yang membantu Anda mengevaluasi kemampuan organisasi dalam mendeteksi, merespons, dan memulihkan ancaman.
  • Pelajari praktik terbaik untuk melindungi supply chain software Anda, dan produk Google Cloud yang dirancang untuk mendukung praktik tersebut.
  • Gunakan Software Delivery Shield untuk melindungi software Anda di seluruh supply chain software Anda di Google Cloud. Anda dapat menerapkan layanan secara bertahap, berdasarkan prioritas dan infrastruktur yang ada.

Langkah selanjutnya