Ngobrolin Keamanan bareng @mazipan
Ringkasan Episode
Bantu KoreksiEpisode ini membahas tentang keamanan web (web security) bersama Mas Irfan, narasumber untuk ketiga kalinya. Diskusi dimulai dengan pengalaman Mas Irfan mencari pekerjaan selama 2 bulan dan pentingnya memiliki dana darurat (emergency fund). Topik utama adalah security yang sering dianggap sulit oleh banyak developer karena kurangnya exposure dan pembahasan, padahal security adalah tanggung jawab semua orang dalam tim pengembangan, bukan hanya tim IT security khusus. Episode ini menekankan bahwa security harus dianggap sebagai bagian dari produk, sama seperti performance dan accessibility.
Poin-poin Utama
- •Security adalah tanggung jawab semua orang dalam pengembangan software, dari front-end sampai back-end, bukan hanya tim IT security khusus
- •Ada banyak tools untuk security checking seperti CodeQL, SonarQube, DefectDojo, Snyk, dan Dependabot yang bisa membantu mendeteksi vulnerability
- •WordPress memiliki standar coding yang ketat dengan mantra 'sanitize early, escape late, always validate everything' untuk mencegah XSS
- •XSS (Cross-Site Scripting) adalah salah satu ancaman paling umum dan harus di-handle dengan sanitasi input dan escaping output
- •Security seringkali berbanding terbalik dengan productivity dan performance, sehingga perlu dicari keseimbangan yang tepat
- •Dependency management menjadi penting karena vulnerability di dependency bisa berdampak ke seluruh aplikasi, sebagaimana dibahas dalam artikel Dan Abramov tentang npm audit
- •Penting untuk menjadi advocate di tempat kerja masing-masing tentang security, performance, dan accessibility dengan pendekatan 'by design' sejak awal pengembangan
SELAMAT MALAM
Selamat malam semuanya, halu-halu.
Selamat malam.
Gimana kabar-kabar?
Gimana puasanya lancar ya, mudah-mudahan ya?
Saya, saya, saya tidak puasa.
Bandirnya juga sudah mulai surut ya.
Saya cuma kebanjiran, cuma kebanjiran.
Tapi nggak kompleksnya, nggak kebanjiran.
Cuma di luar komplek kebanjiran.
Iya, akses. Jadi tidak bisa kemana-mana.
Antarana sekolah juga jadi nggak bisa.
Tapi hampir tiap hari hujan mulu ya sekarang ya.
Sudah nggak sih, sekarang sudah aman sini mah.
Sudah nggak?
Sudah nggak.
Cukia hujan hampir tiap hari.
Nah tadi ada fitur baru, hujan es.
Fitur?
Serius?
Gak tau kenapa, cuma nggak di tempat gue sih.
Bisa ditampung nggak buat itu muka basah?
Atau?
Sayangnya biasa sih bukan es campur, bukan es krim, bukan es celu.
Kasih sinyap lah.
Meni hujan es daripada hujan abu vulkaniknya.
Oh iya, itu benar.
Komparasinya ekstrim.
Berapa kali saya selama di Jogja berapa kali itu hujan abu vulkanik.
Oh sering di Jogja ya?
Lihat transkrip lengkap (829 segmen lagi)
Kalau si merapinya batuk-batuk atau lagi kena flu.
Loh, itu pas Wissuda malam sebelumnya, ya pas letus.
Jadi pas Wissuda itu masih hujan abu.
Terus kan harusnya ada makan-makan, udah bayar juga.
Terus ya Spakat di-cancel buat, ya pokoknya buat kayak donasi gitu.
Pokoknya Wissuda paling ekstrim.
Eh sebentar, Nara Sumber kita kita undang aja kali ya biar ngobrol.
Iya, ngobrolnya belum 4, kasihan dong gue.
Belum ngobrolin hujan abu.
Hei, Nara Sumber kita.
Selamat malam.
Ini kita undang untuk yang ke-berapa kali, ke-2 atau ke-3 ya?
Kesekeian.
Kesekeian ya.
Udah lumayan ini ya, lumayan sering diundang ya.
Gimana kabarnya Mas Irfan?
Terakhir kan lagi nyari kerjaan, sekarang udah ketemu.
Alhamdulillah.
Tepu tangan lagi dong.
Gimana rasanya mencari pekerjaan di winter?
Lumayan, sempat 2 bulan tidak gaji ya.
Januari, Februari.
Kalau pesennya sekarang ya, kayaknya perlu banyak nabung ya.
Buat jaga-jaga biar runway-nya lebih panjang.
Kita harus hitung kebutuhan hidup kita.
Kalau ada tanggungan ya, punya semua all in good, di kali berapa, di kali 6.
Itu harus punya ready fund.
Entah dimasukin ke mana, tapi jangan deposito yang cairnya baru sekian tahun lagi.
6 bulan sekali.
Kalau ngomong finansial bisa panjang nanti kita kalau saya Nara Sumbernya.
Mungkin bisa kali ya, web finance ya.
Finansial untuk para web deaf.
Jadi malam hari ini rencananya kita mau ngobrolin tentang security atau keamanan.
Ini salah satu topik yang disarankan oleh Mas Irfan sendiri, terus kita todong juga.
Dan yang paling banyak vote-nya loh, di GitHub.
Topiknya dari Mas Irfan, kontennya juga udah dikasih.
Kontennya juga dari Mas Irfan.
Orangnya juga sekarang dibawa ke sini.
Buat terkenaan dulu, karena kan topik security ini kan jarang yang bahas ya.
Kalau kita mau jadi developer itu kayaknya di belakang-belakang.
Jadi kayaknya ada komunitasnya sendiri nggak sih?
Ada, ada.
Bahkan profisinya kan ada ya, IT security, atau governance.
Ya, cybersecurity.
Yang semoga topik kita ini bisa memberi pencerahan bagi teman-teman,
khususnya vendor-vendor yang membangun situs untuk ini kita ya.
Pertanyaan pertama adalah role ini atau tugas ini itu untuk developer secara umum atau ada role sendiri?
Security itu mulai dari yang paling bawah sampai paling atas.
Semua bertanggungjawab terhadap security.
Sebenarnya kayak performance nggak sih?
Dalam hal maksudnya walaupun mungkin kalau di perusahaan besar adalah performance specialist atau apa.
Tapi sebenarnya kan ya itu kayak yang dibilang Irfan tadi.
Kayak semua yang coding juga kita bisa pakai A, pakai B, pakai C.
Tapi harus ada pertimbangan performance-nya aja.
Jadi kan security juga kan kita dalam membuat keputusan dalam coding-an,
itu kayak harus ada pertimbangan security-nya juga kan?
Memang pada prakteknya biasanya kita punya specialist misalnya kayak di front-end ya.
Kita punya front-end specialist.
Di IT sec juga biasanya ada teman-teman yang memang profisinya memang di security aja tuh.
Nah itu biasanya yang nge-handle end-to-end jadinya, security-nya.
End-to-end means server-nya juga ngurusin, people-nya juga awareness-nya ngurusin, governance-nya ngurusin.
Dan biasanya di IT sec juga ada spesialisasinya lagi.
Nah tapi yang hari ini ingin kita bahas, at least yang deket sama kita aja deh.
Soalnya kan kadang-kadang meskipun security itu kayak end-to-end ya topiknya.
Tapi kan bahkan tim IT sec pun kadang-kadang meminta kita untuk eksekusi sesuatu.
Nah di sini ketika IT sec meminta sesuatu dan dari sisi web developer-nya,
knowledge-nya terlalu jauh gap-nya ya, itu rada sulit.
Bahkan untuk implementasi hal-hal yang menurut mereka adalah kayak basic aja gitu.
Maksudnya kayak di beberapa company tuh kayak di tempatku yang lama tuh ada ini.
Jadi kalau kita mau deliver services atau web application ke production itu kayak ada security checklist.
Nah security checklist itu isinya sebenarnya hal-hal dasar yang mestinya kita comply dulu
sebelum kita deliver ini product ke production.
Nah hal-hal dasar aja banyak web developer yang kesulitan untuk comply checklist-nya.
Nah kan berarti melihat dari situasi ini,
nah sepertinya kok topiknya jarang dibahas ya.
Atau mungkin karena sebenarnya begitu-begitu aja mungkin ya.
Karena banyak topiknya emang sebenarnya dari jaman kita belajar web dulu ya.
Sudah ada tuh topik begitu. Mungkin ya karena nggak ada ini aja ya.
Tapi praktiknya emang jadinya bahkan teman-teman yang senior pun kadang sulitan untuk ini harus diapain gitu.
Atau harus ngapain gitu.
Nah makanya pinginnya sih awareness-nya juga naik lagi.
At least buat kita yang selama ini mungkin moding-nya di web-nya aja,
entah front-end-nya, entah back-end-nya. Ternyata kita sehari-hari yang moding front-end dan back-end itu tetap ada awareness yang harus dinaikin soal security.
Sama kayak awareness kita soal web performance, sama kayak awareness kita soal accessibility.
Nah security itu ternyata jadi bagian dari product package-nya.
Ya, salah satu.
Dan bisa fatal kalau misalnya lu putih.
Umumnya begitu. Umumnya kan kayaknya ada sebuah konsepsi bahwa soal security itu kayaknya kalau belum kecemplung,
orang belum aware. Padahal kadang dampaknya ketika sudah kecemplung itu terlalu fatal.
Kayak lubang di jalan ya?
Kalau nggak ada yang kecemplung, belum ditambah itu jalan.
Oh, belum kena batunya ya santai aja gitu ya? Gak ada masalah ya?
Saya mau punya satu analogi yang berdasarkan pengalaman ini di rumah sakit mengenai kebersihan.
Yang paling simpel aja itu adalah cuci tangan.
Kalau misalnya di rumah sakit yang sudah tersandarisasi, salah satu yang paling terkena itu GCI, itu semua lini tahu cara cuci tangan yang benar.
Yang enam langkah itu. Dan itu sesekali ada sekaya ahli inspeksinya itu menanyakan.
-Ngeliatin orang cuci tangan? -Kaya sebagai pasien aja datang.
Dia cuci tangan biasa tapi nggak ditegur sama salah satu cleaning service.
Itu juga cara cuci tangan harus benar.
Itu dari sisi inspeksinya dia harus tetap memantau dan melihat semua lini dari paling bawah sampai paling atas itu mengerti cara cuci tangan.
Saya melihat security, at least yang dasar atau top ten atau owas top ten dulu deh.
Itu mengerti dasar-dasar security dan cara menanganinya dan bagaimana menginteract.
Implementasinya di dalam operationnya kita, mau dari moding, mau dari cara kita bekerja di kafe.
Cara kita set password kita, cara kita menyimpan password itu sudah ada diatur.
-Kita mulai dari mana? -Bagai contoh kalau misalnya saya mau kerja dari kafe, itu wajib pakai VPN.
Meskipun wifi-nya pakai password, jadi kalau untrusted network wajib pakai VPN.
Itu kan kadang relasinya ini juga ya karena memang ada beberapa domain yang memang nggak aksesibel buat publik dan cuma aksesibel via proxy atau VPN di kantor tersebut.
Itu namanya Enforce.
Karena kadang-kadang kita di software development kan kita bikin multi environment ya, let's say production, ada canary, ada staging.
Environment environment di bawah production itu memang biasanya nggak aksesibel untuk publik.
Sesebelnya buat internal VPN ya, tolong dijagain public accessnya biar nggak sembarangan di akses.
Kalau kita mau ngomongin tentang security, salah satu referensinya adalah dari...
-Shellscreen. -Shellscreennya hilang dari MDN.
-Internet is a dangerous place. -Alimat pertamanya numpol web.
-Internet is a dangerous place. -Iya.
Jadi banyak resiko-resiko yang bisa terjadi ya, karena dari mulai email, password, kartu kredit, pembayaran, semuanya kita akses internet banking, semuanya di internet kan sekarang ya, semuanya serba internet.
Jadi kalau disini itu ada beberapa jenis ya, beberapa jenis threat itu apa ya?
-Ancaman. -Ancaman, ancaman.
Ada beberapa ancaman. Dan sebenarnya web security itu nggak cuman kayak dari, kita harus mengamankan servernya aja.
Ini semua ini ya, mulai dari aplikasinya, konfigurasinya, web servernya, terus operationnya cara penggunaan.
Kalau di user itu misalkan harus ganti password setiap 6 bulan sekali, atau setahun sekali.
Itu juga termasuk gitu, sampai ke client side nya juga harus dipikirkan. Jadi benar-benar semua ini, nggak cuman ini kerjaan anak BN, ini kerjaan anak PN nggak jadi semua.
Nah untungnya, ini untung atau rugi ya, ini dua belah mata pisau sih. Karena kita sudah terbiasa menggunakan framework, termasuk juga ORM dan lain-lain, itu udah diurusin semua, nggak semua, sebagian sudah diurusin.
-Best practice nya sudah diurusin. -Tapi kita nggak tahu, ternyata itu sudah diurusin gitu. Kita nggak aware.
-Jadi kita nggak punya pengetahuan nya ya? -Ya, kita nggak punya pengetahuan nya. Yang kita tahu bahwa udah aman lah gitu kan, padahal sebenarnya belum tentu juga.
Bisa aja ada ancaman yang lebih advanced ya, lebih mengerikan daripada itu.
Sebagai satu contoh simple, kayak kita penggunaan framework atau CMS, misalnya yang sudah user password.
Kalau misalnya saya bikin CMS jaman dulu, masih jaman kuliah, tanpa pengetahuan security, saya simpan aja username sama password nya itu.
-Input text nya, plain text? -Bukan, password itu dalam plain text database, contohnya.
Tapi kalau kita sudah pakai framework seperti Laravel, seperti Django, ColoPython, atau segala macam, itu sudah ada menyediakan user authentication module.
Yang otomatis sudah menyediakan best practice yang si password nya itu sudah di hash, yang disimpan hash nya doang, contohnya.
Tapi alhasilnya kalau kita hanya tahu pakai, jadi nggak tahu apa yang terjadi di belakang.
Sekarang kita sudah pakai service-service semua ya, Out Zero, Firebase, Cognito, itu sudah mereka menyediakan.
Which is good, tetapi kalau kita nggak tahu dasarnya, ya terjebak lama-lama.
Sama ini nya sih kalau di real usage nya, roy nya juga kadang-kadang, soalnya kan kalau terparti gitu kita harus bayar ya.
Kadang-kadang mereka milih terparti karena memang mungkin nggak punya tenaga yang maintain, nggak punya knowledge yang cukup.
Dan mungkin harganya masih masuk akal buat mereka, tapi mungkin dari satu titik, pada satu titik kadang-kadang ujung-ujungnya balik lagi, mereka akan bikin sendiri.
Jadi disini dijelaskan ada beberapa ancaman kalau di web security atau website security, yang pertama ada cross-site scripting atau XSS.
Injection ya, client-side injection, jadi ada SQL injection, ya ini di client-side. Ini kalau front-end minimal banget, mesti tahu caranya protect ini sih, walaupun mungkin belum tahu yang lainnya.
Ini kan common ya, tapi banyak yang nggak di handle XSS ini, kan yang sering digaung-gaungkan adalah jangan percaya terhadap apa yang di input sama user.
Faktanya kalau QA-nya kreatif biasanya ada satu layer tuh yang akan nge-test dengan input-an yang legendaris tuh.
Ya kayak input gitu mereka isinya pakai JavaScript gitu, script, alert, phone, semacam itu. Bahkan kayak XSS pun banyak kan nggak nge-handle, karena input biasanya kita handle aja, handle input, set ke step-nya, langsung aja kirim ke back-end gitu.
Nggak ada proses sanitize di situ, jadinya ini juga opera-opera siapa yang harusnya sanitize, apakah front-end atau back-end, front-end-nya yang sanitize.
Terserah, itu sebenarnya ini aja. Ya kan salah satu prinsipnya di back-end emang nggak boleh percaya dengan yang dikirim. Walaupun sudah disanitize.
Orang developer front-end bekerja dengan mindset jangan percaya yang dikirim user. Yang dikirim user itu ya yang di browser kan client-side. Orang back-end juga bikin kodingan dengan mindset jangan percaya apa yang dikirim user lewat aplikasi front-end.
Terus seharanya sekarang kan back-end biasanya dikonsumsi multiple client-nya. Let's say kayak browser, ada mobile app-nya, terus bisa jadi ada yang server-to-server, bisa jadi ada CLI gitu ya.
Nah multiple client ini bikin prinsip bahwa tidak boleh percaya terhadap user input makin relevan gitu. Jadi memang sebaiknya di back-end memang sanitize lagi kalau memang input-input itu tidak seharusnya mengandung karakter-karakter yang tidak diinginkan.
Tapi sebagai front-end juga nggak make sense juga kalau user input kayak kata-kata script gitu ya. Terus tiba-tiba kita kirim juga ke back-end. Jadi kalau kata-kata aku sih ya dua arah aja sih.
Sama kalau malasnya script-nya di browser, kayak yang di layar, example.com/trickyjs-nya ngelakuin hal-hal yang berbahaya.
Kalau dulu cookie masih bisa dibaca ya kalau sekarang udah dipartisi, tapi ya tetap aja kan bisa mengakibatkan ancaman security ya. Nah itu kan berarti kita harus limitigate.
Biasanya base64 yang di encode, dijalankan gitu kan. Tapi bukan dijalankan dari domain lain ya. Misalnya dia benar-benar ada masalah nih di inputnya dia masukin JS yang base64 terus dijalankan di browser yang dijalankan oleh browser si user. Cookies masih bisa dibaca.
Itu ada ini juga mas Ivan. Kita tahu pokoknya harus limitigasi duluan kan. Jangan nungguin sampai back-end bahaya. Di XSS tuh ternyata ada yang namanya self-exercise.
Means mungkin kita meng-input sesuatu yang kita nggak tahu tapi sebenarnya itu melakukan XSS terhadap diri kita sendiri. Makanya di beberapa produk yang sudah prominent ini kata-kata Facebook gitu ya.
Kalau kita buka DevTools-nya itu biasanya udah... Oh iya ada stop.
Lo buka DevTools nih lo ngerti nggak mau ngapain? Jangan-jangan lo kopas dari suatu script yang lo nggak tahu script itu ngapain? Makanya dikasih tahu tuh.
Kau berarti lo mau kombinasi sama social engineering gitu ya? Maksud orang yang nggak tahu kayak ditipu-tipu ini caranya biar bisa nge-hack... Contohnya DevTools.
Nah itu script-nya bakal apa yang dilakukan kan misalnya ngambil login token atau apa dikirim ke server-nya si penipu.
Sekarang DevTools... Itu tidak sengaja ya dilakukan oleh dirinya sendiri berarti. Betul. DevTools kita sekarang tuh kalau mau kopas...
Harus bisa kita type dulu. Type dulu, allow, apa gitu. Coba aja.
DevTools kita kalau dikonsolnya kita kopas nggak bisa. Eh, copas pertama kali nggak harus. Berarti sekarang DevTools itu bukan cuma buat ini ya. Buat peringatan juga kadang-kadang buat hiring juga ada ya?
Ada. Masih ya. Bener-bener. Udah nggak sih. Jadang liat tapi semingat ya.
Bener-bener. Alopasting. Oh iya itu alopasting. Ya diketik manual betul.
Kadang ini ya sebeli ya. Sebeli ya yang biasa buka DevTools.
Tapi kita... Tidak, itu cuma kalau installan baru kelihatannya kalau lagi habis update atau apa. Ini bisa nggak? Tidak, kalau type tetap bisa. Tidak, paste dari... Ambil dari misalnya dari MDN tadi.
Dari MDN ya. Harus script dong kalau tes doang. Harus script ya? Iya. Iya maaf, maaf. Oh ini apa? Highlight. Highlightnya. Oke. Sekarang udah ya. Ini nggak bisa nih?
Bisa karena udah pernah. Bisa. Karena udah pernah. Udah pernah. Udah pernah diallow ya. Iya waktu itu setelan baru.
Bisa di-reproduce ya. Oh iya. Harus dihapus dulu semua kali datanya. Historinya. Mungkin.
Nah untuk... Iya ngomongin soal SSS at least berarti dari sisi kita web developer tugasnya adalah dua. Yang satu ketika user menginputkan sesuatu kita make sure aja sanitize hal-hal yang memang kita tidak inginkan.
Misalnya nama. Nama itu kita nggak mau mengandung HTML, mengandung JavaScript, mengandung CSS atau apa pun. Nah itu bisa sanitize.
Yang kedua biasanya selain input yang dikirim dari user adalah output yang kita terima juga dari data source kita. Let's say hasil input user-nya nanti akan ditampilin di satu halaman lain gitu.
Nah halaman lain itu juga mesti ngejagain just in case yang input memang nggak jagain gitu. Jadi yang nampilin itu kan mesti jagain.
Menampilkan HTML. Makanya kalau di-react tuh kita punya lucu kan. Dangerous, scary. Bener, HTML. Jadi kalau cuma ngeprint string-nya, kalau ngerender string-nya itu otomatis di-strip ya nggak sanitize fully sih.
Cuma skrip-skrip itu di-strip. Cuma dihilangin aja sama react. Tapi kalau mau beneran full HTML di-render, sampai command-nya dangerously set inner HTML.
Itu juga ngasih awareness sebenarnya ke developer bahwa ketika kita pakai hal tersebut, make sure kita bener-bener trust dengan data source-nya.
Misalnya oh ini memang dari database kita yang bisa kita control just in case suatu saat ada apa, kita bisa langsung apus aja dulu di database-nya atau dibenerin langsung dari database ya just in case.
Atau kita man sanitize sendiri punya tang jawabnya dialihkan ke developer. Kalau Svel, itu tag-nya cuma @tml doang sih sayangnya.
Karena kalau ikut tutorial official-nya Svel, ada warning-nya juga developer yang bertanggung jawab atas HTML ini di-render as is.
Dari pengalaman ku, exercise ini emang most of the cases butuh tambahan effort. Jadi kita pake next.js pun nggak, otomotif-li exercise gitu tiba-tiba nggak ada exercise yang terjadi, harus ada campur tangannya gitu.
Nah di security best practice-nya WordPress ada mantra-nya begini. Sanitize early, escape late, always validate, everything. Semuanya.
Bahkan decoding best practice-nya atau WordPress decoding standard, pake PHP, code-sniper, dan pake linter-linter-nya si WordPress semuanya itu sudah diimplementasi mantra itu.
Jadi, sanitize early. Jadi semua input dari user itu sudah harus di sanitize. Apapun itu. Paling awal saat baca dari post, HTTP post, HTTP get, atau request di PHP-nya, sanitize early.
Jadi sebelum diproses, apapun itu, sebelum diproses, yang pertama kalian lakukan, sanitize dulu. Sesuai, mau itu text, sanitize text dulu. Mau itu HTML, sanitize dulu. Kalau itu JavaScript, sanitize dulu.
And so on. Terus kemudian sebelum output terakhir ke user, sebelum output, itu di-escape dulu. Escape HTML, escape text, escape JS, escape attribute, pokoknya di-blank-kan dulu.
- Sebelum output, escape. Terus always validate. - Escape itu maksudnya cuma normalize karakter-karakter itu kan? Special text. - Special karakter, apapun itu didecode.
Jadi kalau tag HTML didecode. Jadi HTML kalau bisa escape attribute, berarti semua tag selain text dihapus, semua attribute tidak ada. Macam-macam. Terus...
- Kalau nggak salah, disini disebutkan script, object, embed, and link. - Link. Semua dihapus. Kalau di-escape. Terakhir adalah always validate.
Nah, always validate ini, datanya, kalau kita udah tahu itu misalnya data, datanya mengenai contohnya, kita tahu itu email, harus email gitu formatnya.
Ya jangan allow everything else, validate aja itu sebagai email dulu. Terus kemudian kalau misalnya, ini ada nih contohnya kalau data sanitizing sama escaping,
- kalau Mas Riza mau buka. - Boleh, boleh. - Validate, misalnya kalau itu memang hanya, kayak kata Mas Sipan tadi, hanya nama, ya udah nama.
Jangan ada kasih idly, atau kasih bowl, nggak ada gitu. Plain text nama. Nah ini kalau di WordPress sudah sediakan sanitize underscore apa, macem-macem.
Ya pake aja pada danan. Di Laravel juga punya, nggak cuma di WordPress. Laravel, Call United, semua ini ya. Ini semua sanitize. - Oke.
- Kalau yang escape... - Kalau di jepaskir, andalan, don't purify. - Escaping ini di PHP, bisa di-scroll, nanti ada escape HTML, escape JS, escape ATRI pun, escape URL.
Kalau kita udah tau itu URL, ya udah, hanya allow URL. Semua elemen di-clean. Nah ini, hanya dengan mantra ini aja, implementasi di kehidupan sehari-hari itu harus tetap aware dan itu nggak mudah.
Harus tetap konsisten. - Oke. Beneran ya, si WordPress ini. Karena, oh iya, karena si WordPress apa ya, dia berhubungan dengan user generated content banyak ya, jadi...
- Banyak ini di luar sana, pendapat di luar sana kalau WordPress itu nggak aman. - Nggak aman. - Ya, tapi kan yang bikin plugin-nya kebanyakan. Dan belum tentu semuanya aware.
- Iya. - Nggak, dan saking banyak penggunanya sih, makin banyak penggunanya kan, kayak makin macem-macem nih orangnya. Mungkin makin banyak orang awam yang pakai, yang jauh dari teknologi, gampang dikibulin buat kopas sesuatu di DevTools misalnya. Itu kan kayak udah...
- Atau disuruh install plugin. Kalau mau bikin begini-gini, udah install aja plugin-nya, upload aja plugin-nya, udah masuk plugin-nya. - Terus ekosistemnya terbuka semua, semua orang bisa bikin plugin.
- Terus misalnya ada yang perlu plugin custom, terus bayar dari Fiverr, developer antar-berantah yang mau dibayar 1 dollar sejam. Itu plugin-nya bisa dipertanggung jawabin atau nggak kan, nggak tahu. Jadi maksud saya mungkin separohnya bukan salah WordPress-nya sendiri sih, cuma saking besar ekosistemnya aja.
- Nah ini selama ini sih kayak cuma pakai ini aja sih. - Udah cukup, asal aware aja, tau oke, memang mau sanitize, sanitize.
- Sama ini sih kayak punya standar buat kalau setiap QA ada unsur-unsur input kayak mempastiin ini di tes. Yang susah nge-enforce itu, bukan susah, maksud saya yang tricky dan mungkin orang banyak lewat itu nge-enforce itunya sih.
- Kalau kayak tadi nih, misalnya kayak di WordPress atau ini, pakenya kan gampang, cuma tinggal pakai function yang udah ada aja. Maksudnya apapun itu mau di PHP atau apa, pasti udah ada library-nya.
- Saya sangat terbantu sekali dengan ekosistemnya WordPress yang sudah menyediakan WordPress Coding Standard yang sudah menangkap hal-hal seperti XSS ini dari saat linter.
- Oh ada linter-nya ya? - Kalau misalnya di JavaScript, temen-temen, ya namanya PHP, Coatsniver, itu sebenarnya static analysis.
- Sebenernya kalau di JavaScript biasanya pakai apa? Untuk XSS ini. - Sonar? Apa-apa?
- Nah untuk XSS ini, jadi kayak saat linter ada nggak kita nge-check kalau kita terima input, kita harus sanitize dulu? - Nggak, nggak ada.
- Mungkin ada, gue sih nggak pernah. - Ya opionated kali ya. - Kesadaan developer, eh nggak tahu sih ada atau nggak.
- Dan next desk? Dan next desk ada nggak? - Nggak, nggak pernah pakai, nggak pernah pakai. - Tapi ada kan sebenarnya ya?
- Ini ya, plugin-based gitu ya. - Tapi nggak ada sih. - Plugin-based ya.
- Tapi mungkin nggak se-komplete itu ya. - Se-popular. - Nggak se-komplete itu ya.
- Bahkan kayak SonarQ pun nggak bisa nge-capture terlalu banyak use case. Kayak input-input yang harus di sanitize itu biasanya nggak diomelin.
- Dia paling omelin kayak misalnya di React-nya masih ada yang pakai dangerous set inner HTML, dia ngasih tahu.
- Karena tokennya jelas kan, lo ada dangerous set inner HTML, oh ini berpotensi XSS, bisa nggak pakai yang lain gitu.
- Gitu-gitu, tapi nggak, dia nggak nge-capture oh input, input name itu harus disanitize dulu sebelum dikirim itu kan udah data flow ya.
- Udah sulit tuh di static analyze biasanya begitu-begitu. - Benar, benar.
- Tapi dari sisi backend juga harus jangan percaya juga apa yang dikirimkan sama klien sebenarnya.
- Jadi tetap harus di double check dari sisi server, server side.
- Nah masalah kan terlalu banyak fill juga ya kadang-kadang ya, jadi seringnya sih males gitu ya, nge-sanitize semua hal ya.
- Jadi kadang-kadang at least yang critical dulu di sanitize deh, yang hal-hal yang mungkin fungsinya penting gitu.
- Atau kayak email, email ya jangan yang aneh-aneh gitu. Yang berpotensi menimbulkan hal-hal aneh lah.
- At least itu ngomongin XSS ya, XSS udah banyak juga. Mungkin banyak hal juga yang nggak selesai apa ya.
- XSS tuh panjang ceritanya, masih ada ini yang lain.
- Kalo dulu kan jaman dulu mungkin temen-temen yang nonton mungkin nggak ngalamin ya, dulu sempet ada atau banyak ya, ada banyak website
- Yang kita bisa mengubah JavaScript, CSS-nya kayak Friendster.
- Friendster, Myspace, Myspace.
- Nah itu kan berbahaya sekali, kalo sekarang mungkin udah agak kurang ya, porsinya ya.
- Kalo dulu Friendster bisa diinject, bisa diinject party.
- Bisa diinject, iya.
- Bisa diinject, bisa geser-geser.
- Iya kalo sekarang mungkin orang udah semakin aware, jadi itu semakin beresiko ya, website-website seperti itu.
- Mungkin juga penyebabnya si WordPress mengadopsi ketatnya apa, koding standar, menerapkan koding standar gitu ya, salah satunya karena kan tadi dia CMS.
- Jadi user generated content, dan besar kemungkinan akan mengarah kesana kan, kalo misalkan dibiarkan lepas gitu.
- Nah itu juga CMS tuh penting tuh Mas Riza, karena kebanyakan orang punya asumsi bahwa CMS ya udah asal jalan aja, padahal CMS itu kayak jantungnya.
- Jantungnya, karena dia yang nge-produce kontennya kan.
- Betul.
- Jadi kalo dari CMS nya gak disanitas dengan baik, yang nampilin juga kocar-kacir, karena harus banyak yang disanitas juga di view nya gitu.
- Tapi kalo dari CMS nya oke, itu kayak data source kita oke tuh, jadi seolah-olah kita nampilin data yang sudah trusted lah istilahnya.
- Kita sudah percaya bahwa CMS kita sudah meng-sanitize dengan baik dari sisi konten inputnya, jadi ketika nampilin mungkin bisa lebih lega sedikit lah.
- Ya mungkin juga, mungkin kita gak nyadar ya, misalkan kayak, wah CMS ngapain sih aman-aman banget orang kita mau bikin buat blog engine sendiri misalkan.
- Ya kan kontennya kita yang nulis gitu, gak mungkin kita macem-macem kan, oke.
- Gak cuma CMS berarti ya, ngomongin CMS itu berarti kayak internal tooling dan lain-lain yang temen-temen, mungkin back office nya gitu ya, seolah-olah gak penting gitu.
- Bukan cuma article blog dan lain-lain ya CMS itu ya, LMS juga termasuk CMS kan sebenarnya.
- Semua, kadang yang menjadi ini apa namanya, kalau misalnya tools-tools yang back office yang internal, ah trusted aja gitu kan yang pakai orang-orang sendiri gitu ya, tapi ya, we don't know, we don't know.
- Sebaiknya kalau mau mulai yang oke sih emang dari data source nya dibenarin ya, jadi tempat user nginput-nginput nya itu di sanitaskan dengan baik, jadi bagian yang nampilin biasanya lebih bisa lega sedikit.
- Harus dimulai sejak awal banget dari sejak ini ya. - Iya, kebetulan kemarin di kantor yang lama itu diriku sempat kayak ngikutin security test gitu dari BSSN.
- Jadi kayak mereka punya apa, dari pemerintah itu punya apa, badan yang ngurusin hal-hal kayak gitu, terus mereka bisa ngetes ke menterian lain software-software nya dari ujung ke ujung.
- Dari sisi mereka akan ngetes banyak hal termasuk kayak gini-gini SSS itu akan dicek, paling banyak ke Jeblos ya temen-temen justru yang pegang banyak form,
jadi kayak misalnya saya kemarin ngajuin cuma aplikasi yang front-facing itu yang public-facing, jadi nggak banyak form inputnya, relatif aman kayak kita cuma ketemu satu-dua yang low priority lagi.
- Tapi temen-temen yang ngahendal aplikasi yang punya banyak form inputnya itu biasanya banyak reportnya, nah yang begitu-begitu kan bikin sadar juga ya bahwa mungkin aplikasinya kita merasa kayaknya baik-baik saja,
tapi begitu kita harus comply dengan suatu regulasi gitu ya, itu rumit tuh kalau udah terlanjur banyak begitu, apalagi light shape form nya banyak sulit, jadi kalau itu bisa dikerjakan di first place gitu ya
ketika kita coding pertama kali itu rasanya nanti beban kalau kita mengajukan terhadap suatu compliance gitu lebih enak lah ya.
- Ya berarti kayak WordPress itu misalnya contoh positifnya kan kalau mau bikin ini standarisasinya gini-gini-gini, kalau internal mungkin malah bisa kalau bikin form tuh kayak ada starternya atau template nya,
jadi setiap mau bikin form harus dari template itu.
- Terus kalau misalnya res API, misalnya semua data diterima dari res API, yang benar adalah state nya res API itu dibuat skema nya dulu,
skema res API mau terima input nya, jadi input dari res API itu seperti apa, data field nya apa saja, dan didefine setiap field nya itu data type nya apa.
Nah dari skema itu punya data field dan data type, setelah data type nya, itu yang berarti saat di backend,
di validate lah itu datanya harus sesuai dengan data type, misalnya kalau inputnya adalah string, sorry data input nya adalah number yang dimasukin string ya sudah,
itu sudah gak validate, jadi kembalian dari res API ini data gak benar.
- Error.
- Error, udah itu aja dulu, simpelnya pintu pertamanya adalah validate data itu dulu,
keduanya baru disanitize, jadi jangan mohon temen-temen yang bikin skema nya untuk res API,
jangan kan misalnya skema gak dibuat, res API field nya dibuat seiring berjalan saat development,
nambah-nambah sesuka hati dan data type nya sesuka hati.
- Atau dibuat gak sesuai, gak sesuai skema, itu lebih bahaya lagi gak sih?
- Iya, bisa jadi.
- Pastinya lebih misleading.
- Lebih misleading, betul, dan saat di develop, ya cuma diterima doang, diterima dan ya tidak,
ya udah langsung diproses, gak dibersihin dulu, harusnya dibersihin dulu.
Jadi saat data disimpan ke database, itu udah pasti bersih sesuai dengan data type yang ditentukan.
Dan framework yang seperti apa ya, yang saya tau kayak Yee kalau di PHP, Yee framework itu misalnya,
dia sudah bisa membuat dari database skema, bisa menjadi model, dan dari model bisa langsung jadi skema,
contohnya, dan itu sudah kayak best practice gitu.
- Itu framework for 10x engineer ya.
- 10x engineer.
- Kalau mau bikin kayak sesuatu yang cepat aja, prototyping cepat tuh enak banget.
Tapi jangan minta untuk custom-custom ya, susah opinionated ya.
- Itu counterpartnya golang, kalau di golang kan nololah. - Semua manual.
- Semua manual, tidak ada framework.
- Iya, iya.
- Kalau ini kan cuma bisa omputer doang ya, 10x engineer ya.
- Ada sedikit asumsi, atau kayaknya rather real ya, jadi sedikit fact lah ya,
kadang-kadang ya, security emang tidak berbanding lurus dengan performance atau productivity, kadang-kadang.
Karena intensinya kalau di security itu ya, makin rubit biasanya makin baik tuh, makin banyak layer-nya makin baik.
Sementara di performance, class is better kan kadang-kadang, semakin sedikit, semakin bagus.
Kalau di security kalau bisa, ada banyak layer-nya nih, ada WAF-nya, ada apanya baru sampai ke service-nya.
Kalau kita pinginnya semua ini, kayak tadi ngomongin SSS ya, itu kan.
- Sama common grounder ya, atau mungkin stakeholder lainnya kayak harus memperjuangin, ini emang perlu.
- Iya, tapi kadang-kadang security juga ini ya, security kalau kita bilang tadi adalah bagian package dari produknya,
ketika kita sadar bahwa security adalah bagian dari produknya, jadi nggak bisa dihindarkan gitu.
Inevitable gitu, jadi sama kayak ketika kita ngobrolin accessibility.
- Itu udah bagian dari feature gitu ya? - Iya, ketika kita memiliki accessibility adalah edit value,
itu yaudah nanti aja kita tambahin gitu. Tapi kalau itu udah jadi requirement, itu harus dikerjain gitu.
Meskipun ada trade-off yang harus dibayar gitu.
Let's say ngomongin web accessibility kan otomatis lebih banyak tag yang harus kita tulis ya,
lebih banyak atribut yang harus kita tambahin.
Maksudnya hasil akhirnya, size-nya makin naik.
Tapi kan itu bikin dari rukar menjadi hal yang sudah secara sadar kita kerjakan,
karena memang benefit-nya lebih banyak daripada mudaratnya istilahnya.
Sama kayak security, apakah, let's say kayak tadi kita ngomongin sanitize di JavaScript,
kadang-kadang yang paling populer dipakai adalah don't purify.
Ketika kita tambahin don't purify, sudah pasti bundle size-nya naik.
Jadi kan nggak sejalan tuh antara web performance dan security.
Jadi mungkin cari balance-nya, mungkin cari hal yang masih bisa diterima sama timnya sendiri atau sama produknya.
Misalnya security itu adalah top issue di produknya, jangan ambil risiko di situ.
Tapi kalau performance adalah top priority.
Nah, tetap basic security kayak XSS dan ada macam-macam yang lainnya,
tetapi kita harus ada standarnya.
Basic security itu harus kayak, ini nggak boleh nggak, harus, harus gitu.
- Iya, tapi juga kadang-kadang kita juga cari jalan cepat ya.
Misalnya kayak kita tahu ada don't purify, ya udah kita nggak mau bikin sendiri.
Padahal sebenarnya mungkin kita bisa define requirement dari XSS-nya.
Misalnya kita nggak mau cover semua hal, kita pengen cover hal-hal basic aja.
Misalnya kita nggak mau input text script, kita nggak mau text style.
Itu kan bisa kita regex aja atau bikin condition aja.
Nah, bergantung kita mau scope-nya sebesar apa,
tapi kalau kita nggak mau pushing, ya udah ambil generic approach aja,
udah pakai don't purify, itu udah common use case udah dihandel di sana.
Mungkin sebagian besar kita bahkan nggak pernah temui itu case-nya si don't purify,
tapi kan berarti ada orang di luar sana yang menganggap itu common use case-nya.
Itu pilihan aja sih.
Kalau memang performance segitu pentingnya dari security-nya,
mungkin bisa scope-nya dikurangin, cukup hal-hal yang critical aja yang disanitize,
mungkin bisa bikin regex sendiri.
Berarti kalau misalkan kita ngomongin tadi product, apakah artinya
kalau kita mikirin security dari awal berarti proses pengertiannya akan lebih panjang?
Otomatis kan ya?
Iya, sama kayak performance juga.
Performance kan meskipun kita bilang, performance web accessibility,
meskipun kita bilang itu bagian dari requirement product-nya,
tapi faktanya ada effort yang harus dikerjakan.
Ada effort tambahan.
Iya, let's say accessibility nggak semua orang bahkan punya knowledge-nya disitu.
Maksudnya kan ada learning curve-nya di awal ya.
Kalaupun sudah tahu learning curve-nya, testing-nya juga butuh testing yang terpisah.
Untuk tes accessibility-nya misalnya kita biasa tes pakai mouse doang,
sekali-kali harus tes pakai keyboard-nya, atau harus tes pakai voice-over-nya.
Biasanya pakai line 4.
Itu kan nambah waktu ya, termasuk performance yang misalnya kita sangat confidence dengan coding-an kita.
Ya udah kita coding biasa, tapi kan pada akhirnya kita harus measure hasilnya ya.
Adakah part-part yang kita miss gitu?
Adakah part-part yang temen kita miss yang kita nggak ngah bahwa itu masuk ke master-nya?
Itu kan jadi ada effort tambahan.
Security juga begitu, kita punya set standarnya.
Tapi pada akhirnya kita juga perlu tes lagi apakah standar ini sudah benar-benar comply atau belum.
Jadi pada akhirnya memang ada tambahan dari hal-hal yang kita ingin capai sih.
Akan ada cost dalam bentuk tenaga, waktu, dan uang.
Tenaga dan waktu.
Karena misalnya kalau sudah punya standar, tentunya harus dibikin jadi sebuah pengecekan yang kayak DCI.
Jadi security itu bagian salah satu yang di-check DCI.
Performance juga salah satu yang di-check DCI.
Jadi lama-lama, ujung-ujungnya untuk nge-push 10 request saja, tes-nya banyak dari linter.
Jadi dari linter, security check, accessibility test, kemudian performance test, sampai end-to-end test.
Akhirnya 1 PR bisa 45 menit.
Itu juga harus dipikirin, balik bodalnya bagaimana.
Soalnya apalagi kalau kita nge-moding di private, yang mana kadang kita kayak GitHub Action mungkin nggak punya free tier yang cukup buat private repository kita.
Berarti kan butuh spawn server sendiri, nyiapin server sendiri untuk jalanin CI-CI tersebut.
Jadi kalau pun itu beneficial, juga mesti dipertimbangkan apakah kita masih mampu bayarnya atau nggak.
Kalau nggak mampu bayarnya, mungkin hal-hal yang nggak kritikal banget dijalani di CI, mungkin bisa ditarik lebih awal.
Terpisah jadi end-to-end test yang terpisah aja apa?
Atau rantannya lebih terpisah ini aja.
Jadi kalau di CI kan berarti kondisinya kita commit dulu, nanti jalan di suatu server yang harus dibayar ya. Kadang-kadang kalau kita nggak mau bayar server CI-nya, ditarik ke depan tuh.
Jadi developer aja yang suruh jalanin itu, jadi make sure dia jalanin satu hal sebelum commit misalnya.
Jadi productivity-nya turun, tapi kan jadi karena nggak mau bayar cost-nya, jadi productivity-nya turun sekali.
Yang paling aman kan kita biasanya kalau commit, ngejalanin pre-commit ya.
Pake husky.
Ya, pre-commit itu biasanya at least udah ngejalanin free tier sama ASL-nya.
Nah kalau kita tahu itu sudah dijalani di lokal, maybe kita nggak perlu lagi di CI.
Ya udah terasa aja dengan pre-commit itu, jadi itu bisa di-skip di CI-nya.
Let's say testing, testing-nya apakah harus testing semuanya?
Mungkin ada strategi kayak ada istilah testing effective changes aja.
Jadi yang ditest itu yang perubahannya aja.
Use case-use case yang terdampak dari perubahannya, compare to source-nya misalnya, compare sama master-nya gitu.
Kalau compare sama master-nya, misalnya dia cuma satu file aja.
Jadi instead jalanin semua file yang bisa jadi dalam satu project 300-400an testing itu, jalanin aja satu file yang effective aja.
Nah itu ada tekniknya juga, sudah ada tekniknya.
Mungkin berbeda-beda tergantung tooling pilihannya, tapi prinsipnya bisa dikerjakan.
Sama kayak tadi ASL-en juga sepertinya bisa yang effective aja kayak pakai husky clean-stage-ed gitu-gitu dia bisa ngetest.
Clean-stage ya, clean-stage-ed.
Again sama file-file yang changes aja, file-file yang berubah aja.
Nah mungkin bisa dipanggil situasi.
Ada strategi satu lagi yang saya pakai, contohnya visual regression testing itu kan cukup costly ya visual regression testing.
Pasti ya.
Jadi daripada setiap PR harus di-check visual regression testing, akhirnya kita decide visual regression testing hanya dilakukan sebelum post-production.
Jadi test terakhir aja, eh ternyata masih ada masalah, ya udah perbaiki aja dulu.
Jadi cuma satu langkah sebelum production aja.
Di Guma ini mas Ivan, bukan pre-production malah post-production.
Jadi iya modelnya adalah, kalau ada apa-apa kita tahu at least 25 menit setelahnya, terus kalau ada apa-apa kita perbaiki dulu.
Kadang-kadang kalau nunggu 25 menit untuk deploy, mungkin nggak, nggak gitu oke buat beberapa tim yang memang delivery-nya kencang, delivery-nya terlalu kencang.
Iya. Jadi itu kadang CIA juga menarik ya bisa dicari approach yang cocok juga sama kondisi tim dan kondisi produk dan keuangan.
Itu ngobrolin soal security, memang ada beberapa praktisys yang naruh security check-nya di CIA-nya.
Itu yang free kayak di GitHub itu ada namanya codeql, itu ada free tiernya.
Jadi teman-teman bisa pakai, dipasang di GitHub Action, itu dia akan nge-check kayak macem-macem kayaknya apa namanya?
Dependensi ke-check juga sama dia, terus ada beberapa common pattern yang bisa terdeteksi sama dia. Ini kayak ini loh versi mini-nya dari kayak yang lebih expert kayak model sonar cube dan lain-lain.
Oh iya, karena dia kan cukup baru ya codeql ya kayaknya baru beberapa tahun belakangan, terus nggak tahu adopsinya cukup bagus apa nggak, keliatannya kok banyak yang nge-lemenin.
Ada juga beberapa vendor yang nge-check, bantu kita nge-check untuk open source produk yang kita pakai, library-library yang kita pakai.
Contohnya yang kayak snike, misalnya snjk.io, jadi bisa bantu pakai CIA-nya mereka jalan untuk code analysis, bisa nge-detek dari package lock-nya kita.
Versi-versi javascript package yang kita pakai, jika ada vulnerability atau high risk, mereka bisa tangkap dan bisa kasih tahu kita, jadi PR-nya nggak bisa dipot.
Itu berbayar ya, tapi kayaknya biasanya suka ada free tier-nya deh.
Ada free tier-nya ini.
Kalau yang open source mungkin.
Open source gratis dia suka ya.
Kalau yang open source mungkin ya, kayaknya biasanya gitu.
Kan biasanya kan kita nggak ngeh ya, karena deep down kita punya dependensi itu ada masalah gitu.
Itu ini sih ya, banyak alternatif juga mungkin bisa explore juga, kayak tadi ada sonar cube.
Sonar cube itu ada dua versi juga, ada yang bisa self-hosted, jadi kalau temen-temen nggak mau bayar sonarnya bisa install sendiri di server sendiri.
Ada yang versi clock-nya juga, which is biasanya orang lebih milih bayar orang aja.
Boleh ini salah, tapi yang paling tua.
Iya, mirip juga.
Ada banyak juga kayak code climate atau apa gitu.
Terus di kantorku yang terakhir itu pakai namanya defect dojo.
Ini versi open source-nya lah dari kayak sonar cube.
Ini juga di install self-hosted gitu.
Ini tampilannya masih ada cupu sih.
Iya, kayaknya masih pakai bootstrap ala-ala tahun 2015.
Tapi it works, it works.
Lambat, tapi it works. Dan masih fiturnya comparable lah sama sonar cube.
Dia bisa deteksi kayak, kan dia bisa dipasang di CI itu.
Dia bisa deteksi kayak dependency yang updated, misalnya tiba-tiba dependency-nya kena CVS yang high risk misalnya.
Itu bisa langsung diprevent di PR atau MR-nya.
Terus ada yang common pattern juga yang kayak misalnya kayak tadi tuh di React,
dia bisa tahu bahwa dangerously set inner HTML berpotensi XSS.
Atau misalnya kita bikin regec, tapi regec-nya berpotensi bisa di DDoS.
Kan umum banget ya regec kena DDoS tag ya.
Nah itu dia bisa tahu dari static code kita.
Itu static analysis semua ya?
Iya, static analysis. Jadi cukup membantu lah.
Dan memang kan butuh role tambahan ya.
Karena cukup kompleks untuk ngedeteksi security, vulnerability gitu.
Tapi sonar cube itu setelah aku ada ininya juga, ada linter gitu ya.
Jadi bisa diturunin tuh naik ke langsung lokal developer-nya.
Tapi nak suruh diriku nggak pernah pakai soalnya.
Ini hardware template banget ya.
Ini belinya di Temflores ini, admin LTE.
Gue pernah pakai ini template.
Karena dia kan open source ya, jadi ya sudah lah ya.
Orang-orang security ini kan emang nggak peduli sama STPI-nya.
Yang penting nggak ada tampilan.
Typical kayak team data juga. Mereka punya banyak tooling loh.
Diriku sempat bantuin team data juga.
Team data tuh banyak banget tooling-nya.
Sama kayak team security juga mungkin punya banyak tooling dan punya banyak dashboard-nya.
Jadi mereka mungkin nyobain 1-2 tooling yang harus mereka coba-cobain.
Yang mungkin sebenarnya secara fungsi saling beririsan gitu ya.
Masih pakai jQuery nih template ini.
Ya itu. Terus ada alternative di GitHub juga kita bisa aktifin.
Dependabot atau kalau itu bawaan dari GitHub-nya, tinggal diaktifin aja.
Atau third party dulu tuh ada namanya Renovate.
Ini mirip sama Dependabot. Sebelum Dependabot ada tuh namanya Renovate.
Itu akan directly ngasih... apa namanya?
Yes, bikin pull request ketika ada update. Terutama yang kena-kena ini ya.
Kena-kena CVE ya.
Jadi ada potensi security whole.
Dependabot ini bagus kok dia bisa kita customize, bisa kita configure, bisa kita combine di grouping.
Tapi ini juga ini ya. Pernah baca artikelnya ini nggak ya? Artikelnya Dan Abramov?
Belum. Banyak artikelnya mana?
Tapi kayaknya coba, kan Dan udah jarang lagi coba cari Mas Riza dan Abramov tuh. Apa sih overreacted apa gitu ya?
Overreacted ya?
Iya harusnya ada. Gue lupa apa ya. Nah itu NPM audit broken by design.
Itu tahun 2021. Basically LDR-nya adalah kan dia maintainer React nih.
Dan somehow React kan dipake oleh banyak library.
Sebagai dependency ya.
Dependency itu kan next step ya. Chaining gitu ya.
Nah kalau yang bawah kena CVE itu naik ke atas kena semua tuh.
Oh gitu. Yang atas-atasnya di mark juga.
Iya dong.
Kita require React. Ternyata React require small library.
Nah small library-nya kena CVE. Gimana caranya kita perbaiki?
Kan kita nggak import library kecil ini. Kita cuma import React.
Oh tapi saat kita install React, yang dependency itu.
Kalau punya team security biasanya itu par noh kalau ngeliat begini.
Jadi apapun CVE-nya mau di lokasinya sedalam apapun library-nya itu maunya diperbaiki.
Karena tulisannya kritikal. Ada 7 kritikal. Kan ngeri ya?
Kayaknya ngeri.
Ini masih high. Ada yang kritikal Mas.
Nah itu juga kita jadi mesti ngerti approach-nya tuh.
Bahwa let's say kita punya dependency React.
Tapi ternyata dependency-dependency-nya React yang kena.
Itu kan ada triknya ya gimana untuk bisa naikin dependency-dependency-nya React.
Tanpa kita nunggu React-nya naikin dependency-dependency yang dipake gitu.
Kan kalau kita mau tutup mata ya udah tungguin React naikin aja.
Tapi emang kita pernah denger React naikin versi untuk bump dependency kecil yang dipake?
Itu hampir jarang hampir.
Bahkan approach yang diambil kayak Next.js itu dia compile library-library kecilnya.
Let's say dia pakai slugify.
Instead of dia require dari npm-nya langsung.
Kayaknya di compile, ditaro di langsung kodenya Next.js.
Jadi ketika kita require Next.js bisa jadi package lock-nya nggak sedalem ketika kita bikin library sendiri.
Yang biasanya kita require banyak.
Tapi kan sebenarnya dia tetap pake ya.
Jadi somehow kalau ada report, kita nunggu team Next.js-nya compile versi barunya.
Tapi approach dari sisi kita jadi sebenarnya nggak tahu itu kalau ada npm-nya di...
Oh berarti kayak npm di curasi dulu ya sama mereka ya?
Ya kayak di bikin binary sendiri jadi sama mereka.
Gak lewat npm.
Jadi ini loh, jadi debatable apakah cara yang diambil sama Next.js adalah?
Memang seharusnya ya ketika kita deliver satu library ya?
Atau apakah npm yang desainnya yang nggak oke aja gitu?
Kayaknya sih yang kedua ya.
Karena yang bikinnya pun udah kabur bikin produk baru ganti deh.
Kayaknya yang kedua nggak bisa perbaiki kayaknya.
Udah bikin baru aja deh.
Tapi jadinya at least dari sisi kita sebagai web developer,
kita mesti tahu nih misalnya kita require library A
bagaimana caranya kita ingin naikin dependency dari library A.
Makanya kalau di URN itu ada resolution dan lain-lain itu
kita mesti tahu cara pake resolution itu gimana.
Itu kayak kita naikin dependency kita tanpa harus nunggu
dependency utama yang kita pake naikin versinya.
Tapi jadinya kita...
Betul sekali, itu maksa kan.
Maksa yang dibawahnya dinaikin.
Tapi jadinya sebenarnya kita jalan di jurang tuh.
Karena kita naikin paksa dependency yang
mungkin belum di expect berjalan dengan baik sama
dependency utama yang kita pake.
Nah tapi ya itu pilihan aja.
Kalau kita sangat peduli dengan hal itu,
mungkin pake semacam resolution atau apa itu
itu mungkin membantu untuk resolve
CV-CV yang nggak direct dependency kita.
Nah tapi just in case kita nggak mau terlalu peduli dengan itu,
jadi aku sih ngerasa mungkin ya
mengabaikan beberapa hal itu mungkin tidak apa-apa.
Tapi ketika ada tim IT sec di company-mu,
itu biasanya akan di-enforce selalu.
Ini ada security, ada security bahkan di beberapa tool
kayak SonarCube atau tadi apa namanya ya.
Dan lain-lain lah ya.
Dan Defect Dojo itu mereka kayak ngasih ranking gitu.
Jadi let's say repository A,
dependency-nya udah baru semua itu dia bisa dapet A gitu misalnya.
Dapet B, dapet C, dapet D, kayak ada rankingnya gitu.
Tergantung seberapa banyak yang kita nggak kerjain.
Jadi IT sec sebenarnya lebih mudah tuh.
Karena mereka udah lihat dashboard,
yang udah ada rankingnya udah sikat aja di yang DD.
Nggak boleh deploy ke production misalnya.
Sangat-sangat-sangat berbantu oleh co-stores begitu.
Jadi kalau memang ada timnya yang aware di sana,
yang mau nggak mau emang kita mesti tahu langkah-langkanya
untuk nge-solve hal-hal yang mungkin agak tricky-tricky nih.
Yang nggak kita pake langsung kah, atau hal-hal lainnya.
Tapi just in case nggak ada IT sec-nya,
mungkin kita cukup peduli dengan dependency utama aja lah.
Biasa kalau dev dependency saya cuekin,
kalau memang nggak penting-penting amat projeknya,
kalau misalnya projek pribadi,
dev dependency ya sudahlah, gitu.
Sama kayak yang di-complain sama Bungdan tadi, Mas Ivan.
Jadi ada beberapa CVE yang katanya, let's say...
Denial of service.
Iya, tapi itu berdampak terhadap library yang kita jalanin di lokal kita dengan...
Browser list contohnya, browser list.
Kan browser list nggak bakal sampai ke public.
Nggak di-compile.
Iya.
Jadi mungkin dicari aja yang...
Sesuai kos dan waktu, tetapi juga tetap harus aman.
Tampaknya masih oke, tapi juga effortnya mungkin masih ketakar.
Nah, trick-ku ya biasanya ya,
biar hal-hal begini itu nggak memberatkan ya.
Biasanya point pertama adalah being effective di kerjaan musahari-hari, gitu.
Jadi kalau kita bisa deliver kerjaan kita dengan tepat waktu,
atau bahkan ahead of timeline, gitu ya.
Itu ngerjain hal-hal begini itu nggak sulit sebenarnya,
karena kita punya banyak waktu luang, guys.
Ada waktunya.
Misalnya ada lah.
Betul, sekali.
Tapi ini akan jadi problem kalau kerjaan kita ada keseret-ceret terus, gitu.
Misalnya yang ngasih deadline nggak ngotak lah,
atau kitanya nggak bisa ngejar deadline-nya, gitu.
Misalnya yang nggak bisa ngejar deadline kan bisa jadi salah kita di estimation ininya ya.
Iya, salah estimasi ya.
Masa kita bikin estimasi, kita nggak expect.
Ya, tapi juga semakin lama kan pada akhirnya kita semakin ngerti ya dengan produk kita ya.
Yang hasil akhirnya, outcome-nya adalah secara efektivitas juga makin oke tuh.
Jadi yang tadinya mungkin ngerjain satu halaman butuh 5 hari,
makin lama let's say setahun di perusahaan tersebut,
nggak sampai 2 hari selesai.
Nah, dengan makin experience kita di bidang kita sendiri,
itu ngerjain hal-hal gini makin jadi kayak hal yang ya sudahlah,
gue kerjain aja.
Iya, betul, betul, betul.
Jadi ngerjain hal-hal kayak performance, accessibility, security,
itu akan jadi hal yang nggak gitu memberatkan
ketika kita perform juga di pekerjaan utama kita, gitu.
Tapi itu akan jadi beban yang berat banget,
kalau ke pekerjaan utama kita aja nggak pernah beres, gitu.
Keter-teran ya, kalau keter-teran ya, buru-buru mikirin performance dan security.
Iya, jadi salah satu yang harus diinfestasi.
Salah satu yang harus diinfestasi ketika, sorry, dikit ya.
Oh iya, Mas Irfan dulu kali.
Iya, dikit ya, Mas Irfan ya.
Jadi dari aku yang saat ini baru join ke company baru,
biasanya yang pertama tak kejar buat diinfestasi adalah
getting context-nya sebanyak mungkin
biar bisa produktif di kerjaanku secepat mungkin, gitu.
Iya, jadi akhirnya,
gue bisa ngerjain banyak ideas gue di kerjaan gue, gitu.
Termasuk misalnya company gue misalnya belum gitu aware soal performance,
gue bisa tambahin kerjaan itu bahkan ketika hal itu belum disuruh, gitu.
Belum di-enforce, gitu.
Tapi kalau nunggu di-enforce itu udah mati-matian kita belum ready.
Secara knowledge bahkan mungkin kita belum ada,
tapi udah diharuskan, itu sulit.
Tapi kalau kayak kita bisa playing around di awal ya,
let's say kita udah mulai coba-coba security,
coba-coba tooling-nya, gitu.
Itu rasanya akan lebih mudah ya.
Jadi kalau pindah ke company baru,
buru-buru cepet biar jadi engineer yang produktif, gitu.
Itu akan menolong banyak hal.
Menarik, menarik.
Jadi kayak punya stock senjata sendiri, gitu ya.
Kayak punya stock cheat sheet sendiri.
Saya punya pendangan yang sedikit berbeda.
Contohnya begini nih,
kalau misalnya kayak security atau performance deh,
security namanya by design,
bukannya dalam pengambilan keputusan saat kita,
sebelum implementasi kita udah memikirkan,
ini harus performance by design dan secure by design.
Jadi bukan kayak, maksudnya,
selagi kita membangunnya,
itu sudah wajib memikirkan security dan performance.
Kalau memang itu yang di-enforce,
bisa dibilang enforced lah, di-enforce dari atas.
- Iguidalnya seperti itu. - Karena misalnya gini,
kalau misalnya kayak perbaikan performance atau perbaikan security,
kalau sudah diujung dan baru mau diperbaiki kebelakang,
itu lebih berat sebenarnya.
Itu pendanaan saya.
Itu common sense, tapi praktikalnya sulit.
Ya, idealnya tidak.
Ya, ngomong aja hal yang sudah dekat sama kita lah,
performance gitu ya.
Kan kita selalu ngomong performance by design, gitu.
Kalau bisa performance, ya emang sudah ada di kepala kita,
sudah ada di tangan kita ketika kita coding pertama kali, gitu.
Jadi sudah kebayang nanti akan jadi apa.
Tapi praktiknya gimana?
Kan selalu back effort kerjaannya, kan.
Kerjaannya kayak sampai production dulu, dipest, balik lagi, gitu loh.
Jadi kerjaannya maju-mundur, maju-mundur, gitu.
Security pun kadang maunya begitu ya.
Let's say ada security checklist.
Tapi faktanya security checklist itu seringnya di-running
kayak seminggu sebelum production, atau dua minggu sebelum production.
Which mungkin kalau pun ada sesuatu,
gue udah nggak punya waktu cukup untuk fix itu.
Karena sudah habis waktunya di awal.
Tidak bagus, tapi kurang realistis.
Lebih praktis, lebih praktis.
Iya, maksudnya kalau kita ngobrolin kayak,
"Wih, harusnya memang begitu."
Itu inilah utopia yang harus dikejar lah, ya.
Harusnya naranya tetap benar-benar masif banget.
Dan praktiknya developer yang kerja di konteks sempat kerja,
kerjaannya kan banyak.
Tapi itu juga bisa jadi ini ya.
Jadi salah satu ide kita buat di company yang dimanapun kita kerja sekarang.
Bahwa itu memang topik yang mungkin bisa dibawa,
itu disampaikan ke hal yang lebih ramai, gitu.
Bahwa urusan performance, security, accessibility itu
akan lebih ringan kalau kita bisa ngobrolin itu di depan.
Atau kita bisa desain itu dari awal.
Daripada nunggu kecebur.
Ya.
Biasanya dari sasi kayak, ya.
Dali ke tasks work-press tadi kan, contoh work-press tadi.
Kalau bahasa ininya jadi vicious cycle.
Jadi kalau misalnya kita mengignore dari awal,
terus udah deliver, baru diperbaiki,
akhirnya kerjaan yang belum rampung kemarin tambah lagi ke belakang.
Mundur lagi ya.
Tambah lagi kita punya kerjaan yang feature yang selanjutnya.
Dan akhirnya lama-lama kita jadi kehilangan waktu yang...
Ada ini lah, ada oport ini tuh untuk jadi advocate lah.
Jadi mudah-mudahan teman-teman yang dengerin jadi advocate di tempatnya masing-masing.
Masa kalau jadi lambat, nggak deploy-deploy,
kan anggota tim yang lain jadi kayak trauma kan.
Aduh, ribet. Jadi kayak apa? Mengasosiasikan itu sebagai hal yang ngereputin semua.
- Menhabat ya. - Terlalu istim.
Kayak traumatis lah. Yang nggak traumatis, cuman itu negatif lah.
Jadi kacau semua kan.
- Tapi biasanya sih hal-hal begitu sebenarnya pada akhirnya pasti bisa dinego ya.
Kayak security checklist pun, ya kita berusaha comply sebanyak mungkin.
Tapi ketika produknya misalnya udah ada ceremony release yang sudah dijadwalkan di tanggal berapa misalnya.
- Itu susah ya. - Ya sudahlah ya.
Deploy dulu, nanti kita bareng-bareng kerjain.
Untuk kita tahu sebenarnya problemnya di mana, cuman kita nggak punya waktu aja untuk fix tersebut.
Nah, itu kan sama juga performance ya.
Kadang-kadang kita tahu aja itu nggak...
Tapi kayaknya gue nggak punya waktu atau nggak punya kesempatan untuk deep dive lebih banyak gitu.
Karena beberapa things kan memang perlu digali dulu tuh untuk bisa proper tuh kayak di performance apalagi.
Kadang-kadang satu hal, kompromit ya.
Kita tahu prinsipnya kalau bikin image ya harus lazy load.
Karena nggak punya waktu ya udah pake native lazy load aja dulu, pake loading lazy dulu.
Padahal di common approachnya kadang mereka pake intersection observer lah, ada-ada tambahan kode.
Tapi karena nggak punya waktu, udah passing ke platform aja dulu.
Bismillah dulu nanti tambahin sisanya gitu.
- Tapi loading lazy sudah support. - Sudah dari common banget ya.
Sudah baseline, sudah baseline. Sudah semuanya pake.
Oke, ini kita udah hampir setengah sebelas.
- Jadi mungkin satu dulu ya. Jadi malam ini kayaknya baru... - Kita baru XSS doang.
Belum escape injection, cross-site forgery.
Karena kita larinya ke CICD sama pipeline.
Tapi itu penting juga. Bisa ada security checks juga di sana terjadi.
Apa minggu depan kita omongin lagi tentang escape injection?
Bisa nanti kita lihat ya jadwal ya.
Mudah-mudahan nanti bisa ini, Mas Riza, bisa mengundang teman-teman ya.
Memang oke di security. Karena gue percaya mereka lebih kompetent dan mungkin bisa mengarahkan kita ke arah yang tepat.
- Ada banyak lah bisa dicolek-colek. - Ada banyak lagi kita ngobrol-ngobrol.
- Kita colek-colek. - Pengen dengar perspektifnya orang yang emang spesialisenya di...
- Betul, sekali. - Bukan kita yang perspektif.
- Ya beberapa yang Kak tulis tuh seperti ini cukup aktif di X2.
Jadi boleh lagi kelek-kelek. Jadwalkan satu buat kapan, satu buat kapan.
Karena ini topiknya labor ya.
- Betul-betul. - Jadi kita bisa bahas security 2, security 3, security 4.
- Banyak ini. Kayaknya topik satu malam, satu episode aja cukup ini. Lebih dari cukup bisa sampe berapa bulan ini.
Jadi sebelum apa? Gimana Ivan?
- Ada satu mantra juga soal security yang pernah saya baca tadi mana.
Tapi selalu terngiang, keamanan itu berbanding terbalik dengan kenyamanan.
- Kenyamanan. Yes. - Tetapi keamanan itu untuk keselamatan.
- Hei, hei, hei. - Kasi tepuk tangan.
- Tepuk tangan dulu dong. Mana sound effect-nya?
Tapi bukan saya quote-nya, saya baca dimana.
- Saya juga punya satu tools yang baru ingat. Sebenarnya ini tools udah cukup lama tau.
Kan temen-temen tau ya, kayak co-pilot. Nah ini buatannya EWS, namanya code risk part.
Ini kan AI code completion juga kan ya.
Tapi kelebihannya dia adalah dia punya security scan.
Jadi bisa dipakai freemium ya, freemium.
Jadi bisa dipakai, pakainya itu dia ada ini, ada tombolnya, tinggal klik aja run security scan.
Nanti dia akan lihat kode kita ada vulnerability atau enggak.
- Co-pilot bisa nggak? - Butuh ini kali, additional prompt.
- Butuh additional, iya. Nah ini kayak misalkan...
- Weh, abses skin dimasukin di info. - Eh, contoh.
- Weh, ini lucu.
- Nah lucu-lucu lho Mas Sipal, nanti ada yang beneran melakukan hal itu lho.
Aduh, iya juga ya.
- Iya, jadi ini salah satu kelebihannya adalah dia punya fitur itu.
Jadi mungkin kalau temen-temen bingung mau mulai dari mana nih security ya,
bisa pakai tools-tools yang udah kita sebutkan tadi ya.
Kalau mau tau lebih lanjut bisa cek di komentar.
Oke, nah sebelum mudahannya ada satu pertanyaan nih, saya nggak tahu kita bisa jawab atau nggak ya.
Silakan baca aja. - Saya jelas nggak bisa sih.
- Bisa jawab atau nggak?
Konteks WAF, WAF itu apa? - Firewall.
Web Application Firewall. - Firewall.
- Oke. Masih oke untuk kita menggunakan WAF sebagai primary defense,
atau kita harus mulai beri kesolusi yang lain?
Ada pendapat?
- Enaknya sih kalau WAF biasanya udah integrated ya sama cloud computing-nya ya.
Kayak di AWS ada, di GCP ada, tinggal pakai aja.
Jadi integrated sama cloud kita, jadi gampang buat di set up.
At least biasanya kita bisa nge-prevent hal-hal yang common lah.
Misalnya kayak kita bisa kasih red limiter di sana.
Let's say satu orang atau satu IP atau satu user ID,
nggak boleh request lebih dari 300 dalam berapa waktu gitu.
At least itu kita bisa kasih red limiter.
Terus biasanya di WAF juga kita bisa blocking-blocking by pattern tuh,
by user agent lah, by IP lah, just in case tiba-tiba kita kena di DOS,
kita bisa deteksi aja apakah IP-nya generated atau IP-nya fix dari suatu tempat tuh.
Ya kalau fix dari suatu tempat juga bisa di-double check dulu sih sebelum nge-block.
Karena beberapa IP yang biasanya terlihat sama WAF itu kadang-kadang IP bukan dari kliennya,
tapi kayak operator-nya.
Kalau nge-block operator-nya ya semuanya kena.
Kalau yang banyak pulse ya.
Oh maksudnya NAT ya?
NAT, kayak satu area ya.
Atau dari operator ini ya kadang-kadang operator si internet-nya atau apa gitu, takutnya gitu.
Jadi dilihat-lihat lagi.
Just in case kalau yakin banget beberapa IP memang tidak wajar,
enaknya bisa cepat di-block tanpa banyak can-sin-cong deploy sana-deploy sini ya.
Jadi itu adalah kayak pertahanan paling gampang lah.
Kita nggak perlu ngutang-atik di banyak tempat bisa di-block.
Tapi ya tentu saja security itu kadang layer-layer juga ya.
Misalnya ya kayak di-block layer tambahin lagi kayak capture-nya, tambahin hal lain lagi yang bisa nolong.
Jadi mungkin bisa kombinasi dengan tools lain.
Tapi apakah WAF perlu kalau ngelihat beberapa keperluan tersebut
kayak Red Limiter, DDoS Attack lah buat basic-nya sih rasanya masih perlu ya.
Perlu ya.
Dan sudah cukup ya jadi primary defense berarti ya?
Yang first layer kan?
Yang main lain.
Yang main mental lah ya.
Ada juga kasus-kasus kayak dengan WAF bisa kita stop malicious code injection juga bisa.
Jadi kalau mereka HTTP pose dengan pattern tertentu nggak bisa.
Kalau DDoS tadi sudah disampaikan Mas Ipan.
Ada juga dengan pakai WAF kita juga bisa untuk nge-setting different zone.
Jadi kalau misalnya admin area hanya bisa di-assess oleh IP tertentu saja.
Contohnya hanya pakai IP proxy.
Jadi benar-benar hanya company proxy aja yang bisa masuk.
Itu juga pakai WAF.
Beberapa WAF tuh sekarang sudah pinter juga.
Mas Ipan sekarang udah kayak ada semacam AI atau ML-nya gitu loh.
Jadi mungkin patternnya nggak lagi regex atau yang traditional.
Bisa menyesuaikan.
Amazon kan AOS punya saya lupa namanya.
Antivirus kan biasa juga di WAF kan. Jalannya di Node.
Kalau misalnya kayak company enterprise dan mereka punya antivirus.
Sebelum mengakses sebuah situs mereka ada antivirusnya dulu.
Oke semoga menjawab ya pertanyaannya ya.
Kalau gitu berarti kita udahan dulu karena udah hampir.
Udah secepat amat ya.
Nanti susah bangun sahur nih.
Atau kita lanjut sampai sahur.
Mas Ipan jam kerjanya SGT atau Jakarta?
Singap atau WIB?
Ada sejam.
Tapi kan bisa jadi 9 sampai jam 5.
Terima kasih banyak buat temen-temen buat semuanya.
Terima kasih banyak juga buat Mas Irfan.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Terima kasih banyak buat teman-teman buat semuanya.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Mei 2023
Ngobrolin Accessibility
Aksesibilitas dibahas berangkat dari satu kekeliruan yang sering kita lakukan: menganggap pengguna kita sama seperti kit...
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
7 Feb 2024
Ngobrolin CSS Wrapped Bagian 2
Episode ini merupakan kelanjutan pembahasan artikel CSS Wrap 2023 dari Chrome Developers yang membahas fitur-fitur CSS t...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .