LAPORAN STRATEGI KEAMANAN PERANGKAT LUNAK

[Static Analysis]

DISUSUN OLEH :
[Mufti Kalean] [3411171136]

PROGRAM STUDI INFORMATIKA

FAKULTAS SAINS DAN INFORMATIKA
UNIVERSITAS JENDERAL ACHMAD YANI
TAHUN 2022
 DAFTAR ISI

BAB I. PEMBAHASAN…………………...………………………………………………...…1

I.1 Judul ……………………………………………………………….……………………..…..2

I.1.A. Membangun Alat Analisis Statis di Google ……………………………………………....2

I.1.B. Pengembang pembuat alat dan bertindak dasarkan tingkat positif palsu dirasakan alat…..2

I.1.C. Basis kode yang matang dengan pengujian penuh dan tinjauan kode yang ketat proses….2

I.1.D. Analisis statis harus menunjukkan dampak melalui data keras…………………………...2

BAB III. KESIMPULAN…………………………………………………………………………………………….….………...3

 BAB I PEMBAHASAN

I.1 Agar proyek analisis statis berhasil, pengembang harus merasakan

manfaatnya dan senang menggunakannya

I.1.A Membangun Alat Analisis Statis di Google

o BUGS PERANGKAT LUNAK BIAYA pengembang dan perusahaan perangkat
lunak menghabiskan banyak waktu dan uang.
o Misalnya, pada tahun 2014, bug dalam implementasi SSL yang digunakan
secara luas (“goto fail”) menyebabkannya menerima sertifikat SSL yang tidak
valid, 36 dan bug yang terkait dengan pemformatan tanggal menyebabkan
pemadaman Twitter skala besar. 23 Bug semacam itu seringkali dapat
dideteksi secara statis dan, pada kenyataannya, terlihat jelas setelah
membaca kode atau dokumentasinya, namun tetap membuatnya menjadi
perangkat lunak produksi.
Pekerjaan sebelumnya telah melaporkan pengalaman menerapkan alat
pendeteksi bug ke perangkat lunak produksi. 6,3,7,29 Meskipun ada
banyak kisah sukses untuk pengembang yang menggunakan alat analisis
statis, ada juga alasan insinyur tidak selalu menggunakan alat analisis
statis atau mengabaikan peringatan mereka, 6,7,26,30 termasuk:
o Tidak terintegrasi.
Alat tidak diintegrasikan ke dalam alur kerja pengembang atau
memerlukan waktu terlalu lama untuk dijalankan;
o Tidak dapat ditindaklanjuti.
Peringatan tersebut tidak dapat ditindaklanjuti;
o Tidak dapat dipercaya.
Pengguna tidak mempercayai hasil karena, katakanlah, positif palsu;
Tidak nyata dalam praktek. Bug ed yang dilaporkan secara teori
dimungkinkan, tetapi masalahnya tidak benar-benar terwujud dalam
praktik.
 wawasan kunci
 Penulis analisis statis harus fokus pada pengembang dan mendengarkan
umpan balik mereka.
 Integrasi alur kerja pengembang yang hati-hati adalah kunci untuk adopsi alat
analisis statis.
 Alat analisis statis dapat diskalakan dengan pengembangan analisis
crowdsourcing.
 Terlalu mahal untuk diperbaiki. Memperbaiki bug yang terdeteksi terlalu
mahal atau berisiko; dan Peringatan tidak dipahami. Pengguna tidak
memahami peringatan tersebut.
Di sini, kami menjelaskan bagaimana kami telah menerapkan pelajaran dari
pengalaman Google sebelumnya dengan analisis Java FindBugs, serta dari
literatur akademik, untuk membangun infrastruktur analisis statis yang
berhasil digunakan setiap hari oleh sebagian besar insinyur perangkat lunak
di Google. Alat Google mendeteksi ribuan.
masalah per hari yang diperbaiki oleh engineers, dengan pilihan mereka
sendiri, sebelum kode yang bermasalah diperiksa basis kode seluruh
perusahaan Google.

mungkin tidak mewakili kesalahan perangkat lunak yang sebenarnya. Kami

menganggap suatu masalah sebagai "positif palsu yang efektif" jika
developer tidak mengambil tindakan positif setelah melihat masalah tersebut.
jika analisis salah melaporkan masalah, tetapi pengembang tetap melakukan
perbaikan untuk meningkatkan keterbacaan atau pemeliharaan kode, itu
bukan positif palsu yang efektif. Jika analisis melaporkan kesalahan yang
sebenarnya, tetapi pengembang tidak memahami kesalahan tersebut dan
karena itu tidak mengambil tindakan apa pun, itu adalah positif palsu yang
efektif. Kami membuat perbedaan ini untuk menekankan pentingnya persepsi
pengembang. Pengembang, bukan pembuat alat, akan menentukan dan
bertindak berdasarkan persepsi alat.

 kontribusi
o tingkat positif palsu.
Cara Google membuat perangkat lunak. Di sini, kami menguraikan aspek
utama dari proses pengembangan perangkat lunak Google. Di Google,
hampir semua alat pengembang (kecuali lingkungan pengembangan)
dipusatkan dan distandarisasi. Banyak bagian infrastruktur dibangun dari nol
dan dimiliki oleh tim internal, memberikan fleksibilitas untuk bereksperimen.
Kontrol sumber dan kepemilikan kode. Google telah mengembangkan dan
menggunakan sistem kontrol sumber tunggal dan satu repositori kode
sumber monolitik yang menampung (hampir) semua kode sumber hak milik
Google. sebuah Pengembang menggunakan “trunk
pengembangan berbasis”, dengan penggunaan cabang yang terbatas,
biasanya untuk rilis, bukan untuk fitur. Insinyur mana pun dapat mengubah
bagian kode apa pun, tunduk pada persetujuan pemilik kode. Kepemilikan
kode berbasis.
 Jalur seorang pemilik direktori secara implisit juga memiliki semua
subdirektori., Membangun sistem. Semua kode dalam repositori Google
dibangun dengan versi yang disesuaikan dari sistem pembangunan Bazel
 membutuhkan bangunan yang kedap udara; artinya, semua input harus
dideklarasikan secara eksplisit dan disimpan dalam kontrol sumber
sehingga build mudah didistribusikan dan diparalelkan. Dalam sistem
build Google, aturan Java bergantung pada Java Development Kit dan
kompiler Java yang diperiksa ke kontrol sumber, dan binari semacam itu
dapat diperbarui untuk kita semua
 ers hanya dengan check-in versi baru. Build umumnya dari sumber (di
kepala), dengan beberapa artefak biner diperiksa ke dalam repositori.
Karena semua pengembang menggunakan sistem build yang sama, ini
adalah sumber kebenaran untuk mengetahui apakah setiap potongan
kode tertentu dapat dikompilasi tanpa kesalahan.
 Alat analisis. Alat analisis statis yang digunakan Google biasanya tidak
rumit. Google tidak memiliki dukungan infrastruktur untuk menjalankan
analisis antarprosedur atau keseluruhan program pada skala Google, juga
tidak menggunakan teknik analisis statis tingkat lanjut (seperti logika
pemisahan ) pada skala besar. Bahkan pemeriksaan sederhana
memerlukan infrastruktur analisis yang mendukung integrasi alur kerja
agar berhasil. Jenis analisis yang diterapkan sebagai bagian dari alur
kerja pengembang umum meliputi: Pemeriksa gaya (seperti Checkstyle,

o proyek sumber terbuka besar Google (seperti Android dan Chrome)

menggunakan infrastruktur terpisah dan alur kerjanya sendiri.
 I.1.B Pengembang pembuat alat dan bertindak berdasarkan
tingkat positif palsu dirasakan alat

o Pilint dan Golint

Alat pencari bug yang dapat memperluas compiler, termasuk, tetapi tidak
terbatas pada, alat pencocokan pola pohon sintaks abstrak, pemeriksaan
berbasis tipe, dan analisis variabel yang tidak digunakan;
Penganalisis yang melakukan panggilan ke layanan produksi.
Bug kegagalan akan ditangkap oleh linter C++ Google yang memeriksa
apakah pernyataan if diikuti oleh tanda kurung. Kode yang menyebabkan
pemadaman Twitter 23 tidak dapat dikompilasi di Google karena kesalahan
kompiler Rawan Kesalahan, pemeriksaan berbasis pola yang
mengidentifikasi penyalahgunaan pemformatan tanggal. Pengembang
Google juga menggunakan alat analisis dinamis (seperti AddressSanitizer)
untuk menemukan buffer overrun dan ThreadSanitizer untuk menemukan
data race.
Alat ini dijalankan selama pengujian dan terkadang juga dengan lalu lintas
produksi.

 Lingkungan Pengembangan Terpadu (IDE). Alur kerja yang jelas di titik integrasi
untuk menunjukkan masalah.
- analisis statis di awal proses pengembangan ada di dalam IDE.
Namun Pengembang Google menggunakan berbagai macam editor, sehingga
sulit untuk secara konsisten mendeteksi bug oleh semua pengembang sebelum
menjalankan alat pembangunan. Meskipun Google menggunakan analisis yang
terintegrasi dengan IDE internal populer, membutuhkan IDE tertentu dengan
analisis yang diaktifkan bukanlah permulaan.
- Pengujian. Hampir semua kode Google menyertakan pengujian yang sesuai,
mulai dari pengujian unit hingga pengujian integrasi berskala besar. Pengujian
diintegrasikan sebagai konsep kelas satu dalam sistem build
- tem dan hermetis dan didistribusikan, seperti membangun. Untuk sebagian besar
proyek, pengembang menulis dan memelihara pengujian untuk kode mereka;
proyek biasanya tidak memiliki kelompok pengujian atau jaminan kualitas yang
terpisah. Build-and
- sistem pengujian menjalankan pengujian pada setiap komit dan memberi tahu
pengembang jika perubahan pengembang merusak pembangunan atau
menyebabkan pengujian gagal. Ini juga mendukung pengujian perubahan
sebelum melakukan untuk menghindari.
- menghancurkan proyek-proyek hilir. Tinjauan kode. Setiap komit ke basis kode
Google melalui tinjauan kode terlebih dahulu. Meskipun setiap pengembang
dapat mengusulkan perubahan pada bagian mana pun dari kode Google, pemilik
kode harus meninjau dan menyetujui perubahan tersebut sebelum
mengirimkannya. Selain itu, bahkan pemilik harus meninjau kodenya sebelum
melakukan perubahan. Tinjauan kode terjadi melalui alat berbasis
- web terpusat yang terintegrasi erat dengan infrastruktur pengembangan lainnya.
Hasil analisis statis ditampilkan dalam tinjauan kode. Melepaskan kode. Tim
Google sering merilis, dengan sebagian besar proses validasi rilis dan
penerapan otomatis melalui metodologi "push on green", 27 artinya proses
validasi rilis manual yang sulit tidak mungkin dilakukan. Jika teknisi Google
menemukan bug dalam layanan produksi, rilis baru dapat dipotong dan
diterapkan ke server produksi dengan biaya yang relatif rendah dibandingkan
dengan aplikasi yang harus dikirim ke pengguna.
o Apa yang Di Pelajari dari FindBugs Penelitian sebelumnya, dari 2008
hingga 2010, tentang analisis statis di Google berfokus pada analisis Java
dengan FindBugs 2,3 : alat yang berdiri sendiri yang dibuat oleh William Pugh
dari University of Maryland dan David Hovemeyer dari York College of
Pennsyl vania yang menganalisis file kelas Java yang dikompilasi dan
mengidentifikasi pola kode yang menyebabkan bug. Pada Januari 2018,
FindBugs hanya tersedia di Google sebagai alat baris perintah yang
digunakan oleh beberapa insinyur. Tim Google kecil, yang disebut "BugBot",
bekerja dengan Pugh dalam tiga upaya yang gagal untuk mengintegrasikan
FindBugs ke dalam alur kerja pengembang Google.
- Karena itu, kami telah mempelajari beberapa pelajaran: Percobaan 1. Dasbor
bug. Awalnya, pada tahun 2006, FindBugs diintegrasikan sebagai alat terpusat
yang berjalan setiap malam di seluruh basis kode Google, menghasilkan
database temuan yang dapat diperiksa oleh para insinyur melalui dasbor.
Meskipun FindBugs menemukan ratusan bug di basis kode Java Google, dasbor
tidak banyak digunakan karena dasbor bug berada di luar alur kerja
pengembang yang biasa, dan membedakan antara masalah analisis statis baru
dan yang sudah ada sangat mengganggu.
- Percobaan 2. Mengajukan bug. Tim BugBot kemudian mulai melakukan triase
secara manual terhadap masalah baru yang ditemukan oleh setiap Nightly Find
- Bug dijalankan, mengajukan laporan bug untuk yang paling penting. Pada bulan
Mei 2009, ratusan insinyur Google berpartisipasi dalam minggu “Fixit” di seluruh
perusahaan, dengan fokus menangani Temukan
- Peringatan bug. 3 Mereka meninjau total 3.954 peringatan tersebut (42% dari
total 9.473), tetapi hanya 16% (640) yang benar-benar diperbaiki, meskipun
faktanya 44% dari masalah yang ditinjau (1.746) menghasilkan laporan bug yang
diajukan. Meskipun Fixit memvalidasi bahwa banyak masalah yang ditemukan
oleh FindBugs adalah bug yang sebenarnya, sebagian kecil yang signifikan tidak
cukup penting untuk diperbaiki dalam praktiknya. Secara manual tri
- masalah penuaan dan pengajuan laporan bug tidak berkelanjutan dalam skala
besar. Upaya 3. Integrasi tinjauan kode. Tim BugBot kemudian menerapkan
sistem di mana FindBugs secara otomatis berjalan ketika perubahan yang
diusulkan dikirim untuk ditinjau, memposting hasil sebagai komentar pada utas
tinjauan kode, sesuatu yang sudah dilakukan oleh tim tinjauan kode untuk
gaya/pemformatan. Pengembang Google dapat menekan positif palsu dan
menerapkan kepercayaan Temukan Bug pada hasil untuk memfilter komentar.
Perkakas lebih lanjut tergoda untuk menampilkan hanya peringatan FindBugs
baru tetapi terkadang salah mengategorikan masalah sebagai baru. Integrasi
tersebut dihentikan saat alat tampilan ulang kode diganti pada tahun 2011
karena dua alasan utama: adanya positif palsu yang efektif menyebabkan
pengembang kehilangan kepercayaan pada alat tersebut, dan kustomisasi
pengembang menghasilkan tampilan hasil analisis yang tidak konsisten.
- Jadikan Ini sebagai Alur Kerja Kompiler Bersamaan dengan eksperimen
FindBugs, alur kerja C++ di Google meningkat dengan penambahan
pemeriksaan baru ke kompiler Dentang. Tim Dentang mengimplementasikan
- pemeriksaan penyusun baru, bersama dengan perbaikan yang disarankan, lalu
menggunakan ClangMR 38 untuk menjalankan kompiler yang diperbarui dengan
cara terdistribusi di seluruh basis kode Google, memeriksa ulang, dan secara
terprogram memperbaiki semua contoh masalah yang ada di basis kode. Setelah
basis kode dibersihkan dari suatu masalah, tim Clang mengaktifkan diagnostik
baru sebagai kesalahan penyusun (bukan peringatan, yang menurut tim Clang
diabaikan oleh pengembang Google) untuk menghentikan pembangunan,
sebuah laporan yang sulit diabaikan. Tim Dentang sangat berhasil meningkatkan
kerja sama
o Peringatkan Selama Peninjauan Kode
- Setelah tim Rawan Kesalahan telah membangun infrastruktur yang diperlukan
untuk mendeteksi masalah pada waktu kompilasi, dan telah membuktikannya
- pendekatan berhasil, kami ingin menunjukkan lebih banyak bug berdampak
tinggi yang tidak memenuhi kriteria yang kami uraikan sebelumnya untuk
kesalahan kompiler dan memberikan hasil untuk bahasa selain Java dan C++.
Titik integrasi kedua untuk hasil analisis statis adalah alat tinjauan kode Google,
Critique; hasil analisis statis dipaparkan dalam Critique using Tricorder, 35
Platform analisis program Google. Pada Januari 2018, ada kompiler default
bebas peringatan untuk C++ dan Java build di Google, dengan semua hasil
analisis ditampilkan sebagai kesalahan penyusun atau dalam tinjauan kode.
- Kriteria untuk pemeriksaan tinjauan kode. Tidak seperti pemeriksaan waktu
kompilasi, hasil analisis yang ditampilkan selama peninjauan kode diizinkan
untuk menyertakan hingga 10% positif palsu yang efektif. Ada harapan selama
peninjauan kode bahwa umpan balik tidak selalu sempurna dan yang dievaluasi
oleh penulis
- makin perubahan yang diusulkan sebelum menerapkannya. Pemeriksaan
tinjauan kode di Google harus memenuhi beberapa kriteria.
- Dapat dimengerti. Mudah dipahami oleh insinyur mana pun.
- Dapat ditindaklanjuti dan mudah diperbaiki. Perbaikan mungkin memerlukan
lebih banyak waktu, pemikiran, atau upaya daripada pemeriksaan kompiler, dan
hasilnya harus menyertakan panduan tentang bagaimana masalah.
I.1.C Bahkan dalam basis kode yang matang dengan cakupan
pengujian penuh dan tinjauan kode yang ketat proses.
o Hasil analisis yang ditunjukkan pada waktu kompilasi harus mencapai standar
kualitas dan akurasi yang jauh lebih tinggi yang tidak mungkin dipenuhi untuk
beberapa analisis yang masih dapat mengidentifikasi kesalahan serius.
Setelah peninjauan dan kode diperiksa, gesekan yang dihadapi pengembang
untuk membuat perubahan meningkat. Pengembang dengan demikian ragu-
ragu untuk membuat perubahan tambahan pada kode yang telah diuji dan
dirilis, dan tingkat keparahan yang lebih rendah dan masalah yang kurang
penting sepertinya tidak akan ditangani.
o proyek analisis lainnya
ects di antara organisasi pengembangan perangkat lunak utama (seperti analisis
Facebook Infer untuk aplikasi Android/iOS 7 ) juga menyoroti tinjauan kode
sebagai titik kunci untuk melaporkan hasil analisis.
o Perluas Jangkauan Penganalisis
Karena pengguna pengembang Google telah mendapatkan kepercayaan pada
hasil dari penganalisa kabel Tri, mereka terus meminta analisis lebih lanjut.
Tricorder mengatasinya dengan dua cara: izinkan
o melakukan kustomisasi tingkat proyek dan menambahkan hasil analisis pada
poin tambahan dalam alur kerja pengembang. Di bagian ini, kami juga
menyinggung alasan Google belum memanfaatkan teknik analisis yang lebih
canggih sebagai bagian dari alur kerja pengembang intinya.
o Kustomisasi tingkat proyek.
Tidak semua penganalisa yang diminta memiliki nilai yang sama di seluruh basis
kode Google; misalnya, beberapa penganalisa diasosiasikan dengan laju positif
palsu yang lebih tinggi sehingga akan memiliki laju positif palsu efektif yang
tinggi atau memerlukan konfigurasi proyek khusus agar berguna. Semua
penganalisa ini memiliki nilai tetapi hanya untuk tim yang tepat.
o Untuk memenuhi permintaan ini, kami bermaksud membuat Tricorder dapat
disesuaikan. Pengalaman kami sebelumnya dengan penyesuaian untuk
FindBugs tidak berakhir dengan baik; kustomisasi khusus kami menyebabkan
perbedaan di dalam dan di seluruh tim dan mengakibatkan penurunan
penggunaan alat. Karena setiap pengguna dapat melihat tampilan masalah
yang berbeda, tidak ada cara untuk memastikan masalah tertentu dilihat oleh
semua orang yang mengerjakan proyek. Jika pengembang menghapus
semua impor yang tidak terpakai dari kode tim mereka, perbaikan akan
 segera mundur bahkan jika satu pengembang lain tidak konsisten dalam
menghapus impor yang tidak terpakai
o Untuk menghindari masalah seperti itu, Tricorder mengizinkan konfigurasi
hanya di projek
o ect tingkat, memastikan bahwa siapa pun yang membuat perubahan pada
proyek tertentu melihat pandangan yang konsisten dari hasil analisis yang
relevan dengan proyek itu. Mempertahankan tampilan yang konsisten telah
memungkinkan beberapa jenis penganalisa melakukan hal berikut:
o Menghasilkan hasil yang dikotomis. Misalnya, Tricorder menyertakan ana
lyzer untuk definisi buffering protokol 33 yang mengidentifikasi perubahan
yang tidak kompatibel mundur. Ini digunakan oleh tim pengembang yang
memastikan informasi persisten dari buffer protokol dalam bentuk berseri,
tetapi mengganggu tim yang tidak menyimpan data dalam formulir ini. Contoh
lain adalah penganalisa yang menyarankan menggunakan Guava 37 atau
idiom Java 7 yang tidak masuk akal untuk proyek yang tidak dapat
menggunakan pustaka atau fitur bahasa ini;
o Perlu pengaturan tertentu atau notasi dalam kode. Misalnya, tim hanya dapat
menggunakan analisis nullness Checker Framework 9 jika kode mereka
dianotasi dengan tepat. Analisis lain, ketika dikonfigurasi, akan memeriksa
peningkatan ukuran biner dan jumlah metode untuk biner Android tertentu
dan memperingatkan pengembang jika ada peningkatan yang signifikan atau
jika mereka mendekati batas keras;
o Mendukung bahasa khusus domain khusus (DSL) dan panduan pengkodean
khusus tim. Beberapa tim pengembangan perangkat lunak Google telah
mengembangkan DSL kecil dengan validator terkait yang ingin mereka
jalankan. Tim lain telah mengembangkan praktik terbaik mereka sendiri untuk
keterbacaan dan pemeliharaan dan ingin menerapkan pemeriksaan tersebut;
dan
o Sangat intensif sumber daya. Contohnya adalah analisis hibrid yang
menggabungkan hasil rata-rata dari analisis dinamis. Analisis semacam itu
memberikan nilai tinggi untuk beberapa tim tetapi terlalu mahal atau lambat
untuk semuanya.
o Pada Januari 2018, ada sekitar 70 analisis opsional yang tersedia di Google,
dan 2.500 proyek telah mengaktifkan setidaknya salah satunya. Lusinan tim
di seluruh perusahaan secara aktif mengembangkan penganalisa baru,
sebagian besar di luar pengembangan
o grup oper-alat.
- Poin integrasi alur kerja tambahan. Karena pengembang telah mendapatkan
kepercayaan pada alat tersebut, mereka juga meminta integrasi lebih lanjut ke
dalam alur kerja mereka. Tricorder sekarang memberikan hasil analisis melalui
alat baris perintah, sistem integrasi berkelanjutan, dan alat penelusuran kode.
I.1.D Insinyur yang mengerjakan analisis statis harus
menunjukkan dampak melalui data keras.
- Dukungan baris perintah. Tim Tricord er menambahkan dukungan baris perintah
untuk pengembang yang, pada dasarnya, adalah pembersih kode, secara teratur
menelusuri dan menggosok basis kode var tim mereka.
- peringatan analisis yang kuat. Pengembang ini juga sangat paham dengan jenis
perbaikan yang akan dihasilkan setiap analisis dan memiliki kepercayaan tinggi
pada penganalisa tertentu. Pengembang dengan demikian dapat menggunakan
perintah
- alat baris untuk secara otomatis menerapkan semua perbaikan dari analisis yang
diberikan dan menghasilkan perubahan pembersihan;
- Gating berkomitmen. Beberapa tim menginginkan penganalisa khusus untuk
benar-benar memblokir komit, bukan hanya muncul di alat peninjau kode.
Kemampuan untuk memblokir komit umumnya diminta oleh tim yang memiliki
pemeriksaan khusus yang sangat spesifik tanpa false positive, biasanya untuk
DSL atau pustaka khusus; dan
- Hasil dalam penelusuran kode. Penjelajahan kode berfungsi paling baik untuk
menunjukkan skala masalah di seluruh proyek besar (atau seluruh basis kode).
Misalnya, hasil analisis saat menelusuri kode tentang dep
- API yang dibuat ulang dapat menunjukkan seberapa banyak pekerjaan yang
diperlukan untuk migrasi; atau beberapa analisis keamanan dan privasi bersifat
global dan memerlukan tim khusus untuk memeriksa hasilnya sebelum
menentukan apakah memang ada masalah. Sejak analisis re
- Hasil tidak ditampilkan secara default, browser kode memungkinkan tim tertentu
untuk mengaktifkan lapisan analisis dan kemudian memindai seluruh basis kode
dan memeriksa hasilnya tanpa mengganggu pengembang lain dengan gangguan
dari penganalisa ini. Jika hasil analisis memiliki perbaikan terkait, maka
pengembang dapat menerapkan perbaikan tersebut dengan satu klik dari alat
penelusuran kode. Peramban kode juga ideal untuk menampilkan hasil dari
analisis yang memanfaatkan produk
- data, karena data ini tidak tersedia hingga kode dikomit dan dijalankan. Analisis
yang canggih. Semua analisis statis yang diterapkan secara luas di Google relatif
sederhana, meskipun beberapa tim bekerja pada kerangka kerja analisis khusus
proyek untuk pekerjaan terbatas (seperti aplikasi Android) yang melakukan
analisis antarprosedur. Interproce dural analysis pada skala Google layak secara
teknis. Namun, menerapkan analisis semacam itu sangat menantang. Semua
kode Google berada dalam satu repositori kode sumber monolitik, seperti yang
 telah dibahas, jadi, secara konseptual, setiap kode dalam repositori dapat
menjadi bagian dari biner apa pun. Dengan demikian dapat dibayangkan.
- skenario di mana hasil analisis untuk tinjauan kode tertentu akan memerlukan
analisis seluruh repositori. Meskipun Facebook Infer 7,25 berfokus pada analisis
komposisi untuk menskalakan analisis berbasis logika separasi ke repositori
jutaan baris, scal
- Melakukan analisis semacam itu ke repositori baris singa bernilai miliaran
Google masih membutuhkan upaya rekayasa yang signifikan.
- Sejak Januari 2018, penerapan sistem untuk melakukan analisis yang lebih
canggih belum menjadi prioritas Google karena:
Investasi besar. Investasi infrastruktur di muka akan menjadi penghalang;
Pekerjaan diperlukan untuk mengurangi tingkat positif palsu. Tim analisis harus
mengembangkan teknik untuk secara dramatis mengurangi tingkat positif palsu
untuk banyak penganalisa penelitian dan/atau sangat ketat membatasi kesalahan
mana yang ditampilkan, seperti Infer;
Masih banyak lagi yang harus diterapkan. Tim analisis masih memiliki lebih banyak
ana lyzers "sederhana" untuk diterapkan dan diintegrasikan; dan
Biaya di muka yang tinggi. Kami telah menemukan utilitas dari penganalisa
"sederhana" seperti itu tinggi, motivasi inti dari FindBugs. 24 Sebaliknya, bahkan
menentukan rasio manfaat biaya untuk pemeriksaan yang lebih rumit memiliki biaya
di muka yang tinggi.
Perhatikan bahwa analisis biaya-manfaat ini mungkin sangat berbeda untuk
developer di luar Google yang bekerja di bidang khusus atau pada proyek tertentu
Pelajaran
Pengalaman kami mencoba mengintegrasikan analisis statis ke dalam alur kerja
Google memberi kami pelajaran berharga:
Menemukan bug itu mudah. Ketika basis kode cukup besar, itu akan berisi hampir
semua pola kode yang bisa dibayangkan. Bahkan dalam basis kode yang matang
dengan cakupan pengujian penuh dan proses peninjauan kode yang ketat, bug
berlalu begitu saja. Kadang-kadang masalahnya tidak jelas dari pemeriksaan lokal,
dan kadang-kadang bug diperkenalkan oleh pemfaktoran ulang yang tampaknya
tidak berbahaya. Misalnya, perhatikan cuplikan kode berikut yang melakukan hash
pada bidang f dengan tipe panjang

hasil =
31 * hasil
 + (int) (f ^ (f >>> 32));

- Sekarang pertimbangkan apa yang terjadi jika pengembang mengubah tipe f

menjadi int . Kode terus dikompilasi, tetapi pergeseran kanan sebesar 32 menjadi
no-op, bidang di-XOR dengan dirinya sendiri, dan hash untuk bidang menjadi
konstanta 0 . Hasilnya f tidak lagi mempengaruhi nilai yang dihasilkan oleh metode
hashCode. Pergeseran ke kanan lebih dari 31 secara statis dapat dideteksi oleh alat
apa pun yang dapat menghitung jenis f , namun kami tetap 31 terjadi
rences bug ini di basis kode Google sambil mengaktifkan pemeriksaan sebagai
kesalahan kompiler di Rawan Kesalahan.
- Karena menemukan bug itu mudah, 24 Google menggunakan alat sederhana
untuk mendeteksi pola bug. Penulis analisis kemudian menyetel pemeriksaan
berdasarkan hasil menjalankan kode Google.
- Sebagian besar pengembang tidak akan berusaha keras untuk menggunakan
alat analisis statis. Mengikuti jejak banyak alat komersial, penerapan awal
FindBugs Google bergantung pada para insinyur yang memilih untuk
mengunjungi dasbor pusat untuk melihat masalah yang ditemukan dalam proyek
mereka, meskipun hanya sedikit dari mereka yang benar-benar melakukan
kunjungan semacam itu. Menemukan bug dalam kode check-in (yang mungkin al
- siap digunakan dan berjalan tanpa masalah yang terlihat oleh pengguna) sudah
terlambat. Untuk memastikan bahwa sebagian besar atau semua insinyur
melihat peringatan analisis statis, alat analisis harus diintegrasikan ke dalam alur
kerja dan diaktifkan secara default untuk semua orang. Alih-alih menyediakan
dasbor bug, proyek seperti Rawan Kesalahan memperluas kompiler dengan
pemeriksaan tambahan, dan analisis permukaan menghasilkan tinjauan kode.
- Kebahagiaan pengembang adalah kuncinya. Dalam pengalaman kami dan
dalam literatur, banyak upaya untuk mengintegrasikan analisis statis ke dalam
organisasi pengembangan perangkat lunak gagal. Di Google, biasanya tidak ada
mandat dari manajemen agar para insinyur menggunakan alat analisis statis.
Insinyur yang mengerjakan analisis statis harus menunjukkan dampak melalui
data keras. Agar proyek analisis statis berhasil, pengembang harus merasakan
manfaat dan senang menggunakannya.
- Untuk membuat formulir platform analisis yang sukses, kami telah membuat alat
yang memberikan nilai tinggi bagi pengembang. Tim Tri corder terus menghitung
masalah dengan hati-hati, melakukan survei untuk memahami sentimen
pengembang, memudahkan untuk mengajukan bug terhadap alat analisis, dan
menggunakan semua data ini untuk membenarkan investasi lanjutan.
Pengembang perlu membangun kepercayaan pada alat analisis
- Jika alat membuang-buang waktu pengembang dengan positif palsu dan
masalah prioritas rendah, pengembang akan kehilangan kepercayaan dan
mengabaikan hasil.
- Jangan hanya menemukan bug, perbaiki. Untuk menjual alat analisis statis,
pendekatan tipikal adalah menghitung sejumlah besar masalah yang ada dalam
basis kode. Tujuannya adalah untuk mempengaruhi pembuat keputusan dengan
menunjukkan po
- kemampuan tential untuk memperbaiki bug yang mendasarinya atau
mencegahnya di masa depan.
- Namun potensi tersebut akan tetap tidak terealisasi jika pengembang tidak diberi
insentif untuk bertindak. Ini adalah kelemahan mendasar: alat analisis mengukur
utilitas mereka dengan jumlah masalah yang mereka identifikasi, sementara
upaya integrasi gagal karena rendahnya jumlah bug yang sebenarnya diperbaiki
atau dicegah. Sebaliknya, tim analisis statis Google bertanggung jawab untuk
memperbaiki, serta menemukan, bug, dan mengukur keberhasilan yang sesuai.
Berfokus pada perbaikan bug telah memastikan bahwa alat memberikan saran
yang dapat ditindaklanjuti 30 dan meminimalkan positif palsu. Dalam banyak
kasus, memperbaiki bug semudah menemukannya melalui perkakas otomatis.
Bahkan untuk masalah yang sulit diperbaiki, penelitian selama lima tahun
terakhir telah menyoroti teknik baru untuk pembuatan secara otomatis
- perbaikan untuk masalah analisis statis. 22,28,31 Pengembangan analisis
crowdsource. Meskipun alat analisis statis tipikal memerlukan pengembang ahli
untuk menulis analisis, pakar mungkin langka dan tidak benar-benar mengetahui
pemeriksaan apa yang akan memberikan dampak terbesar. Selain itu, pakar
analisis biasanya bukan pakar utama (seperti yang bekerja dengan API, bahasa,
dan keamanan). Dengan integrasi FindBugs, hanya sejumlah kecil Googler yang
memahami cara menulis cek baru, sehingga tim kecil BugBot harus melakukan
semua pekerjaan sendiri. Ini membatasi kecepatan menambahkan cek baru dan
mencegah orang lain menyumbangkan pengetahuan domain mereka. Tim
seperti Tricorder kini berfokus untuk menurunkan standar pemeriksaan yang
dikontribusikan pengembang, tanpa memerlukan pengalaman analisis statis
sebelumnya. Misalnya, alat Google Refaster 37 memungkinkan operator
pengembang untuk menulis cek dengan menentukan contoh sebelum dan
sesudah potongan kode hewan peliharaan. Karena kontributor sering kali
termotivasi untuk berkontribusi setelah mendebug sendiri kode yang salah,
pemeriksaan baru bias terhadap pemeriksaan yang menghemat waktu
pengembang.
 BAB II KESIMPULAN

- Wawasan terpenting adalah bahwa integrasi alur kerja pengembang yang hati-
hati adalah kunci untuk adopsi alat analisis statis. Sementara pembuat alat
mungkin percaya bahwa pengembang harus senang dengan daftar kemungkinan
cacat dalam kode yang mereka tulis
- Di dalam praktiknya tidak menemukan daftar seperti itu yang memotivasi
pengembang untuk memperbaiki cacat. Sebagai pengembang alat analisis, kita
harus mengukur kesuksesan kita dalam hal cacat yang diperbaiki, bukan angka
sebelumnya
- dikirim ke pengembang. Ini berarti tanggung jawab melampaui alat analisis itu
sendiri.
- menganjurkan sistem yang berfokus pada mendorong integrasi alur kerja sedini
mungkin. Jika memungkinkan, pemeriksaan diaktifkan sebagai kesalahan
kompiler. Untuk menghindari kerusakan build, penulis alat melakukan tugas
untuk terlebih dahulu memperbaiki semua masalah yang ada di basis kode,
memungkinkan kami untuk "meningkatkan" kualitas basis kode Google
selangkah demi selangkah, tanpa regresi. Karena kami menampilkan kesalahan
dalam kompiler, pengembang en
- lawan segera setelah menulis kode, sementara mereka masih dapat melakukan
perubahan. Untuk mengaktifkannya, kami telah mengembangkan infrastruktur
untuk menjalankan analisis dan membuat perbaikan di seluruh basis kode
Google yang luas. Kami juga mendapat manfaat dari tinjauan kode dan
otomatisasi pengiriman yang memungkinkan perubahan pada ratusan file, serta
budaya teknik di mana perubahan pada kode lama biasanya disetujui karena
peningkatan kode menang atas penghindaran risiko.
- Peninjauan kode adalah titik tepat untuk menampilkan peringatan analisis
sebelum kode diterapkan. Untuk memastikan pengembang dapat menerima hasil
analisis, Tricorder menampilkan masalah hanya saat pengembang mengubah
kode yang dimaksud, sebelum perubahan dilakukan, dan tim Tricorder
menerapkan serangkaian kriteria untuk memilih peringatan apa yang akan
ditampilkan. Tricorder selanjutnya mengumpulkan data pengguna dalam alat
tinjauan kode yang digunakan untuk mendeteksi analisis apa pun yang
menghasilkan jumlah reaksi negatif yang tidak dapat diterima. Tim Tricorder
meminimalkan kesalahan positif yang efektif dengan menonaktifkan analisis
perilaku buruk.
- Untuk mengatasi kebutaan peringatan, yang telah bekerja untuk mendapatkan
kembali kepercayaan dari para insinyur Google, menemukan pengembang
 Google memiliki bias yang kuat untuk mengabaikan analisis statis, dan setiap
positif palsu

- atau pelaporan yang buruk memberi mereka pembenaran untuk kelambanan.

Tim analisis cukup berhati-hati untuk mengaktifkan pemeriksaan sebagai
kesalahan atau peringatan hanya setelah memeriksanya berdasarkan kriteria
yang dijelaskan di sini, sehingga pengembang jarang kebanjiran, con
- menyatu, atau terganggu oleh hasil analisis. Survei dan saluran umpan balik
merupakan kontrol kualitas yang penting untuk proses ini. Kini setelah developer
mendapatkan kepercayaan pada hasil analisis, tim Tricorder memenuhi
permintaan untuk lebih banyak analisis yang muncul di lebih banyak lokasi dalam
alur kerja developer Google.
- membangun infrastruktur analisis statis yang sukses di Google yang mencegah
ratusan bug per hari memasuki basis kode Google, baik pada waktu kompilasi
maupun selama peninjauan kode. Kami berharap orang lain dapat
memanfaatkan pengalaman kami untuk berhasil mengintegrasikan analisis statis
ke dalam alur kerja mereka sendiri.