ओपन सोर्स सुरक्षा कार्य “विशेष” नहीं है

मुख्य सारांश

• सुरक्षा का रहस्य-मुक्तिकरण: सुरक्षा कार्य को एक विशेष क्षेत्र मानने वाले 'security exceptionalism' की आलोचना की गई है, और इस बात पर ज़ोर दिया गया है कि इसे सामान्य engineering के दायरे में संभाला जाना चाहिए।
• रिस्क मैनेजमेंट का एकीकरण: सुरक्षा incidents को किसी जादुई आपदा की तरह नहीं, बल्कि सिस्टम की availability या performance में गिरावट जैसे एक प्रकार के 'operational risk' के रूप में परिभाषित किया गया है।
• व्यावहारिक दिशा: security debt को technical debt की तरह ही मानने और specialist security team के हस्तक्षेप के बिना भी engineering teams द्वारा स्वायत्त रूप से हल किए जा सकने वाले guardrails बनाने का प्रस्ताव रखा गया है।

कोरियाई अनुवाद संस्करण

---

गहन विश्लेषण

1. Security Exceptionalism की समस्या

कई organizations में सुरक्षा को "विशेष, समझना कठिन, और ऐसा क्षेत्र जिसे केवल कुछ experts ही संभाल सकते हैं" माना जाता है। यह दृष्टिकोण security teams को engineering process से अलग-थलग कर देता है, और नतीजतन निम्नलिखित दुष्प्रभाव पैदा करता है।

• Siloing: सुरक्षा प्रभारी workflow में bottleneck पैदा करते हैं, या development context को समझे बिना केवल compliance लागू करने पर ज़ोर देते हैं।
• जिम्मेदारी टालना: "क्या मेरा code सुरक्षित है?" इस सवाल का जवाब developer खुद नहीं दे पाता और केवल security team की approval पर निर्भर हो जाता है।

2. सुरक्षा को engineering समस्या के रूप में पुनर्परिभाषित करना

लेख का तर्क है कि सुरक्षा को किसी विशेष कौशल के बजाय software quality और reliability के एक subset के रूप में देखा जाना चाहिए।

• Bug के रूप में vulnerability: memory corruption या injection, किसी विशेष attack का लक्ष्य बनने से पहले ही, input validation विफल होने जैसी design flaw हैं।
• Operational metrics का उपयोग: सुरक्षा को 'compliance स्थिति' के बजाय 'MTTD (औसत पहचान समय)', 'MTTR (औसत रिकवरी समय)' जैसे operational metrics से प्रबंधित किया जाना चाहिए।

3. समाधान: abstraction और guardrails (Paved Road)

हर code review security experts से करवाने के बजाय, ऐसा environment बनाना मुख्य है जिसमें engineers के लिए 'गलती करना कठिन' हो।

• सुरक्षित default settings: framework स्तर पर XSS protection जैसी चीज़ों को default रूप से लागू कर developer की cognitive load कम करना।
• Self-service tools: CI/CD pipeline में static analysis (SAST) और dependency scanning को integrate करके development cycle में तुरंत शामिल करना।

---

प्रमुख अवधारणाओं की तुलना

श्रेणी	पारंपरिक सुरक्षा (Special)	engineering-आधारित सुरक्षा (Not Special)
लक्ष्य	पूर्ण अवरोध और compliance	risk mitigation और system resilience सुनिश्चित करना
जिम्मेदारी	केंद्रीकृत security team	पूरी distributed engineering team
उपकरण	external scanners, manual checks	automated testing, static analysis, library abstraction
विफलता प्रतिक्रिया	incident investigation और जवाबदेही तय करना	post-mortem के माध्यम से system improvement