Menjaga keamanan build

Dokumen ini menjelaskan praktik terbaik untuk melindungi build Anda. Kode build dapat merujuk ke berbagai jenis operasi, seperti:

  • Mengoptimalkan atau meng-obfuscate kode: Misalnya, alat open source Google Closure Compiler mengurai dan menganalisis JavaScript, menghapus kode mati, serta menulis ulang dan meminimalkan kode yang tersisa. Alat ini juga memeriksa kode untuk menemukan kesalahan umum JavaScript.
  • Mengompilasi kode menjadi kode perantara: Misalnya, Anda dapat mengompilasi kode Java menjadi file class Java (.class), atau kode C++ menjadi file objek (.obj).
  • Mengompilasi kode dan menautkan, membuat library atau file yang dapat dieksekusi: Misalnya, mengompilasi kode C++ menjadi Library Bersama (.so) atau file yang dapat dieksekusi Windows (.exe).
  • Memaketkan kode ke dalam format yang dapat didistribusikan atau di-deploy: Contohnya mencakup membuat file WAR Java (.war) dari file class Java, membuat image Docker, atau membuat distribusi buatan Python (.whl).

Bergantung pada bahasa pemrograman yang Anda gunakan dan lingkungan tempat Anda men-deploy, build Anda mungkin berisi kombinasi operasi yang berbeda. Misalnya, build dapat memaketkan kode Python ke dalam distribusi yang dibuat dan menguploadnya ke penyimpanan artefak seperti Artifact Registry atau PyPI sehingga Anda dapat menggunakannya sebagai dependensi dalam fungsi Cloud Run. Anda juga dapat membuat container kode Python dan men-deploy image container ke Cloud Run atau Google Kubernetes Engine.

Praktik dalam dokumen ini berfokus pada pembuatan kode untuk pengemasan atau deployment ke lingkungan runtime, bukan kompilasi kode.

Menggunakan build otomatis

Build otomatis atau build dengan skrip menentukan semua langkah build dalam skrip build atau konfigurasi build, termasuk langkah-langkah untuk mengambil kode sumber dan langkah-langkah untuk mem-build kode. Satu-satunya perintah manual, jika ada, adalah perintah untuk menjalankan build.

Misalnya, skrip build dapat berupa:

  • cloudbuild.yaml Cloud Build.
  • Makefile yang Anda jalankan dengan alat make.
  • File alur kerja GitHub Actions dalam format YAML yang disimpan di direktori .github/workflows/ Anda.

Build otomatis memberikan konsistensi dalam langkah-langkah build. Namun, penting juga untuk menjalankan build dalam lingkungan yang konsisten dan tepercaya.

Meskipun build lokal dapat berguna untuk tujuan proses debug, merilis software dari build lokal dapat menimbulkan banyak masalah keamanan, inkonsistensi, dan ketidakefisienan dalam proses build.

  • Mengizinkan build lokal memberikan cara bagi penyerang dengan niat jahat untuk mengubah proses build.
  • Inkonsistensi dalam lingkungan lokal developer dan praktik developer membuat sulit untuk mereproduksi build dan mendiagnosis masalah build.

Build manual membuat proses menjadi tidak efisien dengan memanfaatkan lebih banyak resource infrastruktur seperti komputasi, penyimpanan, dan jaringan. Dalam persyaratan untuk framework SLSA, build otomatis adalah persyaratan untuk SLSA level 1, dan menggunakan layanan build, bukan lingkungan developer untuk build, adalah persyaratan untuk SLSA level 2.

Cloud Build adalah layanan build terkelola di Google Cloud. Alat ini menggunakan file build config untuk memberikan langkah-langkah build ke Cloud Build. Anda dapat mengonfigurasi build untuk mengambil dependensi, menjalankan pengujian unit, analisis statis, dan pengujian integrasi, serta membuat artefak dengan alat build seperti Docker, Gradle, Maven, Go, dan Python. Cloud Build terintegrasi sepenuhnya dengan layanan CI/CD lainnya di Google Cloud seperti Artifact Registry dan Cloud Deploy, serta lingkungan runtime seperti GKE dan Cloud Run. Layanan ini juga menyediakan integrasi dengan sistem pengelolaan kode sumber utama seperti GitHub dan Bitbucket.

Membuat provenance build

Provenans build adalah kumpulan data yang dapat diverifikasi tentang build.

Metadata provenance mencakup detail seperti ringkasan gambar yang di-build, lokasi sumber input, toolchain build, dan durasi build.

Membuat provenance build membantu Anda untuk:

  • Verifikasi bahwa artefak yang di-build dibuat dari lokasi sumber tepercaya dan oleh sistem build tepercaya.
  • Identifikasi kode yang dimasukkan dari lokasi sumber atau sistem build yang tidak tepercaya.

Anda dapat menggunakan mekanisme pemberitahuan dan kebijakan untuk menggunakan data asal build secara proaktif. Misalnya, Anda dapat membuat kebijakan yang hanya mengizinkan deployment kode yang dibuat dari sumber terverifikasi.

Untuk SLSA level 1, provenance build harus tersedia bagi konsumen artefak yang di-build. Untuk SLSA level 2, data asal build juga harus:

  • Dibuat oleh layanan build atau dapat dibaca langsung dari layanan build.
  • Dapat diverifikasi oleh konsumen untuk keaslian dan integritas. Hal ini harus dilakukan dengan tanda tangan digital yang dihasilkan oleh layanan yang membuat data provenans build.

Untuk SLSA level 3, konten asal juga harus menyertakan:

  • Titik entri definisi build.
  • Semua parameter build berada di bawah kontrol pengguna.

Cloud Build dapat menghasilkan provenance build untuk image container yang memberikan jaminan build SLSA level 3. Untuk mengetahui informasi selengkapnya, lihat Melihat asal build.

Menggunakan lingkungan build sementara

Lingkungan sementara adalah lingkungan sementara yang dimaksudkan untuk berlangsung selama satu pemanggilan build. Setelah build, lingkungan akan dihapus total atau dihapus. Build sementara memastikan bahwa layanan build dan langkah build berjalan di lingkungan sementara, seperti penampung atau VM. Daripada menggunakan kembali lingkungan build yang ada, layanan build menyediakan lingkungan baru untuk setiap build, lalu menghancurkannya setelah proses build selesai.

Lingkungan sementara memastikan build yang bersih karena tidak ada file residual atau setelan lingkungan dari build sebelumnya yang dapat mengganggu proses build. Lingkungan yang tidak bersifat sementara memberikan peluang bagi penyerang untuk memasukkan file dan konten berbahaya. Lingkungan sementara juga mengurangi overhead pemeliharaan dan mengurangi inkonsistensi di lingkungan build.

Cloud Build menyiapkan lingkungan virtual machine baru untuk setiap build dan menghancurkannya setelah build.

Membatasi akses ke layanan build

Ikuti prinsip keamanan dengan hak istimewa terendah dengan memberikan izin minimum yang diperlukan ke layanan build dan resource build. Anda juga harus menggunakan identitas non-manusia untuk menjalankan build dan berinteraksi dengan layanan lain atas nama build.

Jika Anda menggunakan Cloud Build:

  • Berikan izin minimum yang diperlukan kepada anggota organisasi Anda.
  • Sesuaikan izin untuk akun layanan yang bertindak atas nama Cloud Build sehingga hanya memiliki izin yang diperlukan untuk penggunaan Anda. Edit izin akun layanan Cloud Build default, atau pertimbangkan untuk menggunakan akun layanan kustom.
  • Gunakan kebijakan organisasi Integrasi yang diizinkan Cloud Build untuk mengontrol layanan eksternal yang diizinkan untuk memanggil pemicu build.

  • Tempatkan Cloud Build di perimeter layanan menggunakan Kontrol Layanan VPC. Perimeter memungkinkan komunikasi bebas antara layanan Google Cloud dalam perimeter, tetapi membatasi komunikasi di seluruh perimeter berdasarkan aturan yang Anda tentukan. Perimeter juga memitigasi risiko pemindahan data yang tidak sah.

    Cloud Build hanya mendukung Kontrol Layanan VPC untuk build yang Anda jalankan di kumpulan pribadi.

Melindungi kredensial

Build sering kali menyertakan koneksi ke sistem lain seperti kontrol versi, penyimpanan artefak, dan lingkungan deployment. Melindungi kredensial yang Anda gunakan dalam build membantu mencegah akses tidak sah ke sistem dalam supply chain software dan pemindahan data secara tidak sah.

Hindari menyimpan kredensial hardcode langsung di kontrol versi atau dalam konfigurasi build Anda. Sebagai gantinya, simpan kredensial di keystore yang aman.

Di Google Cloud, Secret Manager menyimpan kunci API, sandi, dan data sensitif lainnya dengan aman. Anda dapat mengonfigurasi Cloud Build untuk menggunakan secret yang disimpan di Secret Manager.

Mengelola dependensi

Integritas aplikasi Anda bergantung pada integritas kode yang Anda kembangkan dan dependensi apa pun yang Anda gunakan. Anda juga perlu mempertimbangkan tempat memublikasikan dependensi, siapa yang memiliki akses untuk membaca dan menulis ke repositori artefak, dan kebijakan untuk sumber artefak build tepercaya yang Anda deploy ke lingkungan runtime.

Untuk mempelajari pengelolaan dependensi lebih lanjut, lihat Mengelola dependensi.

Di Cloud Build, Anda menggunakan cloud builder untuk menjalankan perintah. Builder adalah image container yang di dalamnya telah terinstal bahasa dan alat yang umum. Anda dapat menggunakan image container publik dari registry publik seperti Docker Hub, builder yang disediakan oleh Cloud Build, builder kontribusi komunitas, dan builder kustom yang Anda buat. Anda juga dapat menggunakan buildpacks sebagai builder, termasuk buildpack Google Cloud.

Tinjau builder yang Anda gunakan dalam build Cloud Build, cari tahu siapa yang menyediakannya, dan tentukan apakah Anda memercayainya dalam supply chain software Anda. Untuk mempertahankan kontrol yang lebih besar atas kode dalam builder, Anda dapat membuat builder kustom, bukan menggunakan builder dari sumber publik.

Mengurangi peluang untuk mengubah build

Ada berbagai faktor lain yang dapat memengaruhi build, termasuk:

  • Build yang berjalan secara serentak dan dapat memengaruhi satu sama lain, atau build yang tetap ada dan memengaruhi build berikutnya.
  • Build yang menerima parameter pengguna selain titik entri build dan lokasi sumber tingkat teratas.
  • Build yang menentukan dependensi dengan rentang atau dependensi yang dapat diubah, (misalnya menggunakan image dengan tag latest). Pendekatan ini menimbulkan risiko bagi build untuk menggunakan versi dependensi yang buruk atau tidak diinginkan.

Praktik berikut membantu memitigasi risiko ini:

  • Jalankan setiap build di lingkungan sementara.
  • Hindari menjalankan build dengan parameter tambahan sehingga pengguna tidak dapat memengaruhi variabel yang ditentukan dalam skrip build.
  • Membatasi akses ke layanan build dan resource build.
  • Mereferensikan versi dependensi yang tidak dapat diubah, bukan ID seperti tag yang dapat mengarah ke versi artefak yang berbeda pada masa mendatang. Untuk mengetahui informasi dependensi selengkapnya, lihat Pengelolaan dependensi.

Keamanan supply chain software

Google Cloud menyediakan serangkaian kemampuan dan alat modular yang dapat Anda gunakan untuk meningkatkan postur keamanan supply chain software Anda. Panel ini menampilkan insight keamanan untuk aplikasi yang di-build oleh Cloud Build. Hal ini mencakup:

  • Tingkat SLSA, yang mengidentifikasi tingkat kematangan keamanan supply chain software Anda.
  • Kerentanan, software bill of materials (SBOM), dan pernyataan Vulnerability Exploitability eXchange (VEX) untuk artefak build.
  • Build provenance, yang merupakan kumpulan metadata yang dapat diverifikasi tentang build. Laporan ini mencakup detail seperti ringkasan gambar yang di-build, lokasi sumber input, toolchain build, langkah-langkah build, dan durasi build.

Untuk petunjuk tentang cara melihat insight keamanan untuk aplikasi yang di-build, lihat Mem-build aplikasi dan melihat insight keamanan.

Langkah selanjutnya