Mengirim software dengan aman

Kecepatan dan waktu penyiapan produk adalah prioritas utama bagi organisasi di mana pun yang membangun software dan aplikasi untuk memenuhi kebutuhan pelanggan mereka. Keharusan strategis ini telah menjadi kekuatan pendorong di balik pertumbuhan container yang luar biasa sebagai platform pilihan. Dalam setahun terakhir, setelah menuai keuntungan dari container, yang mencakup waktu penyiapan produk yang lebih cepat, ketersediaan yang lebih tinggi, keamanan yang ditingkatkan, skalabilitas yang lebih baik, dan biaya yang lebih rendah, banyak dari organisasi ini juga mulai memikirkan pendekatan tanpa server.

Meskipun solusi software telah mengurangi waktu yang diperlukan untuk menghadirkan fitur baru atau bahkan produk baru, banyak dari praktik keamanan yang ada tidak dapat mengimbangi peningkatan kecepatan, sehingga menyebabkan salah satu dari tiga masalah:

1. Developer diperlambat oleh proses yang ada, sehingga menyebabkan penundaan
2. Tim keamanan dan operasi menurunkan standar yang membuat organisasi terpapar ancaman
3. Tim pengembangan mengakali proses keamanan yang ada untuk memenuhi tenggat, sehingga membuat keamanan menjadi rentan

Dalam beberapa tahun terakhir telah terjadi banyak pelanggaran keamanan yang diklasifikasikan sebagai serangan "supply chain software".

Log4Shell adalah kerentanan berbahaya dalam software Apache Log4j yang teridentifikasi pada Desember 2021. Kerentanan ini, yang ditandai dengan skor CVSS maksimum 10, bersifat sangat merusak. Ini disebabkan oleh populernya Log4j sebagai framework logging berbasis Java. Ada dua hal yang berkontribusi pada keparahan ini: pertama, kerentanan ini sangat mudah dieksploitasi dan kodenya dapat dieksekusi sepenuhnya dari jarak jauh. Kedua, lapisannya sering kali berada terlalu dalam pada hierarki dependensi sehingga mudah terlewatkan.

Solarwinds, sebuah perusahaan software manajemen IT, diserang oleh pelaku sabotase teknologi dari suatu negara yang menginjeksikan kode berbahaya ke build resmi software open-source yang digunakan perusahaan tersebut. Update berbahaya ini dikirimkan ke 18.000 pelanggan, termasuk Departemen Keuangan dan Perdagangan Amerika Serikat.

Kaseya, penyedia software manajemen IT lainnya, diserang melalui kerentanan zero-day yang membahayakan server Kaseya VSA, dan mentransfer skrip berbahaya untuk mengirimkan ransomware yang mengenkripsi semua file di sistem yang terpengaruh.

Kebutuhan mendesak untuk menanggapi insiden ini dan insiden serupa lainnya membuat Gedung Putih mengeluarkan Perintah Eksekutif pada Mei 2021 yang mewajibkan organisasi yang terikat kerja sama dengan pemerintah federal untuk mempertahankan standar keamanan software tertentu.

Dalam banyak hal, istilah "supply chain software" sangat tepat. Proses pembuatan supply chain software sangat mirip dengan proses pembuatan mobil.

Produsen mobil memperoleh berbagai suku cadang siap pakai, memproduksi komponen miliknya sendiri, kemudian menyatukan semuanya menggunakan proses yang sangat otomatis. Produsen memastikan keamanan operasinya dengan menetapkan setiap komponen pihak ketiga berasal dari sumber tepercaya. Komponen pihak pertama diuji secara ekstensif untuk memastikan tidak ada masalah keamanan. Terakhir, perakitan dilakukan melalui proses terpercaya yang menghasilkan mobil jadi.

Supply chain software serupa dalam banyak hal. Produsen software memperoleh komponen pihak ketiga, sering kali bersifat open source, yang menjalankan fungsi tertentu dan mengembangkan software-nya sendiri. Software ini adalah kekayaan intelektual inti produsen tersebut. Kode kemudian dijalankan melalui proses build yang menggabungkan komponen-komponen ini menjadi artefak untuk selanjutnya di-deploy ke dalam produksi.

Hanya diperlukan satu mata rantai rentan untuk membobol supply chain software.

Seperti dalam kasus-kasus serangan keamanan yang menggegerkan tahun lalu tersebut, setiap langkah dalam proses dapat memiliki kelemahan yang rentan dieksploitasi oleh penyerang.

Misalnya, paket npm rata-rata memiliki 12 dependensi langsung dan sekitar 300 dependensi tidak langsung. Selain itu, kita tahu bahwa hampir 40% dari semua paket npm yang dipublikasikan bergantung pada kode yang kerentanannya telah diketahui..

Kerentanan tersebut mungkin tidak benar-benar membuat kode menjadi tidak aman. Misalnya, kerentanan mungkin berada di bagian library yang tidak pernah benar-benar digunakan. Namun, tetap saja kerentanan ini harus diperiksa.

Skala masalah ini luar biasa besar. Jika satu saja dari kerentanan ini tidak diperbaiki, akan ada peluang bagi pihak tidak bertanggung jawab untuk mendapatkan akses ke supply chain software Anda.

Di Google, kami telah membuat aplikasi berskala global selama beberapa dekade. Seiring waktu, kami telah menjadikan project internal kami sebagai open source untuk membantu meningkatkan kecepatan developer. Pada saat yang sama, kami mengembangkan berbagai proses internal untuk membantu mengamankan pengalaman software.

Berikut adalah beberapa upaya yang kami lakukan untuk memperkuat supply chain software di mana pun.

• Peningkatan investasi – Pada Agustus 2020, kami mengumumkan akan menginvestasikan $10 miliar dalam lima tahun ke depan untuk memperkuat pengamanan cyber, termasuk memperluas program zero-trust, membantu mengamankan supply chain software, dan meningkatkan keamanan open source.
• Supply-chain Levels for Software Artifacts (SLSA) – SLSA adalah framework end-to-end untuk integritas supply chain. Ini adalah open source yang setara dengan banyak proses yang telah kami terapkan secara internal di Google. SLSA memberikan informasi asal usul yang dapat diaudit terkait apa yang dibuat dan bagaimana prosesnya.
• DevOps Research and Assessment (DORA) – Tim DORA kami melakukan program riset selama tujuh tahun demi memvalidasi sejumlah kemampuan teknis, proses, pengukuran, dan kultural yang mendorong pengiriman software serta performa organisasi yang lebih tinggi.
• Open Source Security Foundation – Pada tahun 2019, kami ikut mendirikan sebuah forum lintas industri terkait keamanan supply chain yang bernama Open Source Security Foundation.
• Allstar – Allstar adalah Aplikasi GitHub yang diinstal pada organisasi atau repositori untuk mengatur dan menerapkan kebijakan keamanan. Hal ini memungkinkan penerapan praktik keamanan terbaik secara berkelanjutan untuk project GitHub.
• Open Source Scorecards – Scorecards menggunakan metrik evaluasi, seperti kebijakan keamanan yang jelas, proses peninjauan kode, serta cakupan pengujian berkelanjutan dengan alat analisis kode fuzzing dan statis, guna memberikan skor risiko bagi berbagai project open source.

Kami percaya ada dua hal yang diperlukan untuk mengatasi masalah keamanan supply chain software:

1. Standar dan framework di seluruh industri
2. Layanan terkelola yang menerapkan standar ini dengan menggunakan prinsip hak istimewa terendah dikenal sebagai arsitektur zero-trust. Dalam arsitektur zero-trust, tidak ada orang, perangkat, atau jaringan yang memiliki kepercayaan bawaan. Sebaliknya, semua kepercayaan, yang memungkinkan akses ke informasi, harus diupayakan.

Mari kita lihat satu per satu:

Dalam kondisinya saat ini, SLSA adalah seperangkat pedoman keamanan yang dapat diadopsi secara bertahap, yang ditetapkan oleh konsensus industri. Dalam bentuk akhirnya, SLSA akan berbeda dari daftar praktik terbaik dalam hal penerapannya. SLSA akan mendukung pembuatan otomatis metadata yang dapat diaudit serta disertakan ke dalam perangkat kebijakan untuk memberikan "sertifikasi SLSA" ke paket atau platform build tertentu.

SLSA dirancang agar bersifat inkremental dan dapat ditindaklanjuti serta memberikan manfaat keamanan di setiap tahap. Setelah artefak memenuhi syarat pada level tertinggi, konsumen dapat merasa yakin bahwa artefak tersebut belum dirusak dan dapat ditelusuri kembali ke sumbernya dengan aman. Ini adalah hal yang sulit, bahkan nyaris tidak mungkin, untuk dilakukan dengan sebagian besar software saat ini.

SLSA terdiri dari empat level, dengan SLSA 4 mewakili kondisi akhir yang ideal. Level-level yang lebih rendah mewakili tonggak pencapaian inkremental untuk tiap jaminan integritas inkremental yang berkaitan. Persyaratannya saat ini didefinisikan sebagai berikut:

SLSA 1 mensyaratkan bahwa proses build sepenuhnya ditulis/diotomatiskan dan menghasilkan provenance. Provenance adalah metadata terkait cara pembuatan artefak, termasuk proses build, sumber tingkat atas, dan dependensi. Dengan mengetahui provenance, konsumen software dapat membuat keputusan keamanan berbasis risiko. Meskipun provenance di SLSA 1 tidak memberikan perlindungan terhadap gangguan, provenance ini menawarkan level dasar identifikasi sumber kode dan dapat membantu dalam mengelola kerentanan.

SLSA 2 memerlukan penggunaan kontrol versi dan layanan build yang dihosting yang menghasilkan provenance yang diautentikasi. Persyaratan tambahan ini membuat konsumen lebih percaya tentang asal-usul software. Pada level ini, provenance mencegah gangguan sejauh layanan build yang digunakan dapat dipercaya. SLSA 2 juga menyediakan jalur upgrade yang mudah ke SLSA 3.

SLSA 3 selanjutnya mensyaratkan bahwa sumber dan platform build harus memenuhi standar tertentu untuk menjamin sumber dan integritas provenance dapat diaudit. SLSA 3 memberikan perlindungan yang jauh lebih kuat terhadap gangguan daripada level sebelumnya dengan mencegah kelas ancaman tertentu, seperti kontaminasi lintas build.

SLSA 4 saat ini merupakan level tertinggi, yang mensyaratkan tinjauan dua orang atas semua perubahan serta proses build yang hermetis dan dapat direproduksi. Tinjauan dua orang adalah praktik terbaik industri untuk menemukan kesalahan dan mencegah perilaku buruk. Build yang hermetis menjamin bahwa daftar dependensi provenance tersebut lengkap. Build yang dapat direproduksi, meskipun tidak wajib, memberikan banyak manfaat dalam hal kemampuan diaudit dan keandalan. Secara keseluruhan, SLSA 4 memberi konsumen tingkat kepercayaan yang tinggi bahwa software belum dirusak. Detail lebih lanjut mengenai level-level yang diusulkan ini dapat ditemukan di repositori GitHub, termasuk persyaratan Sumber dan Build/Provenance yang sesuai untuk tiap level. 

Supply chain software dapat dipecah menjadi lima fase yang berbeda: kode, build, paket, deploy, dan jalankan. Kami akan membahas setiap fase ini dalam kaitannya dengan pendekatan kami terhadap keamanan.

Di Google Cloud, kami menyediakan alat yang terkelola sepenuhnya, mulai dari kode dan build hingga deployment serta pengoperasian, dengan menerapkan standar dan praktik terbaik secara default.

Pengamanan supply chain software Anda memerlukan penetapan, verifikasi, dan pemeliharaan rantai kepercayaan yang menghasilkan provenance kode Anda, serta memastikan bahwa apa yang Anda jalankan dalam produksi sesuai dengan yang diinginkan. Di Google, kami melakukannya melalui pengesahan yang dibuat dan diperiksa di seluruh proses pengembangan dan deployment software, yang memungkinkan tingkat keamanan ambien melalui hal-hal seperti tinjauan kode, provenance kode terverifikasi, dan penegakan kebijakan. Bersama-sama, proses ini membantu kami meminimalkan risiko supply chain software sambil meningkatkan produktivitas developer.

Pada dasarnya, kami memiliki layanan infrastruktur umum yang aman, seperti pengelolaan akses dan identitas serta logging audit. Selanjutnya, kami mengamankan supply chain software Anda sedemikian rupa guna menentukan, memeriksa, dan menerapkan pengesahan di seluruh siklus proses software Anda.

Mari kita pelajari lebih jauh cara mencapai keamanan ambien dalam proses pengembangan melalui kebijakan dan provenance di Google Cloud.

Pengamanan supply chain software Anda dimulai saat developer mulai merancang aplikasi dan menulis kode. Ini termasuk software pihak pertama serta komponen open source, yang masing-masing memiliki tantangannya sendiri.

Software open source dan dependensinya

Open source memberdayakan developer untuk membangun banyak hal dengan lebih cepat agar organisasi bisa lebih gesit dan produktif. Namun, software open source jauh dari sempurna. Meskipun industri kita bergantung pada open source, sering kali kita tidak tahu banyak tentang dependensinya serta berbagai level risiko yang menyertainya. Bagi sebagian besar perusahaan, risiko utamanya berasal dari kerentanan atau lisensi.

Software open source, paket, image dasar, dan artefak lain yang Anda andalkan membentuk fondasi "rantai kepercayaan" Anda.

Misalnya, anggaplah organisasi Anda sedang membangun software “a”. Diagram ini menunjukkan rantai kepercayaan yang terkait, atau dengan kata lain, jumlah dependensi implisit dalam project Anda. Dalam diagram, "b" hingga "h" adalah dependensi langsung, sedangkan "i" hingga "m" adalah dependensi tidak langsung.

Sekarang anggaplah ada kerentanan yang berada jauh di dalam hierarki dependensi. Masalah ini dapat muncul di banyak komponen dengan sangat cepat. Selain itu, dependensi cukup sering berubah: rata-rata dalam satu hari, sebanyak 40.000 npm paket mengalami perubahan pada dependensinya.

Open Source Insights adalah alat yang dibuat oleh Google Cloud yang menyediakan grafik dependensi transitif sehingga Anda dapat melihat satu dependensi dan dependensi selanjutnya, di sepanjang hierarki dependensi. Open Source Insights terus diupdate dengan saran keamanan, informasi lisensi, dan data keamanan lainnya dalam berbagai bahasa, semuanya di satu tempat. Jika digunakan bersama dengan Open Source Scorecards, yang memberikan skor risiko untuk project open source, Open Source Insights membantu developer Anda membuat pilihan yang lebih baik di antara jutaan paket open source yang tersedia.

Untuk mengatasi masalah ini, penting untuk berfokus pada dependensi sebagai kode. Saat bergerak menuju akhir supply chain, dependensi akan lebih sulit untuk diperiksa. Untuk mengamankan dependensi Anda, kami sarankan untuk memulai dengan supply:

• Gunakan alat seperti Open Source Insights dan OSS Scorecards untuk lebih memahami dependensi Anda. 
• Pindai dan verifikasi semua kode, paket, dan image dasar melalui proses otomatis yang merupakan bagian penting dari alur kerja Anda.
• Kontrol bagaimana orang mengakses dependensi ini. Sangat penting untuk mengontrol secara ketat repositori untuk kode open source dan kode pihak pertama, dengan batasan seputar tinjauan kode dan persyaratan audit menyeluruh.

Kami akan membahas proses build dan deployment secara lebih mendetail ke depannya, tetapi penting juga untuk memverifikasi provenance dari build tersebut, memanfaatkan lingkungan build yang aman, dan memastikan bahwa image ditandatangani dan selanjutnya divalidasi pada saat deployment.

Ada juga sejumlah praktik coding yang aman yang dapat diterapkan oleh developer:

• Mengotomatiskan pengujian
• Menggunakan bahasa software yang aman untuk memori 
• Mewajibkan tinjauan kode
• Memastikan keaslian commit
• Mengidentifikasi kode berbahaya sejak dini
• Menghindari pengungkapan informasi sensitif
• Mewajibkan output build dan logging 
• Memanfaatkan pengelolaan lisensi

Langkah selanjutnya dalam mengamankan supply chain software Anda melibatkan pembuatan lingkungan build yang aman dalam skala yang tepat. Proses build pada dasarnya dimulai dengan mengimpor kode sumber Anda dalam, kemungkinan, satu dari banyak bahasa yang berasal dari sebuah repositori, serta menjalankan build untuk memenuhi spesifikasi yang ditetapkan dalam file konfigurasi Anda.

Penyedia cloud, misalnya Google, memberi Anda akses ke lingkungan build terkelola terbaru, sehingga Anda dapat mem-build image pada skala apa pun yang dibutuhkan.

Saat Anda menjalani proses build, ada beberapa hal yang perlu dipertimbangkan:

• Apakah secret Anda aman selama proses build dan seterusnya?
• Siapa yang memiliki akses ke lingkungan build Anda?
• Bagaimana dengan vektor serangan yang relatif baru atau risiko eksfiltrasi?

Untuk mengembangkan lingkungan build yang aman, Anda harus memulai dengan secret. Secret sangat penting dan relatif mudah diamankan. Mulailah dengan memastikan bahwa secret Anda tidak pernah berupa teks biasa dan sejauh mungkin bukan bagian dari build Anda. Anda harus memastikan secret dienkripsi dan build Anda diberi parameter untuk merujuk ke secret eksternal yang akan digunakan sesuai kebutuhan. Langkah ini juga menyederhanakan rotasi secret secara berkala dan meminimalkan dampak kebocoran.

Langkah selanjutnya adalah menyiapkan izin untuk build Anda. Ada berbagai pengguna dan akun layanan yang terlibat dalam proses build Anda. Misalnya, sebagian pengguna mungkin harus dapat mengelola secret, sementara yang lain mungkin perlu mengelola proses build dengan menambahkan atau mengubah langkah-langkah, sedangkan yang lain lagi mungkin hanya perlu melihat log.

Saat Anda melakukan ini, penting untuk mengikuti praktik terbaik berikut:

• Yang paling penting adalah prinsip hak istimewa terendah. Terapkan izin terperinci untuk memberi pengguna dan akun layanan izin yang tepat yang mereka butuhkan untuk melakukan pekerjaan secara efektif.
• Pastikan Anda mengetahui proses interaksi antara pengguna dan akun layanan serta paham benar tentang rantai tanggung jawab, mulai dari menyiapkan build, menjalankannya, hingga efek downstream build tersebut.

Selanjutnya, saat Anda meningkatkan skala proses ini, buat batasan di seputar build Anda sejauh mungkin, lalu gunakan otomatisasi untuk meningkatkan skala melalui konfigurasi sebagai kode dan parameterisasi. Dengan demikian, Anda dapat mengaudit setiap perubahan pada proses build secara efektif. Selain itu, pastikan Anda memenuhi kebutuhan kepatuhan melalui gerbang persetujuan untuk build dan deployment yang sensitif, permintaan pull untuk perubahan infrastruktur, dan peninjauan log audit rutin yang digerakkan oleh manusia.

Terakhir, pastikan jaringan sesuai dengan kebutuhan Anda. Dalam kebanyakan kasus, yang terbaik adalah menghosting kode sumber Anda sendiri di jaringan pribadi di belakang firewall. Google Cloud memberi Anda akses ke fitur seperti Cloud Build Private Pools, yakni lingkungan build tanpa server yang dikunci dalam perimeter jaringan pribadi Anda sendiri, dan fitur seperti Kontrol Layanan VPC untuk mencegah eksfiltrasi kekayaan intelektual Anda.

Otorisasi Biner

Meskipun IAM adalah titik awal logis dan harus dimiliki, framework ini tidaklah sempurna. Kebocoran kredensial merupakan risiko keamanan yang serius. Jadi, untuk mengurangi ketergantungan pada IAM, Anda dapat beralih ke sistem berbasis pengesahan yang tidak terlalu rawan kesalahan. Google menggunakan sistem yang disebut otorisasi biner, yang hanya mengizinkan beban kerja tepercaya untuk di-deploy.

Layanan otorisasi biner menetapkan, memverifikasi, dan memelihara rantai kepercayaan melalui pengesahan dan pemeriksaan kebijakan selama proses berlangsung. Pada dasarnya, otorisasi biner menghasilkan tanda tangan kriptografi, atau pengesahan, saat kode dan artefak lainnya bergerak ke arah produksi. Sebelum deployment, pengesahan ini akan diperiksa berdasarkan kebijakan yang berlaku.

Saat menggunakan Google Cloud Build, serangkaian pengesahan akan diambil dan ditambahkan ke rantai kepercayaan Anda secara keseluruhan. Misalnya, pengesahan dihasilkan untuk menentukan tugas mana yang dijalankan, alat dan proses build apa yang digunakan, dan seterusnya. Khususnya, Cloud Build membantu Anda mencapai SLSA Level 1 dengan merekam sumber konfigurasi build, yang dapat digunakan untuk memvalidasi bahwa build tersebut ditambahkan melalui skrip. Build berskrip lebih aman daripada build manual dan diperlukan untuk SLSA Level 1. Selain itu, provenance build Anda dan pengesahan lainnya dapat dilihat menggunakan ringkasan image container, yang membuat tanda tangan unik untuk image apa pun, dan juga diperlukan untuk SLSA Level 1.

Setelah build selesai, Anda memiliki image container yang hampir siap untuk diproduksi. Sangat penting untuk memiliki lokasi penyimpanan image yang aman guna mencegah perusakan image yang ada dan upload image yang tidak sah. Pengelola paket Anda mungkin perlu memiliki image untuk build pihak pertama maupun build open source serta paket bahasa yang digunakan aplikasi Anda.

Google Cloud Artifact Registry menyediakan repositori tersebut bagi Anda. Artifact Registry adalah satu tempat bagi organisasi Anda untuk mengelola image container serta paket bahasa (seperti Maven dan npm). Artifact Registry sepenuhnya terintegrasi dengan alat dan runtime Google Cloud serta dilengkapi dengan dukungan untuk protokol artefak asli. Hal ini memudahkan pengintegrasian dengan alat CI/CD saat Anda bekerja menyiapkan pipeline otomatis.

Mirip dengan langkah build, izin akses ke Artifact Registry harus direncanakan dengan baik dan mengikuti prinsip hak istimewa terendah. Selain membatasi akses tidak sah, repositori paket dapat memberikan lebih banyak manfaat. Artifact Registry, misalnya, menyertakan pemindaian kerentanan untuk memindai image Anda dan memastikannya aman untuk di-deploy. Layanan ini menggunakan database kerentanan yang terus di-refresh dan diupdate untuk memindai image, guna mengevaluasi adanya ancaman baru dan memberi tahu Anda jika ada kerentanan yang ditemukan.

Langkah ini menghasilkan metadata tambahan, termasuk pengesahan apakah hasil kerentanan artefak memenuhi batas keamanan tertentu atau tidak. Informasi ini kemudian disimpan dalam layanan analisis kami, yang menyusun dan mengatur metadata artefak, sehingga membuatnya mudah diakses oleh otorisasi biner. Anda dapat menggunakan pendekatan ini untuk secara otomatis mencegah image berisiko di-deploy ke Google Kubernetes Engine (GKE).

Dua fase terakhir dari supply chain keamanan software adalah men-deploy dan menjalankan. Meskipun ini adalah dua langkah terpisah, keduanya harus dipertimbangkan secara bersamaan guna memastikan bahwa hanya build resmi yang akan sampai ke tahap produksi.

Di Google, kami telah mengembangkan praktik terbaik untuk menentukan jenis build yang harus diotorisasi. Ini dimulai dengan memastikan integritas supply chain Anda sehingga hanya menghasilkan artefak yang dapat Anda percayai. Selanjutnya, praktik ini mencakup pengelolaan kerentanan sebagai bagian dari siklus proses pengiriman software. Terakhir, kami menggabungkan kedua bagian tersebut untuk menerapkan alur kerja berdasarkan kebijakan untuk pemindaian kerentanan dan integritas.

Saat mencapai tahap ini, Anda telah melalui fase kode, build, dan paket. Pengesahan yang direkam di sepanjang supply chain dapat diverifikasi keasliannya dengan otorisasi biner. Dalam mode penerapan, image di-deploy hanya jika pengesahan memenuhi kebijakan organisasi Anda. Dalam mode audit, pelanggaran kebijakan akan dicatat ke dalam log dan memicu peringatan. Anda juga dapat menggunakan otorisasi biner untuk membatasi build agar tidak dijalankan kecuali build tersebut dibuat menggunakan proses Cloud Build yang disetujui. Otorisasi biner memastikan bahwa hanya kode yang ditinjau dan diotorisasi dengan benar yang dapat di-deploy.

Men-deploy image Anda ke lingkungan runtime tepercaya sangatlah penting. Platform Kubernetes terkelola kami, GKE, menggunakan pendekatan yang mengutamakan keamanan pada container.

GKE menangani sebagian besar masalah keamanan cluster yang perlu Anda perhatikan. Upgrade cluster otomatis dapat digunakan untuk menjaga agar Kubernetes Anda tetap di-patch dan diupdate secara otomatis menggunakan saluran rilis. Booting aman, node berpelindung, dan pemeriksaan integritas memastikan bahwa kernel dan komponen cluster node Anda tidak dimodifikasi dan berjalan sesuai keinginan, serta bahwa node berbahaya tidak dapat bergabung dengan cluster Anda. Terakhir, Confidential Computing dapat Anda gunakan untuk menjalankan cluster dengan node yang memorinya dienkripsi sehingga data dapat tetap dirahasiakan bahkan saat sedang diproses. Jika dikombinasikan dengan enkripsi data ketika dalam penyimpanan dan dalam pengiriman di jaringan, GKE dapat menyediakan lingkungan yang sangat aman, pribadi, dan rahasia untuk menjalankan beban kerja dalam container Anda.

Selain itu, GKE juga memberikan keamanan yang lebih baik bagi aplikasi Anda melalui pengelolaan sertifikat untuk load balancer, Workload Identity, dan kemampuan jaringan tingkat lanjut dengan cara yang andal guna mengonfigurasi serta mengamankan ingress ke dalam cluster Anda. GKE juga menawarkan lingkungan dalam sandbox untuk menjalankan aplikasi yang tidak tepercaya sekaligus melindungi sisa beban kerja Anda.

Dengan GKE Autopilot, fitur dan praktik terbaik keamanan GKE diimplementasikan secara otomatis, sehingga makin mengurangi permukaan serangan (attack surface) dan meminimalkan kesalahan konfigurasi yang dapat menyebabkan masalah keamanan.

Tentu saja, kebutuhan akan verifikasi tidak berhenti pada deployment. Otorisasi biner juga mendukung validasi terus-menerus, sehingga memungkinkan kesesuaian berkelanjutan dengan kebijakan yang ditetapkan bahkan setelah deployment. Jika aplikasi yang sedang berjalan tidak sesuai dengan kebijakan yang ada atau yang baru ditambahkan, peringatan akan dibuat dan dicatat ke dalam log, sehingga meyakinkan Anda bahwa apa yang Anda jalankan dalam produksi persis seperti yang diinginkan.

Pengelolaan kerentanan

Selain memastikan integritas, aspek lain dari keamanan supply chain adalah memastikan bahwa setiap kerentanan ditemukan dengan cepat dan diperbaiki. Penyerang telah berevolusi untuk secara aktif menyusupkan kerentanan ke dalam project upstream. Pengelolaan kerentanan dan deteksi kerusakan harus digunakan di seluruh tahapan siklus proses pengiriman software.

Setelah kode siap untuk deployment, gunakan pipeline CI/CD dan manfaatkan berbagai alat yang tersedia untuk melakukan pemindaian menyeluruh terhadap kode sumber dan artefak yang dihasilkan. Alat-alat ini mencakup penganalisis statis, alat fuzzing, dan berbagai jenis pemindai kerentanan.

Setelah Anda men-deploy beban kerja ke produksi, dan saat beban kerja sedang berjalan dalam tahap produksi serta melayani pengguna, Anda harus memantau ancaman yang muncul dan memiliki rencana untuk mengambil tindakan perbaikan yang cepat.

Kesimpulan

Singkatnya, mengamankan supply chain software dilakukan dengan menerapkan praktik terbaik, seperti SLSA, dan menggunakan layanan terkelola yang tepercaya untuk membantu Anda menerapkan praktik terbaik ini.

Sangat penting untuk:

• Memulai dengan kode dan dependensi Anda serta memastikan Anda dapat mempercayainya.
• Melindungi sistem build Anda dan menggunakan pengesahan untuk memverifikasi bahwa semua langkah build yang diperlukan telah diikuti.
• Memastikan semua paket dan artefak Anda tepercaya dan tidak dapat dirusak.
• Menerapkan kontrol atas siapa yang dapat men-deploy apa dan mempertahankan jejak audit. Gunakan otorisasi biner untuk memvalidasi pengesahan bagi setiap artefak yang ingin di-deploy.
• Menjalankan aplikasi Anda di lingkungan tepercaya dan memastikan tidak ada yang dapat mengganggunya saat sedang berjalan. Awasi setiap kerentanan yang baru ditemukan sehingga Anda dapat melindungi deployment yang ada.

Di Google, kami menerapkan praktik terbaik di setiap tahap perjalanan ini, dan mengintegrasikannya ke dalam portofolio produk kami, sehingga Anda memiliki fondasi tepercaya untuk mem-build aplikasi.

Siap untuk mulai mengamankan supply chain software Anda? Untuk memperjelas, di mana Anda memulai umumnya bersifat pilihan. Tidak ada tindakan tunggal yang dapat mengamankan seluruh supply chain Anda, dan tidak ada satu tindakan yang lebih penting daripada tindakan lainnya dalam memberikan keamanan total bagi supply chain. Meskipun demikian, berikut adalah empat rekomendasi untuk memulai.

1. Terapkan patch pada software

Jika Anda men-deploy kode ke dalam lingkungan produksi yang diketahui memiliki kerentanan, berarti Anda telah membantu penyerang dalam melakukan pembobolan. Jika ini telah terjadi, sia-sia untuk menerapkan keamanan terbaik pada supply chain software Anda karena penyerang sudah mendapatkan jalan masuk. Jadi, menerapkan patch sangatlah penting.

2. Kendalikan apa yang berjalan di lingkungan Anda

Setelah menguasai patching, kuasai pula kontrol atas supply chain software Anda. Ini dimulai dengan kemampuan untuk menegaskan bahwa apa yang Anda jalankan benar-benar berasal dari alat build atau repositori yang tepercaya. Tingkat kontrol tersebut membantu mencegah serangan yang disengaja maupun error yang tidak disengaja, seperti dalam kasus developer yang men-deploy sesuatu tanpa sadar bahwa hal tersebut tidak aman. Ini memberi Anda dasar yang kuat untuk menambahkan alat seperti uji klik dan otorisasi biner. 

3. Pastikan keamanan paket vendor pihak ketiga

Masalah yang muncul dalam keamanan supply chain adalah frekuensi pembobolan software vendor, yang menyediakan saluran bagi ransomware atau akses tidak sah menuju deployment pelanggan target mereka. Paket vendor pihak ketiga yang Anda jalankan di lingkungan Anda, seperti produk manajemen sistem, produk manajemen jaringan, atau produk keamanan, sering kali memiliki tingkat hak istimewa yang tinggi. Anda sebaiknya meminta vendor tersebut untuk menggunakan pernyataan keamanan yang melampaui standar demi memberikan jaminan kuat terkait paket yang Anda gunakan. Anda dapat menanyakan sejauh mana penerapan level SLSA mereka atau tingkat kepatuhan mereka terhadap persyaratan Perintah Eksekutif terbaru.

4. Simpan salinan pribadi dari kode sumber Anda

Jika Anda menggunakan software open source, jangan menggunakan versi yang Anda ambil langsung dari Internet untuk membuat build. Sebaliknya, dapatkan salinan pribadi yang terus-menerus di-patch sehingga Anda memiliki tempat yang aman untuk memulai setiap build dan dapat 100% yakin dari mana kode sumber berasal. 

Praktik terbaik DevOps

1. State of DevOps Report selama enam tahun, sekumpulan artikel berisi informasi mendalam mengenai kemampuan memprediksi performa pengiriman software, dilengkapi pemeriksaan cepat untuk membantu Anda mengetahui performa organisasi Anda dan cara meningkatkannya.
2. Google Cloud 2021 Accelerate State of DevOps Report
3. Laporan resmi Google Cloud: Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale

Mengamankan supply chain software

1. Blog Google Cloud: What is zero trust identity security
2. Blog keamanan Google: Introducing SLSA, an end-to-end framework for supply chain integrity
3. Laporan resmi Google Cloud: Shifting left on security: Securing software supply chains