Lindungi bisnis Anda selama proyek pengkodean khusus

Pada 19 Juli 2019, programmer kontrak David Tinley mengaku bersalah atas tuduhan bahwa ia sengaja merusak komputer milik Siemens Corporation. Menurut pengajuan dalam kasus ini, Tinley menanam bom logika ke dalam kode yang ia kembangkan untuk Siemens di lokasi Monroeville, Pennsylvania. Bom-bom logika itu, yang merupakan bagian-bagian kode yang diatur waktunya untuk menimbulkan gangguan berminggu-minggu atau berbulan-bulan setelah proyek selesai, dimaksudkan untuk memastikan bahwa Tinsley memiliki aliran pendapatan konstan karena harus memperbaiki masalah yang dianggap sebagai bug. Ketika dia dipanggil untuk memperbaiki masalah, Tinsley hanya mengubah tanggal pada bom logika sehingga itu akan berbunyi lagi nanti.

Akhirnya, programmer lain dipanggil untuk memperbaiki kode Tinsley ketika dia sedang berlibur, dan saat itulah plot itu terungkap. Tinsley yang berusia 62 tahun telah bekerja untuk Siemens selama sekitar 12 tahun sebelum dia ditangkap, tetapi selama waktu itu, dia tidak pernah dicurigai. Hukuman ditetapkan untuk 8 November 2019, dan Tinsley bisa menghabiskan 10 tahun penjara dan membayar denda hingga $ 250.000.

Menyewa Kode Cadangan

Jadi, mengapa saya memberi tahu Anda semua ini? Lagipula, kemungkinan Anda bisa menyewa seorang programmer yang dengan sengaja memasukkan bom logika ke dalam kode kustom Anda tidak besar. Dan sementara peluang itu tidak nol, ada sejumlah hal lain yang bisa salah ketika seseorang menulis kode untuk organisasi Anda.

"Apa yang terjadi jika orang itu mati atau jatuh?" tanya Jack Gold, Kepala Analis di J. Gold Associates. Gold menyarankan bahwa ketika Anda merekrut seseorang untuk melakukan pengembangan, Anda selalu membutuhkan cadangan. Lagi pula, kode khusus adalah kode Anda. Tidak ada pihak ketiga yang dapat Anda hubungi jika ada masalah, kecuali jika Anda merencanakannya. Dia juga menyarankan bahwa ada beberapa langkah lain yang perlu dilakukan perusahaan untuk melindungi diri mereka sendiri selama proses pengembangan, kepala di antara mereka diperlukan tinjauan kode.

"Tinjauan kode mungkin merupakan cara terbaik untuk mengetahui apa yang ada dalam kode Anda, " kata Alan Zeichick, Kepala Analis di Camden Associates, "termasuk hal-hal seperti bom logika, kerentanan keamanan, atau kesalahan bodoh."

"Ada alasan lain untuk melakukan tinjauan kode, " Zeichick menambahkan. "Ini membantu tim pengembangan Anda mendapatkan pemahaman yang lebih baik tentang bagaimana pengembangan bekerja, membantu programmer junior mendapatkan pemahaman yang lebih baik. Ulasan kode juga baik untuk membantu manajer tim menangani kualitas tim pengembangan dan mendapatkan perkiraan berapa lama dibutuhkan untuk menyelesaikan pekerjaan.

Melakukan Ulasan Kode

Zeichick mengatakan bahwa ada beberapa cara untuk melakukan tinjauan kode. "Anda dapat memiliki tim di mana ada dua orang yang mengerjakannya atau Anda dapat bertemu di ruang konferensi untuk meninjau kode."

Tim-tim di mana setiap anggota meninjau kode orang lain semakin populer saat programmer semakin sulit menemukannya. Namun dalam organisasi yang lebih besar, pertemuan berkala untuk meninjau kode masih berguna karena beberapa set mata dapat membantu dalam proses peninjauan. Zeichick mengatakan bahwa pemrogram paling senior sekalipun harus ditinjau kodenya.

Jadi, mengapa Siemens membiarkan Tinley pergi selama bertahun-tahun tanpa ulasan kode? Menurut komentar pengacaranya selama persidangan, Tinley menganggap kodenya sebagai hak milik dan menggunakannya sebagai alasan untuk tidak memeriksa kodenya.

Mengapa ini dibiarkan terjadi tidak jelas, tetapi baik Zeichick dan Gold menunjukkan bahwa persyaratan untuk tinjauan kode harus menjadi bagian dari kontrak antara bisnis dan pakaian pemrograman independen. Gold menyarankan bahwa kontrak tidak hanya menyebutkan ulasan kode tetapi menentukan bagaimana dan kapan mereka terjadi.

Zeichick mencatat bahwa beberapa toko pengembangan besar mungkin melakukan tinjauan kode sendiri, yang menurutnya masuk akal. "Orang-orang terbaik untuk melakukan tinjauan kode adalah orang-orang di tim pengembangan, " katanya.

Menghindari Coders Berbahaya

Ulasan kode telah ada hampir selamanya. Ketika saya mengelola tim pemrogram untuk fasilitas pemerintah yang besar, kami akan membahas COBOL yang mematikan pikiran setiap Jumat sore. Meskipun membosankan, kami sering menemukan kesalahan, kesalahan, referensi salah tempat, atau kesalahan pengkodean lainnya. Faktanya adalah, kita semua membuat kesalahan, dan ulasan yang masuk akal membuat kode lebih baik untuk semua orang.

Sayangnya, programmer terkadang membenci ulasan kode, percaya mereka hanya membuang-buang waktu. Yang lain mengatakan mereka tidak ingin orang menebak-nebak kode mereka. Namun faktanya, penolakan untuk memperbolehkan kode ditinjau harus menjadi bendera merah. Jika Anda membayar kode yang akan ditulis, maka kontrak Anda dapat dengan wajar menyertakan persyaratan untuk ulasan. Penolakan untuk melakukan itu adalah alasan pemecatan.

Sayangnya, menemukan programmer yang baik sulit hari ini. Permintaannya tinggi, dan dalam beberapa kasus, pemrogram kontrak merasa mereka dapat menentukan bahwa mereka tidak harus tunduk pada kode mereka ditinjau, bahkan jika kontak mereka mengatakan itu akan.

Cara terbaik untuk menghindari masalah tersebut adalah, pertama, meminta dan kemudian memanggil referensi untuk pekerjaan sebelumnya. Kedua, tegakkan ulasan kode dari Hari Pertama. Dengan begitu, mereka menjadi kebiasaan, dan programmer yang menolak untuk melakukan review dapat diberhentikan segera - sebelum mereka menjadi kritis terhadap proses pengembangan.

• Apa yang Harus Dilakukan Ketika Anda Diretas Apa yang Harus Dilakukan Ketika Anda Diretas
• 6 Hal Yang Tidak Harus Dilakukan Setelah Pelanggaran Data 6 Hal Yang Tidak Harus Dilakukan Setelah Pelanggaran Data
• Florida City akan Membayar $ 600.000 untuk Peretas Setelah Ransomware Attack Florida City untuk Membayar $ 600.000 untuk Peretas Setelah Ransomware Menyerang

Sayangnya, risiko dalam proses pembangunan bisa sangat besar. Gold menunjukkan bahwa seorang programmer yang tidak etis dapat memasukkan pintu belakang ke dalam kode Anda, menemukan cara untuk mencuri data pelanggan Anda atau kekayaan intelektual, atau meneruskan data penting ke perusahaan lain atau kekuatan asing.

Cara untuk mencegahnya adalah dengan mengelola secara terus-menerus, meninjau produk kerja staf pemrograman Anda, dan meninjau kode sebelum diterima oleh sistem manajemen kode Anda.