Pekerjaan keamanan open source tidak “istimewa”

Ringkasan inti

• Demistifikasi keamanan: Mengkritik 'security exceptionalism' yang memperlakukan pekerjaan keamanan sebagai ranah khusus, dan menekankan bahwa hal itu harus ditangani dalam kategori rekayasa yang umum.
• Integrasi manajemen risiko: Mendefinisikan insiden keamanan bukan sebagai bencana yang terasa seperti sihir, melainkan sebagai jenis 'risiko operasional' yang sama seperti penurunan ketersediaan (Availability) atau kinerja (Performance) sistem.
• Arah yang praktis: Mengusulkan agar security debt diperlakukan sama seperti technical debt, serta membangun guardrail yang memungkinkan tim engineering menyelesaikannya secara mandiri tanpa campur tangan tim keamanan khusus.

Versi terjemahan Korea

---

Analisis mendalam

1. Masalah Security Exceptionalism

Di banyak organisasi, keamanan dianggap sebagai "ranah yang istimewa, sulit dipahami, dan hanya bisa ditangani oleh segelintir pakar". Sudut pandang ini mengisolasi tim keamanan dari proses engineering dan pada akhirnya menimbulkan efek samping berikut.

• Tersilo: Pihak keamanan menjadi bottleneck dalam workflow, atau memaksakan kepatuhan regulasi tanpa memahami konteks pengembangan.
• Lempar tanggung jawab: Untuk pertanyaan seperti "Apakah kode saya aman?", developer tidak bisa menjawab sendiri dan akhirnya hanya bergantung pada persetujuan tim keamanan.

2. Mendefinisikan ulang keamanan sebagai masalah engineering

Tulisan ini berargumen bahwa keamanan seharusnya dipandang bukan sebagai keahlian khusus, melainkan sebagai subset dari kualitas dan keandalan perangkat lunak.

• Kerentanan sebagai bug: Memory corruption atau injection, sebelum menjadi target serangan khusus, pada dasarnya adalah cacat desain berupa kegagalan validasi input.
• Mengadopsi metrik operasional: Keamanan harus dikelola bukan berdasarkan 'kepatuhan', tetapi dengan metrik operasional seperti 'MTTD (mean time to detect)' dan 'MTTR (mean time to recover)'.

3. Solusi: abstraksi dan guardrail (Paved Road)

Daripada pakar keamanan melakukan semua code review, kuncinya adalah membangun lingkungan yang membuat engineer 'sulit melakukan kesalahan'.

• Konfigurasi aman secara default: Menerapkan pencegahan XSS dan sejenisnya di level framework secara default untuk mengurangi beban kognitif developer.
• Alat self-service: Mengintegrasikan static analysis (SAST) dan dependency scan ke dalam pipeline CI/CD agar langsung tercermin dalam siklus pengembangan.

---

Data perbandingan konsep utama

Kategori	Keamanan tradisional (Special)	Keamanan berbasis engineering (Not Special)
Tujuan	Pemblokiran sempurna dan kepatuhan regulasi	Mitigasi risiko dan memastikan ketahanan sistem
Penanggung jawab	Tim keamanan terpusat	Seluruh tim engineering yang terdistribusi
Alat	Scanner eksternal, pemeriksaan manual	Pengujian otomatis, static analysis, abstraksi library
Respons terhadap kegagalan	Investigasi insiden dan mencari pihak yang disalahkan	Perbaikan sistem melalui post-mortem

[darjeeling]

Sepertinya ringkasannya salah.

https://rosettalens.com/s/ko/security-work-isnt-special

Silakan lihat teks aslinya lewat ini.

[gguimoon]

Tautan artikel asli dan terjemahan bahasa Koreanya tidak memuat isi yang diperkenalkan dalam analisis mendalam. Isi analisis mendalam itu merujuk ke tulisan yang mana? Apakah itu tulisan yang Anda buat sendiri?

[darjeeling]

Sepertinya saya harus membuat gems baru.. T_T Maaf.