Mengamankan sumber

Dokumen ini menjelaskan praktik terbaik untuk mengelola kode sumber software.

Langkah mendasar yang dilakukan tim software untuk mengelola sumber adalah mengadopsi sistem kontrol versi (VCS). Sistem kontrol versi menyediakan histori dan kemampuan untuk diaudit untuk perubahan. Sistem kontrol versi yang dihosting seperti GitHub memberikan manfaat tambahan seperti ketersediaan, stabilitas, kontrol keamanan, alat peninjauan kode yang terintegrasi, dan integrasi dengan layanan cloud lainnya.

Meskipun sebagian besar tim menggunakan kontrol versi saat ini, ada banyak cara untuk mengonfigurasi sistem kontrol versi dan integrasinya dengan bagian lain dari pipeline CI/CD.

Dokumen ini mempelajari pertimbangan keamanan supply chain software untuk mengonfigurasi sistem kontrol versi. Panduan ini menjelaskan praktik terbaik dari Supply chain Levels for Software Artifacts, sebuah framework untuk mengamankan supply chain software Anda. Framework ini menyertakan persyaratan di beberapa level untuk membantu Anda mengimplementasikan perubahan secara inkremental, termasuk persyaratan sumber.

Sistem kontrol versi dengan histori perubahan dan revisi yang tidak dapat diubah adalah persyaratan SLSA level 2. Sebaiknya lakukan penyelarasan dengan SLSA level 2 sebagai level dasar pengukuran awal untuk supply chain software Anda.

Pada SLSA level 3, platform sumber dan build mematuhi persyaratan keamanan yang lebih kuat, termasuk kebijakan retensi sumber dan histori sumber terverifikasi. SLSA level 4 menambahkan ulasan dua orang ke persyaratan sumber.

Menggunakan kontrol versi untuk hal selain sumber aplikasi Anda

Menyimpan sumber aplikasi dalam kontrol versi adalah praktik yang sudah umum jika peninjauan dan audit historis diperlukan. Namun, ada jenis sumber lain yang juga mendapatkan manfaat dari kontrol versi, termasuk konfigurasi, kebijakan, dan data. Hal ini mencakup file yang:

  • Memengaruhi ketersediaan dan keamanan infrastruktur komputasi Anda
  • Perlu kolaborasi untuk menyelesaikan
  • Memerlukan proses persetujuan yang dapat diulang
  • Mewajibkan histori perubahan

Berikut beberapa contohnya:

  • Infrastruktur sebagai kode: Organisasi yang ingin mengelola infrastruktur dengan cara yang skalabel dan aman menggunakan infrastruktur sebagai kode sebagai metodologi kunci. Misalnya, Anda dapat menyimpan modul Terraform dalam kontrol versi yang membuat repositori Artifact Registry.
  • Manajemen konfigurasi: Pengelolaan konfigurasi mirip dengan infrastruktur sebagai kode, tetapi berfokus pada pengelolaan konfigurasi aplikasi dengan alat seperti Ansible, Puppet, dan Chef. Anda menyimpan dan mengelola file konfigurasi aplikasi di sistem kontrol versi.
  • Konfigurasi database dan skrip migrasi: Simpan konfigurasi dan skrip untuk database produk dan database analisis atau logging Anda.
  • Notebook Jupyter: Ada berbagai cara untuk menggunakan notebook yang disimpan di GitHub, termasuk [ekstensi untuk JupyterLab][jlab], Colaboratory, dan [Vertex AI Workbench][vertex]
  • Kebijakan keamanan: Menyimpan file kebijakan untuk penegakan kebijakan otomatis. Misalnya, Anda dapat menyimpan kebijakan Gatekeeper yang mengizinkan atau menolak perilaku deployment di GKE atau kebijakan Sentinel yang mencegah Terraform menyediakan infrastruktur yang melanggar kebijakan.

Kontrol versi adalah salah satu kemampuan teknis yang diidentifikasi oleh riset DevOps DORA yang mendorong performa pengiriman software dan organisasi yang lebih tinggi. Menyimpan skrip, kode sumber, dan file konfigurasi di kontrol versi membantu Anda mereproduksi dan memulihkan lingkungan, melacak dan mengaudit perubahan, serta merespons kerusakan dengan cepat.

Konfigurasi repositori

Repositori adalah unit logis dasar untuk mengatur kode serta peran, izin, integrasi, dan persetujuan terkait.

Masalah yang dapat terjadi dengan konfigurasi repositori meliputi:

  • Konfigurasi repositori tidak terstandardisasi, sehingga sulit untuk memastikan bahwa keamanan repositori sesuai dengan aplikasi yang diwakilinya, terutama dalam skenario umum ketika sebuah organisasi memiliki ratusan atau ribuan repositori.
  • Siapa pun yang membuat repositori akan menjadi pemilik dengan izin administratif penuh, termasuk kemampuan untuk melakukan penggabungan tanpa peninjau lain.
  • Mengintegrasikan repositori dengan analisis kode, server build, issue tracker, layanan notifikasi, dan bagian lain dari infrastruktur CI/CD dapat menjadi pekerjaan yang cukup berat. Memiliki cara standar untuk membuat dan menyiapkan repositori akan menghemat pekerjaan berulang dan mendukung praktik terbaik.

Untuk mengatasi masalah ini, praktik terbaik mencakup

  • Siapkan repositori dengan proses otomatis, dapat diulang, dan sadar keamanan. Misalnya, Anda dapat menyiapkan modul Terraform yang menyertakan persyaratan keamanan aplikasi yang menjadi tujuan repositori. Aplikasi dengan keamanan tinggi memerlukan pemberi persetujuan penggabungan yang lebih banyak dan berbeda daripada aplikasi dengan keamanan lebih rendah.
  • Buat cara bagi administrator repositori untuk memilih dari serangkaian template konfigurasi repositori yang mendorong penyiapan repositori baru, bukan mengonfigurasi setiap repositori dari awal. Template ini harus mencerminkan berbagai tingkat keamanan aplikasi Anda, dan disinkronkan dengan identitas pengguna yang diperlukan untuk setiap tingkat keamanan. Dalam praktiknya, hal ini biasanya berarti menggunakan sistem kontrol akses dan identitas (IAM) hierarkis yang mencerminkan aplikasi dan infrastruktur di organisasi Anda serta pengguna yang bertanggung jawab atas aplikasi dan infrastruktur tersebut.
  • Mewajibkan pengelolaan identitas terpusat dengan autentikasi multi-faktor untuk pengguna repositori.
    • Pengelolaan identitas terpusat memastikan bahwa saat pengguna meninggalkan organisasi atau pindah ke tim baru, Anda mempertahankan hak istimewa terendah seputar pengelolaan sumber.
    • Autentikasi multi-faktor secara signifikan mengurangi risiko phishing dan jenis serangan lainnya terhadap sumber Anda. Autentikasi 2 langkah adalah salah satu persyaratan SLSA level 4 untuk pemberi persetujuan kode.
  • Membatasi pemilik repositori ke sejumlah kecil karyawan tepercaya. Hal ini mungkin memerlukan integrasi kontrol versi dengan sistem pengelolaan identitas dan memindahkan kemampuan untuk menetapkan kebijakan yang lebih tinggi dalam organisasi. Jika memungkinkan, hapus kemampuan pemilik repositori untuk melakukan penggabungan tanpa peninjau kedua.

Peninjauan kode

Peninjauan kode adalah cara utama bagi organisasi untuk menjaga kualitas dan keamanan software mereka. Peninjauan kode mencoba mengatasi berbagai mode kegagalan seperti:

  • Pengenalan kode dengan cacat software atau desain yang tidak fleksibel.
  • API yang tidak didefinisikan dengan baik
  • Pengenalan masalah keamanan karena kode tidak aman yang ditulis oleh developer
  • Masalah keamanan akibat penambahan library pihak ketiga yang tidak aman atau dapat menjadi tidak aman.

Beberapa cara untuk memitigasi risiko antara lain:

  • Implementasikan otomatisasi pengujian di sepanjang siklus proses software. Pengujian otomatis yang terpicu saat Anda meng-commit sumber ke sistem kontrol versi adalah cara bagi developer untuk mendapatkan masukan dengan cepat terkait masalah yang ditemukan oleh pengujian.
  • Pastikan jumlah dan identitas peninjau sesuai dengan tingkat keamanan aplikasi. Misalnya, aplikasi intranet dengan penggunaan rendah akan memiliki persyaratan keamanan yang lebih rendah daripada aplikasi penting bisnis yang ditujukan kepada publik.
  • Tetapkan peninjau berdasarkan keahlian teknis dan tingkat kepercayaan yang diperlukan untuk perubahan dalam commit. Peninjau harus menguasai bahasa yang sedang ditinjau, sistem yang berinteraksi dengan kode, dan risiko keamanan dalam kelas aplikasi ini. Persyaratan keahlian teknis memiliki banyak dimensi. Contoh:
    • Apakah kodenya dapat dibaca?
    • Apakah aman?
    • Apakah menggunakan library pihak ketiga yang sesuai?
    • Apakah terdapat proses pengamanan library pihak ketiga?
    • Apakah kodenya dapat dikomposisi?
    • Apakah desain API mengikuti praktik terbaik?

  • Ulasan tidak boleh berupa langkah birokratis, tetapi percakapan berkelanjutan terkait praktik terbaik. Buat checklist, panduan gaya, dan standar desain di setiap bagian technology stack Anda, beserta program edukasi untuk developer baru. Beberapa IDE seperti VS Code dan IntelliJ menyediakan linter yang dapat otomatis menandai error terprogram atau gaya. Linter membantu developer membuat kode yang lebih konsisten dan memungkinkan peninjau kode lebih berfokus pada masalah yang tidak mudah diidentifikasi dengan pemeriksaan otomatis.

    Developing Secure Software adalah kursus online gratis yang dibuat oleh Open Source Security Foundation (OpenSSF). Panduan ini menjelaskan praktik dasar pengembangan software dalam konteks keamanan supply chain software.

  • Melakukan peninjauan kode dengan permintaan pull cabang fitur segera setelah setiap developer siap. Jangan menunggu tepat sebelum rilis baru diuji untuk melakukan pemeriksaan keamanan dan peninjauan kode.

  • Mengintegrasikan pemindaian kerentanan, termasuk pemindaian untuk library pihak ketiga, ke dalam permintaan pull dan IDE akan membantu mengidentifikasi masalah sesegera mungkin. On-Demand Scanning API di Google Cloud memungkinkan Anda memindai container secara lokal untuk mencari kerentanan.

  • Integrasikan pengujian otomatis pra-penggabungan sehingga developer dapat mengidentifikasi dan memperbaiki perubahan yang akan merusak aplikasi. Pelajari otomatisasi pengujian lebih lanjut.

Menggabungkan persetujuan

Dalam pipeline CI/CD yang terintegrasi secara berkelanjutan, penggabungan kode ke cabang produksi dapat menyebabkan perubahan downstream, termasuk build dan peluncuran otomatis. Karena alasan ini, mengamankan siapa yang dapat menggabungkan adalah bagian penting dalam mengamankan deployment software. Pertimbangannya meliputi:

  • Siapkan pemilik cabang yang dilindungi di cabang produksi Anda. Jumlah dan identitas yang diizinkan untuk digabungkan harus sesuai dengan persyaratan keamanan aplikasi. SLSA level 4 memerlukan dua pemberi persetujuan yang sangat diautentikasi, tetapi jumlah pemberi persetujuan harus sesuai dengan konten repositori.
  • Kontrol identitas pemilik repositori dengan ketat karena di sebagian besar sistem kontrol versi, mereka dapat melakukan penggabungan sendiri.
  • Pisahkan proses persetujuan penggabungan dan deployment untuk peluncuran multi-repositori dan multi-artefak.

Alat untuk mengamankan pengembangan

Software Delivery Shield adalah solusi keamanan supply chain software menyeluruh yang terkelola sepenuhnya. Solusi ini menyediakan serangkaian kemampuan dan alat yang komprehensif serta modular di seluruh layanan Google Cloud yang dapat digunakan oleh developer, DevOps, dan tim keamanan untuk meningkatkan postur keamanan supply chain software. Komponen Perlindungan Pengiriman Software berikut membantu melindungi kode sumber software:

  • Cloud Workstations (Pratinjau)

    Cloud Workstations menyediakan lingkungan pengembangan yang terkelola sepenuhnya di Google Cloud. Dengan API ini, admin IT dan keamanan dapat dengan mudah menyediakan, menskalakan, mengelola, dan mengamankan lingkungan pengembangan mereka, serta memungkinkan developer mengakses lingkungan pengembangan dengan konfigurasi yang konsisten dan alat yang dapat disesuaikan.

    Cloud Workstations membantu mengubah keamanan dengan meningkatkan postur keamanan lingkungan pengembangan aplikasi Anda. Layanan ini memiliki fitur keamanan seperti VPC Service Controls, traffic masuk atau keluar pribadi, update image paksa, dan kebijakan akses Identity and Access Management. Untuk informasi selengkapnya, lihat dokumentasi Cloud Workstations.

  • Perlindungan sumber Cloud Code (Pratinjau)

    Cloud Code menyediakan dukungan IDE untuk membuat, men-deploy, dan mengintegrasikan aplikasi dengan Google Cloud. Library ini memungkinkan developer membuat dan menyesuaikan aplikasi baru dari contoh template dan menjalankan aplikasi yang sudah selesai. Cloud Code source melindungi memberi developer masukan keamanan real-time, seperti identifikasi dependensi yang rentan dan pelaporan lisensi, saat mereka bekerja di IDE. Alat ini memberikan masukan cepat dan dapat ditindaklanjuti yang memungkinkan developer memperbaiki kode mereka di awal proses pengembangan software.

    Ketersediaan fitur: Cloud Code source Protect tidak tersedia untuk akses publik. Untuk mendapatkan akses ke fitur ini, lihat halaman permintaan akses.

Langkah selanjutnya