Mengamankan build

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

  • Mengoptimalkan atau mengaburkan kode: Misalnya, alat open source Google Closure Compiler mengurai dan menganalisis JavaScript, menghapus kode yang mati, dan menulis ulang serta meminimalkan yang tersisa. Contoh ini juga memeriksa kode untuk menemukan kesalahan umum JavaScript.
  • Mengompilasi kode menjadi kode perantara: Misalnya, Anda dapat mengompilasi kode Java ke dalam 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++ ke dalam Shared Library (.so) atau file Windows yang dapat dieksekusi (.exe).
  • Mengemas kode ke dalam format yang dapat didistribusikan atau dapat di-deploy: Contohnya termasuk membuat file Java WAR (.war) dari file class Java, membuat image Docker, atau membuat distribusi yang dibangun Python (.whl).

Bergantung pada bahasa pemrograman yang Anda gunakan dan lingkungan yang di-deploy, build Anda mungkin berisi berbagai kombinasi operasi ini. Misalnya, build dapat mengemas kode Python ke dalam distribusi yang di-build dan menguploadnya ke penyimpanan artefak seperti Artifact Registry atau PyPI sehingga Anda dapat menggunakannya sebagai dependensi di Cloud Functions. Anda juga dapat menyimpan kode Python dalam container dan men-deploy image container ke Cloud Run atau Google Kubernetes Engine.

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

Menggunakan build otomatis

Build otomatis atau build dengan skrip mendefinisikan semua langkah build dalam skrip build atau konfigurasi build, termasuk langkah-langkah untuk mengambil kode sumber dan langkah-langkah untuk membuat 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, menjalankan build di lingkungan yang konsisten dan tepercaya juga penting.

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

  • Mengizinkan build lokal akan memberi cara bagi penyerang dengan intent berbahaya untuk mengubah proses build.
  • Inkonsistensi dalam lingkungan lokal developer dan praktik developer menyulitkan reproduksi 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 merupakan persyaratan untuk SLSA level 1. Selain itu, penggunaan layanan build untuk build, bukan lingkungan developer, untuk build merupakan persyaratan untuk SLSA level 2.

Cloud Build adalah layanan build terkelola di Google Cloud. Tutorial ini menggunakan file konfigurasi build untuk menyediakan 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. Cloud Build juga menyediakan integrasi dengan sistem pengelolaan kode sumber utama seperti GitHub dan Bitbucket.

Membuat provenance build

Build provenance adalah kumpulan data yang dapat diverifikasi tentang suatu build.

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

Membuat provenance build akan membantu Anda:

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

Anda dapat menggunakan mekanisme pemberitahuan dan kebijakan untuk menggunakan data provenance 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 dibangun. Untuk SLSA level 2, data provenance build juga harus:

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

Untuk SLSA level 3, konten provenance juga harus mencakup:

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

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

Menggunakan lingkungan build efemeral

Lingkungan ephemeral adalah lingkungan sementara yang dimaksudkan agar berlaku untuk pemanggilan build tunggal. Setelah build, lingkungan akan dihapus total atau dihapus. Build efemeral memastikan bahwa layanan build dan langkah build dijalankan di lingkungan yang singkat, seperti container atau VM. Layanan build tidak menggunakan kembali lingkungan build yang ada, tetapi menyediakan lingkungan baru untuk setiap build, lalu menghancurkannya setelah proses build selesai.

Lingkungan ephemeral memastikan build yang bersih karena tidak ada file residu atau setelan lingkungan dari build sebelumnya yang dapat mengganggu proses build. Lingkungan non-efemeral memberi peluang bagi penyerang untuk memasukkan file dan konten berbahaya. Lingkungan sementara juga mengurangi overhead pemeliharaan dan mengurangi inkonsistensi dalam lingkungan build.

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

Membatasi akses ke layanan build

Ikuti prinsip keamanan hak istimewa terendah dengan memberikan izin minimum yang diperlukan ke layanan build dan resource build. Anda juga harus menggunakan identitas nonmanusia 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 sebagai gantinya.
  • Gunakan kebijakan organisasi Integrasi yang diizinkan Cloud Build untuk mengontrol layanan eksternal yang diizinkan 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 mengurangi 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 akan membantu mencegah akses tidak sah ke sistem dalam supply chain software dan pemindahan data yang tidak sah.

Hindari menyimpan kredensial hard code secara langsung di kontrol versi atau dalam konfigurasi build Anda. 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 agar menggunakan secret yang disimpan di Secret Manager.

Mengelola dependensi Anda

Integritas aplikasi Anda bergantung pada integritas kode yang Anda kembangkan dan dependensi apa pun yang digunakan. Anda juga perlu mempertimbangkan tempat memublikasikan dependensi, siapa yang memiliki akses untuk membaca dan menulis ke repositori artefak, serta 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 dengan bahasa dan alat umum yang terinstal di dalamnya. 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 buildpack sebagai builder, termasuk buildpack Google Cloud.

Tinjau builder yang Anda gunakan di build Cloud Build, cari tahu siapa yang menyediakannya, dan putuskan 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 bersamaan dan dapat saling memengaruhi, atau build yang tetap ada dan memengaruhi build berikutnya.
  • Build yang menerima parameter pengguna selain titik entri build dan lokasi sumber tingkat atas.
  • Build yang menentukan dependensi dengan rentang atau dependensi yang dapat berubah, (misalnya menggunakan image dengan tag latest). Pendekatan ini menimbulkan risiko bagi build untuk menggunakan versi dependensi yang buruk atau tidak diinginkan.

Praktik berikut membantu mengurangi risiko ini:

  • Jalankan setiap build dalam lingkungan efemeral.
  • 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 menunjuk ke versi artefak yang berbeda di masa mendatang. Untuk mengetahui informasi selengkapnya tentang dependensi, lihat Pengelolaan dependensi.

Mengikuti praktik terbaik untuk membangun container

Tinjau praktik terbaik untuk mem-build container guna mempelajari cara mem-build image container yang lebih andal dan kurang rentan terhadap serangan, termasuk:

  • Mengemas aplikasi tunggal
  • Menangani proses
  • Mengoptimalkan cache build Docker
  • Menghapus alat yang tidak diperlukan dan menjaga gambar Anda sekecil mungkin
  • Memindai kerentanan dengan Artifact Analysis. Anda dapat memindai image yang disimpan di Artifact Registry atau memindainya secara lokal sebelum menyimpannya.
  • Praktik terbaik pemberian tag
  • Pertimbangan keamanan untuk menggunakan gambar publik

Perlindungan Pengiriman Software

Software Delivery Shield adalah solusi keamanan supply chain software menyeluruh yang terkelola sepenuhnya. Solusi ini menyediakan rangkaian kemampuan dan alat yang komprehensif dan modular di seluruh layanan Google Cloud yang dapat digunakan oleh developer, DevOps, dan tim keamanan untuk meningkatkan postur keamanan supply chain software. Halaman ini menampilkan insight keamanan untuk aplikasi yang dibangun di UI Cloud Build di Konsol Google Cloud. Hal ini mencakup:

  • Level SLSA, yang mengidentifikasi tingkat kedewasaan 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. Panduan ini berisi detail seperti ringkasan image yang di-build, lokasi sumber input, toolchain build, langkah-langkah build, dan durasi build.

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

Langkah selanjutnya