Mengamankan sumber

Dokumen ini menjelaskan praktik terbaik untuk mengelola kode sumber software.

Langkah mendasar yang dilakukan tim software untuk mengelola sumbernya adalah mengadopsi sistem kontrol versi (VCS). Sistem kontrol versi menyediakan histori dan kemampuan audit untuk perubahan. Sistem kontrol versi yang dihosting seperti GitHub memberikan manfaat tambahan seperti ketersediaan, stabilitas, kontrol keamanan, alat peninjauan kode 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 membahas pertimbangan keamanan supply chain software untuk mengonfigurasi sistem kontrol versi. Dokumen ini menjelaskan praktik terbaik dari Supply-chain Levels for Software Artifacts, framework untuk melindungi supply chain software Anda. Framework ini mencakup persyaratan di beberapa level untuk membantu Anda menerapkan perubahan secara bertahap, termasuk persyaratan sumber.

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

Di SLSA level 3, platform sumber dan build mematuhi persyaratan keamanan yang lebih ketat, termasuk histori sumber yang diverifikasi dan kebijakan penyimpanan sumber. SLSA level 4 menambahkan peninjauan dua orang ke persyaratan sumber.

Menggunakan kontrol versi untuk lebih dari sekadar sumber aplikasi

Menyimpan sumber aplikasi dalam kontrol versi adalah praktik yang sudah mapan 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 apa pun yang:

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

Berikut beberapa contohnya:

  • Infrastructure-as-code: Organisasi yang ingin mengelola infrastruktur mereka dengan cara yang skalabel dan aman menggunakan infrastructure-as-code sebagai metodologi utama. Misalnya, Anda dapat menyimpan modul Terraform dalam kontrol versi yang membuat repositori Artifact Registry.
  • Pengelolaan konfigurasi: Pengelolaan konfigurasi mirip dengan infrastructure-as-code, 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, Colaboratory, dan Vertex AI Workbench
  • Kebijakan keamanan: Simpan 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 DORA DevOps yang mendorong performa organisasi dan pengiriman software yang lebih tinggi. Menyimpan skrip, kode sumber, dan file konfigurasi dalam kontrol versi membantu Anda mereproduksi dan memulihkan lingkungan, melacak dan mengaudit perubahan, serta merespons kerusakan dengan cepat.

Konfigurasi repositori

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

Masalah yang dapat terjadi pada konfigurasi repositori mencakup:

  • Konfigurasi repositori tidak distandardisasi, sehingga sulit untuk memastikan bahwa keamanan repositori sesuai dengan aplikasi yang diwakilinya, terutama dalam skenario umum ketika 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, pelacak masalah, layanan notifikasi, dan bagian lain dari infrastruktur CI/CD dapat menjadi pekerjaan yang cukup besar. Memiliki cara standar untuk membuat dan menyiapkan repositori akan menghemat pekerjaan berulang dan mendukung praktik terbaik.

Untuk mengatasi masalah ini, praktik terbaik mencakup

  • Menyiapkan repositori dengan proses otomatis, berulang, dan berorientasi pada keamanan. Misalnya, Anda dapat menyiapkan modul Terraform yang menggabungkan persyaratan keamanan aplikasi yang digunakan repositori. Aplikasi dengan keamanan tinggi memerlukan pemberi persetujuan penggabungan yang lebih banyak dan berbeda daripada aplikasi dengan keamanan yang lebih rendah.
  • Membuat cara bagi administrator repositori untuk memilih dari kumpulan template konfigurasi repositori yang mendorong penyiapan repositori baru, bukan mengonfigurasi setiap repositori dari awal. Template ini harus mencerminkan tingkat keamanan aplikasi Anda yang berbeda, 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 atasnya.
  • Mewajibkan pengelolaan identitas terpusat dengan autentikasi multi-faktor untuk pengguna repositori.
    • Pengelolaan identitas terpusat memastikan bahwa saat pengguna keluar dari organisasi atau berpindah ke tim baru, Anda mempertahankan hak istimewa terendah di sekitar pengelolaan sumber.
    • Autentikasi multi-faktor secara signifikan mengurangi risiko phishing dan jenis serangan lainnya pada sumber Anda. Autentikasi dua faktor 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 di organisasi. Jika memungkinkan, hapus kemampuan pemilik repositori untuk melakukan penggabungan tanpa peninjau kedua.

Peninjauan kode

Peninjauan kode adalah cara utama organisasi mempertahankan 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 kurang jelas
  • Pengenalan masalah keamanan karena kode yang tidak aman yang ditulis oleh developer
  • Pengenalan masalah keamanan karena menambahkan library pihak ketiga yang tidak aman atau dapat menjadi tidak aman.

Beberapa cara untuk mengurangi risiko mencakup:

  • Menerapkan otomatisasi pengujian di seluruh siklus proses software. Pengujian otomatis yang dipicu saat Anda melakukan commit sumber ke sistem kontrol versi adalah cara bagi developer untuk mendapatkan masukan dengan cepat tentang masalah yang ditemukan oleh pengujian.
  • Membuat 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 ditampilkan secara publik.
  • Menetapkan peninjau berdasarkan keahlian teknis dan tingkat kepercayaan yang diperlukan untuk perubahan dalam commit. Peninjau harus ahli dalam bahasa yang ditinjau, sistem yang berinteraksi dengan kode, dan risiko keamanan dalam kelas aplikasi ini. Persyaratan keahlian teknis memiliki banyak dimensi. Contoh:
    • Apakah kode dapat dibaca?
    • Apakah aman?
    • Apakah menggunakan library pihak ketiga yang sesuai?
    • Apakah proses pengamanan library pihak ketiga sudah diterapkan?
    • Apakah kode dapat disusun?
    • Apakah desain API mengikuti praktik terbaik?

  • Peninjauan tidak boleh menjadi langkah birokrasi, tetapi percakapan berkelanjutan seputar praktik terbaik. Buat checklist, panduan gaya, dan standar desain di sekitar setiap bagian dari tumpukan teknologi Anda, beserta program pendidikan untuk developer baru. Beberapa IDE seperti VS Code dan IntelliJ menyediakan linter yang dapat secara otomatis menandai error programatik 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). Kursus ini menjelaskan praktik pengembangan software dasar dalam konteks keamanan supply chain software.

  • Lakukan peninjauan kode dengan permintaan pull cabang fitur segera setelah developer individu siap. Jangan menunggu hingga tepat sebelum rilis baru ditempatkan ke dalam pengujian untuk melakukan pemeriksaan keamanan dan peninjauan kode.

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

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

Persetujuan penggabungan

Dalam pipeline CI/CD yang terintegrasi secara berkelanjutan, penggabungan kode ke dalam cabang produksi dapat menghasilkan perubahan hilir termasuk build dan peluncuran otomatis. Oleh karena itu, mengamankan siapa yang dapat melakukan penggabungan adalah bagian penting dari pengamanan deployment software. Pertimbangannya meliputi:

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

Alat untuk mengamankan pengembangan

Google Cloud menyediakan serangkaian kemampuan dan alat modular yang dapat Anda gunakan untuk meningkatkan postur keamanan supply chain software Anda. Komponen berikut membantu melindungi kode sumber software:

  • Cloud Workstations (Pratinjau)

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

    Cloud Workstations membantu menggeser keamanan ke kiri dengan meningkatkan postur keamanan lingkungan pengembangan aplikasi Anda. Solusi ini memiliki fitur keamanan seperti Kontrol Layanan VPC, traffic masuk atau keluar yang terlindungi, update image otomatis, dan kebijakan akses Identity and Access Management. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Cloud Workstations.

  • Cloud Code source protect (Pratinjau)

    Cloud Code menyediakan dukungan IDE untuk membuat, men-deploy, dan mengintegrasikan aplikasi dengan Google Cloud. Solusi ini memungkinkan developer membuat dan menyesuaikan aplikasi baru dari template contoh dan menjalankan aplikasi yang telah selesai. Cloud Code source protect memberikan masukan keamanan real-time kepada developer, seperti identifikasi dependensi yang rentan dan pelaporan lisensi, saat mereka bekerja di IDE. Solusi ini memberikan masukan yang cepat dan dapat ditindaklanjuti yang memungkinkan developer melakukan koreksi pada 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 berikutnya