Sumber pengamanan

Dokumen ini menjelaskan praktik terbaik untuk mengelola kode sumber software.

Langkah mendasar yang dilakukan tim software untuk mengelola sumbernya adalah menggunakan sistem kontrol versi (VCS). Sistem kontrol versi memberikan histori dan auditabilitas 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 saat ini menggunakan kontrol versi, ada banyak cara untuk mengonfigurasi sistem kontrol versi dan integrasinya dengan bagian lain pipeline CI/CD.

Dokumen ini membahas pertimbangan keamanan supply chain software untuk mengonfigurasi sistem kontrol versi. Panduan ini menjelaskan praktik terbaik dari Supply chain Levels for Software Artifacts, framework untuk melindungi supply chain software Anda. Framework ini mencakup persyaratan di beberapa tingkat 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 sesuaikan dengan SLSA level 2 sebagai tingkat dasar awal untuk supply chain software Anda.

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

Menggunakan kontrol versi untuk lebih dari sumber aplikasi Anda

Menyimpan sumber aplikasi dalam kontrol versi adalah praktik yang sudah mapan saat peninjauan historis dan audit 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 menyelesaikan
  • Memerlukan proses persetujuan yang dapat diulang
  • Mewajibkan 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 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: Menyimpan konfigurasi dan skrip untuk database produk dan database analisis atau logging.
  • Notebook Jupyter: Ada berbagai cara untuk menggunakan notebook yang disimpan di GitHub, termasuk ekstensi untuk JupyterLab, Colaboratory, dan Vertex AI Workbench
  • 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 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 dasar untuk mengatur kode dan peran, izin, integrasi, dan persetujuan terkait.

Masalah yang dapat terjadi dengan konfigurasi repositori meliputi:

  • Konfigurasi repositori tidak distandarisasi, sehingga sulit untuk memastikan bahwa keamanan repositori sesuai dengan aplikasi yang diwakilinya, terutama dalam skenario umum saat 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 berat. Memiliki cara standar untuk membuat dan menyiapkan repositori akan menghemat pekerjaan berulang dan mendukung praktik terbaik.

Untuk mengatasi masalah ini, praktik terbaiknya mencakup

  • Siapkan repositori dengan proses otomatis, berulang, dan memperhatikan keamanan. Misalnya, Anda dapat menyiapkan modul Terraform yang menggabungkan persyaratan keamanan aplikasi yang menjadi tujuan repositori. Aplikasi dengan keamanan tinggi memerlukan lebih banyak dan berbeda dari pemberi persetujuan penggabungan dibandingkan aplikasi dengan keamanan yang lebih rendah.
  • Buat 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 berbagai tingkat keamanan aplikasi Anda, dan disinkronkan dengan identitas pengguna yang diperlukan untuk setiap tingkat keamanan. Dalam praktiknya, hal ini biasanya berarti menggunakan sistem identitas dan kontrol akses (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 keluar dari organisasi atau berpindah ke tim baru, Anda mempertahankan hak istimewa minimum di sekitar pengelolaan sumber.
    • Autentikasi multifaktor secara signifikan mengurangi risiko phishing dan jenis serangan lainnya pada sumber Anda. Autentikasi 2 langkah adalah salah satu persyaratan SLSA level 4 untuk pemberi persetujuan kode.
  • Batasi pemilik repositori untuk sejumlah kecil karyawan tepercaya. Hal ini mungkin memerlukan integrasi kontrol versi dengan sistem pengelolaan identitas dan memindahkan kemampuan untuk menetapkan kebijakan ke tingkat 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 menjaga kualitas dan keamanan software mereka. Peninjauan kode mencoba mengatasi berbagai mode kegagalan seperti:

  • Pengantar kode dengan cacat software atau desain yang tidak fleksibel.
  • API yang tidak ditentukan dengan baik
  • Munculnya masalah keamanan karena kode yang tidak aman yang ditulis oleh developer
  • Munculnya masalah keamanan karena menambahkan library pihak ketiga yang tidak aman atau dapat menjadi tidak aman.

Beberapa cara untuk memitigasi risiko meliputi:

  • Terapkan otomatisasi pengujian selama 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.
  • Buat 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.
  • Tetapkan peninjau berdasarkan keahlian teknis dan tingkat kepercayaan yang diperlukan untuk perubahan dalam commit. Peninjau harus merupakan pakar dalam bahasa yang ditinjau, sistem yang berinteraksi dengan kode, dan risiko keamanan dalam class aplikasi ini. Persyaratan keahlian teknis memiliki banyak dimensi. Contoh:
    • Apakah kode tersebut dapat dibaca?
    • Apakah aman?
    • Apakah aplikasi menggunakan library pihak ketiga yang sesuai?
    • Apakah ada proses pengamanan library pihak ketiga?
    • Apakah kode tersebut composable?
    • Apakah desain API mengikuti praktik terbaik?

  • Peninjauan tidak boleh menjadi langkah birokrasi, tetapi percakapan berkelanjutan tentang praktik terbaik. Buat checklist, panduan gaya, dan standar desain di setiap bagian stack teknologi Anda, beserta program pendidikan untuk developer baru. Beberapa IDE seperti VS Code dan IntelliJ menyediakan lint yang dapat otomatis menandai error terprogram atau gaya. Linters 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 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 library pihak ketiga, ke dalam permintaan pull dan IDE membantu mengidentifikasi masalah sesegera mungkin. On-Demand Scanning API di Google Cloud memungkinkan 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.

Menggabungkan persetujuan

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

  • Siapkan pemilik cabang yang dilindungi di cabang produksi Anda. Jumlah dan identitas orang yang diizinkan untuk bergabung 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.
  • Kontrol identitas pemilik repositori dengan ketat karena di sebagian besar sistem kontrol versi, mereka dapat melakukan penggabungan sendiri.
  • Pisahkan proses persetujuan deployment dan 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 terkelola sepenuhnya di Google Cloud. Hal ini memungkinkan administrator IT dan keamanan 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 memindahkan keamanan ke kiri dengan meningkatkan postur keamanan lingkungan pengembangan aplikasi Anda. Cloud Workstations memiliki fitur keamanan seperti Kontrol Layanan VPC, traffic masuk atau keluar yang terlindungi, update image paksa, 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. Hal ini memungkinkan developer untuk membuat dan menyesuaikan aplikasi baru dari template contoh dan menjalankan aplikasi yang sudah selesai. Perlindungan sumber Cloud Code memberikan masukan keamanan real-time kepada developer, seperti identifikasi dependensi yang rentan dan pelaporan lisensi, saat mereka bekerja di IDE. Alat ini memberikan masukan yang cepat dan bisa ditindaklanjuti yang memungkinkan developer melakukan koreksi pada kode mereka di awal proses pengembangan software.

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

Langkah selanjutnya