Ancaman terhadap supply chain software

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

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

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

Titik entri untuk serangan supply chain software

Legenda diagram mencakup dua kumpulan ancaman:

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

Google Cloud menyediakan serangkaian kemampuan dan alat modular yang menggabungkan praktik terbaik untuk mengurangi kedua kumpulan ancaman tersebut.

Subbagian dalam dokumen ini menjelaskan ancaman dalam konteks sumber, build, deployment, dan dependensi.

Ancaman sumber

Ancaman ini memengaruhi integritas kode sumber Anda.

  • 1: Menulis kode yang tidak aman. Kurangnya praktik coding yang aman dapat menyebabkan penulisan kode yang secara tidak sengaja menyertakan 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 terkelola sepenuhnya dan telah dikonfigurasi sebelumnya yang dapat Anda sesuaikan agar sesuai dengan persyaratan Anda.
    • Pemindaian kode secara lokal. Perlindungan sumber Cloud Code (pratinjau pribadi) memberikan masukan keamanan secara real time, termasuk informasi kerentanan dan lisensi untuk dependensi. Developer juga dapat menggunakan On-Demand Scanning API untuk memindai image container guna mendeteksi kerentanan 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 cross-site scripting. Mitigasi mencakup:

    • Mewajibkan peninjauan manual untuk perubahan pada kode sumber.
    • Menggunakan alat pemindaian kode dan linting 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 dan men-deploy software. Sertakan file tersebut dalam sistem kontrol sumber dan proses peninjauan kode, sehingga Anda dapat mengurangi risiko dari kerentanan dalam file ini.

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

Membangun ancaman

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

  • C: Mem-build dengan sumber yang bukan dari sistem kontrol sumber tepercaya. Mitigasi yang membantu mengurangi risiko ini mencakup:
    • Menggunakan layanan build, seperti Cloud Build, yang menghasilkan informasi asal 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 tepercaya dependensi open source 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 kustom.
    • Gunakan layanan build terkelola seperti Cloud Build. Cloud Build menjalankan build sementara dengan menyiapkan lingkungan VM untuk setiap build dan menghancurkannya setelah build.
    • Tempatkan infrastruktur CI/CD Anda di perimeter jaringan untuk mencegah pemindahan data yang tidak sah dari build Anda. Untuk layanan Google Cloud, gunakan Kontrol Layanan VPC.
  • F: Memaketkan dan memublikasikan software yang dibuat di luar proses resmi. Sistem build yang membuat dan menandatangani provenance build memungkinkan Anda memvalidasi bahwa software Anda di-build oleh sistem build tepercaya.
  • G: Mengkompromikan repositori tempat Anda menyimpan software untuk pengguna internal atau eksternal. Mitigasi yang membantu mengurangi risiko ini meliputi:
    • Menyimpan dan menggunakan salinan tepercaya dependensi open source yang Anda perlukan di penyimpanan artefak pribadi seperti Artifact Registry.
    • Memvalidasi asal build dan sumber.
    • Membatasi izin upload ke akun non-manusia khusus dan administrator repositori. Di Google Cloud, akun layanan bertindak atas nama layanan dan aplikasi.

Ancaman deployment dan runtime

  • H: Me-resolve dependensi dengan menentukan rentang versi atau tag yang tidak terpasang secara permanen ke versi build tertentu dapat menyebabkan beberapa masalah:

    • Build tidak dapat direproduksi karena dependensi yang digunakan build untuk pertama kalinya dapat berbeda dengan dependensi yang digunakan build untuk eksekusi build yang sama pada masa mendatang.
    • Dependensi mungkin me-resolve ke versi yang disusupi, atau versi dengan perubahan yang merusak software Anda. Pelaku kejahatan 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, tindakan yang membahayakan proses tersebut dapat menyebabkan perubahan yang tidak diinginkan pada software yang Anda kirimkan kepada pengguna. Anda dapat memitigasi risiko dengan membatasi akses ke layanan deployment dan menguji perubahan di lingkungan pra-produksi. Cloud Deploy dapat membantu Anda mengelola proses pengiriman berkelanjutan dan promosi antar-lingkungan.

  • 3: Men-deploy software yang disusupi atau tidak mematuhi kebijakan. Menerapkan 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 rutin, yang berarti bahwa temuan baru dapat mengubah tingkat risiko keamanan untuk aplikasi Anda dalam produksi.
    • Beberapa konfigurasi meningkatkan risiko akses tidak sah, seperti berjalan sebagai pengguna root atau mengizinkan eskalasi hak istimewa saat menjalankan penampung.

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

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

Lihat Menjaga keamanan build untuk mempelajari lebih lanjut cara melindungi sumber, dan Menjaga keamanan deployment untuk mempelajari cara melindungi deployment.

Ancaman dependensi

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

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

  • Semua software yang menjadi dependensi aplikasi Anda, termasuk komponen yang Anda kembangkan secara internal, software pihak ketiga komersial, software open source.
  • Kerentanan yang berasal dari vektor serangan lainnya. Contoh:
    • 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 mem-build dan memublikasikan komponen langsung dari lingkungan pengembangan lokal dan tidak sengaja memasukkan kerentanan dalam library yang hanya mereka gunakan secara lokal untuk pengujian dan proses debug.
  • Penghapusan dependensi open source secara sengaja dari repositori publik. Penghapusan ini dapat menyebabkan pipeline yang digunakan rusak jika mengambil dependensi langsung dari repositori publik.

Lihat praktik terbaik untuk dependensi guna mempelajari cara untuk mengurangi risiko.

Memitigasi ancaman

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

Namun, Anda tidak perlu mengubah semuanya sekaligus. Efek tindakan kumulatif, yang lebih dikenal sebagai model keju swiss, berlaku untuk keamanan supply chain software. Setiap mitigasi yang Anda terapkan akan mengurangi risiko, dan saat menggabungkan mitigasi di seluruh supply chain, Anda akan meningkatkan perlindungan terhadap berbagai jenis serangan.

  • Nilai postur keamanan Anda menggunakan framework dan alat yang membantu Anda mengevaluasi kemampuan organisasi untuk mendeteksi, merespons, dan memulihkan ancaman.
  • Pelajari praktik terbaik untuk melindungi supply chain software Anda, dan produk Google Cloud yang dirancang untuk mendukung praktik tersebut.
  • Gabungkan fitur keamanan Google Cloud ke dalam proses pengembangan, build, dan deployment untuk meningkatkan postur keamanan supply chain software Anda. Anda dapat menerapkan layanan secara bertahap, berdasarkan prioritas dan infrastruktur yang ada.

Langkah selanjutnya