Persetujuan rilis aplikasi: bukti uji, risiko, dan rollback

Apa yang perlu disetujui sebelum rilis?

Persetujuan rilis harus menunjuk versi dan perubahan tertentu. Kalimat “sudah dites” belum cukup jika tidak jelas lingkungan, hasil, masalah yang masih terbuka, dan pihak yang menerima risiko.

NIST SSDF v1.1 memuat praktik penetapan kriteria pemeriksaan, perlindungan integritas, pengarsipan rilis, dan pengujian perangkat lunak. Gunakan sebagai rujukan teknis, bukan kewajiban universal menurut hukum Indonesia. Alur persetujuan dan contoh di bawah merupakan rancangan kerja Kompli yang perlu disesuaikan dengan risiko layanan.

Isi catatan rilis

Bagian	Bukti yang disiapkan
Perubahan	Versi, fitur, perbaikan, konfigurasi, dan migrasi data
Hasil uji	Lingkungan, skenario penting, hasil, dan masalah tersisa
Dampak	Pengguna, integrasi, hak akses, data pribadi, serta waktu gangguan
Persetujuan	Pemilik layanan, pemeriksa teknis, dan penerima risiko yang berwenang
Jalan kembali	Kondisi rollback, langkah yang sudah diuji, serta keterbatasannya
Setelah rilis	Pemantauan, kontak, pemeriksaan transaksi, dan keputusan penerimaan

Pisahkan lingkungan uji dari produksi. Gunakan data fiktif saat memungkinkan. Perubahan alur pengumpulan data atau hak akses juga perlu diperiksa dari sisi privasi, bukan hanya apakah tombol berfungsi.

Contoh: aplikasi bisa dikembalikan, skema data belum tentu

Tim fiktif merilis fitur yang mengubah struktur alamat pelanggan. Paket aplikasi versi lama masih tersedia, tetapi struktur data sudah diubah dan beberapa kolom digabung.

Mengembalikan paket aplikasi saja belum menyelesaikan masalah. Tim perlu menguji apakah versi lama bisa membaca struktur baru, bagaimana transaksi selama perpindahan ditangani, serta kapan pemulihan cadangan dapat dilakukan. Jika hasil belum jelas, keputusan yang masuk akal adalah menunda bagian perubahan tersebut, bukan menandai semua kolom siap.

Contoh ini menunjukkan perlunya pemeriksaan tersendiri untuk kode, konfigurasi, dan data. Rencana rollback tidak boleh hanya berupa kalimat “restore backup bila gagal”.

Bagaimana dengan perbaikan darurat?

Siapkan jalur keputusan darurat sebelum kejadian. Tentukan siapa boleh menyetujui, bukti minimum, batas akses, dan pemeriksaan susulan. Catat alasan penyederhanaan proses serta risiko yang diterima. Darurat bukan alasan menghilangkan jejak perubahan.

Jika perbaikan terkait insiden, koordinasikan dengan petugas insiden agar perubahan tidak merusak bukti atau menghambat penilaian dampak. Lihat penanganan insiden data pribadi untuk kewajiban dan pembagian tugas terkait.

Kapan pekerjaan dianggap selesai?

Sesudah rilis, periksa alur pengguna yang penting, kesalahan aplikasi, integrasi, dan pekerjaan terjadwal. Catat versi yang berjalan, waktu penerimaan, serta masalah lanjutan. Tutup akses sementara yang tidak diperlukan dan simpan berkas rilis sesuai kebijakan tim.

Gunakan checklist persetujuan rilis pada rapat singkat sebelum perubahan. Untuk pemeriksaan sepanjang pengembangan, baca pengembangan aplikasi yang aman; untuk gangguan yang lebih luas, gunakan BCP dan DRP.

Contoh keputusan keamanan sebelum rilis

Contoh fiktif: rilis R-12 mengubah unduhan faktur. Kriteria tim menyatakan akses lintas pelanggan harus ditolak dan paket yang dipasang harus sama dengan paket yang diuji. SAST, DAST, dan SCA dicatat sesuai cakupannya.

Hasil pemeriksaan	Keputusan contoh
Semua kasus akses yang disepakati lulus pada paket R-12	Lanjutkan pemeriksaan bukti lainnya sebelum persetujuan
DAST tidak berhasil login	Cakupan belum terbukti; lengkapi pengujian, bukan tandai nol temuan
Akses faktur pelanggan lain berhasil	Tahan perubahan terkait sampai perbaikan dan retest membuktikan penolakan
Temuan lain diminta untuk ditunda	Catat risiko, pihak berwenang, kontrol sementara, tenggat dan pemicu tinjauan

Simpan ID artefak, konfigurasi pemeriksaan, hasil, pengecualian, dan persetujuan. Jangan mengganti paket setelah persetujuan tanpa memeriksa perubahan. Ini contoh penerapan kriteria SSDF PO.4/PW.8, bukan aturan bahwa satu skor alat otomatis menentukan semua rilis.