SecureBuild บริการที่สร้างเวอร์ชันปลอดภัยของโปรเจกต์โอเพนซอร์สพร้อมแบ่งปันรายได้กับผู้ดูแลโปรเจกต์ ได้ดึงดูดความสนใจจากชุมชนเทคโนโลยี แต่ไม่ใช่ด้วยเหตุผลที่พวกเขาหวังไว้ คำมั่นสัญญาในการให้บริการแก้ไขช่องโหว่ร้ายแรงภายใน 6 วันตามข้อตกลงระดับการให้บริการ (SLA) ได้จุดประกายการถกเถียงอย่างร้อนแรงเกี่ยวกับสิ่งที่ถือเป็นเวลาตอบสนองด้านความปลอดภัยที่เหมาะสมในสภาพแวดล้อมภัยคุกคามในปัจจุบัน
ข้อถกเถียงเรื่อง SLA 6 วัน
ข้อผูกพันของบริษัทในการแก้ไข CVE ร้ายแรงภายใน 6 วันได้กลายเป็นจุดดึงดูดการวิพากษ์วิจารณ์ ผู้เชี่ยวชาญด้านความปลอดภัยในชุมชนตั้งคำถามว่าระยะเวลานี้เป็นไปตามมาตรฐานความปลอดภัยสมัยใหม่หรือไม่ องค์กรบางแห่งรายงานว่ากำลังผลักดันให้มีขีดจำกัด 48 ชั่วโมงสำหรับการแพทช์ช่องโหว่ร้ายแรง ทำให้คำมั่นสัญญาของ SecureBuild ดูช้าเมื่อเปรียบเทียบ
อย่างไรก็ตาม ความเป็นจริงดูซับซ้อนกว่านั้น ในขณะที่ SecureBuild มุ่งหวังที่จะส่งมอบการแก้ไขเร็วกว่า 6 วันที่สัญญาไว้มาก พวกเขายอมรับว่าต้นไม้การพึ่งพิงที่ลึกบางครั้งอาจทำให้กระบวนการแพทช์ซับซ้อนขึ้น บริษัทมีแผนการทะเยอทะยานที่จะลดเวลาตอบสนองลงเหลือเพียง 6 ชั่วโมงในที่สุด แม้ว่าพวกเขาจะยังไม่ได้ให้กรอบเวลาสำหรับการบรรลุเป้าหมายนี้
การเปรียบเทียบไทม์ไลน์ SLA ของ SecureBuild
- CVE วิกฤต: SLA 6 วัน (เป้าหมาย: 6 ชั่วโมง)
- CVE ระดับสูง/กลาง/ต่ำ: SLA 13 วัน
- ความคาดหวังของอุตสาหกรรม: 48 ชั่วโมงสำหรับช่องโหว่วิกฤต
- มาตรฐานการตรวจสอบ: มักกำหนดให้ 30 วันสำหรับช่องโหว่วิกฤต
การคิดใหม่เกี่ยวกับกลยุทธ์การตอบสนอง CVE
การวิพากษ์วิจารณ์ที่แหลมคมเป็นพิเศษเกิดขึ้นจากการสนทนาในชุมชน โดยท้าทายแนวทางทั้งหมดของการแข่งขันเพื่อแก้ไข CVE ทุกตัว ผู้เชี่ยวชาญด้านความปลอดภัยโต้แย้งว่าองค์กรไม่ควรติดตามช่องโหว่ในแง่ของวัน แต่ควรมุ่งเน้นไปที่การแพทช์ก่อนที่การใช้ประโยชน์อย่างแข็งขันจะเริ่มต้นขึ้นในโลกจริง
คุณต้องมีแพทช์ออกมาก่อนที่การใช้ประโยชน์อย่างแข็งขันในโลกจริงจะเริ่มต้น นั่นคือตัวชี้วัดเดียวที่สำคัญ
มุมมองนี้ชี้ให้เห็นว่า SecureBuild และบริการที่คล้ายกันอาจกำลังแก้ปัญหาที่ผิด แทนที่จะสัญญาเวลาตอบสนองแบบครอบคลุมสำหรับ CVE ทั้งหมด ควรมุ่งเน้นไปที่การระบุว่าช่องโหว่ใดกำลังถูกใช้ประโยชน์จริงและจัดลำดับความสำคัญตามนั้น
การตรวจสอบความเป็นจริงของโมเดลธุรกิจ
นอกเหนือจากการถกเถียงทางเทคนิคแล้ว สมาชิกในชุมชนยังตั้งคำถามเกี่ยวกับหลักฐานทางธุรกิจพื้นฐาน ผู้สังเกตการณ์คนหนึ่งสังเกตว่าอาจมีการทับซ้อนกันน้อยมากระหว่างองค์กรที่ใช้ความปลอดภัยของตนบนการตอบสนอง CVE อย่างรวดเร็วกับองค์กรที่สนใจอย่างแท้จริงในการสนับสนุนโปรเจกต์โอเพนซอร์สทางการเงิน
ผู้นำของ SecureBuild โต้กลับความสงสัยนี้ โดยชี้ไปที่ฐานลูกค้าของพวกเขาที่เป็นผู้จำหน่ายซอฟต์แวร์อิสระ (ISV) ที่จำหน่ายซอฟต์แวร์เชิงพาณิชย์ให้กับสภาพแวดล้อมองค์กรเช่นธนาคารและหน่วยงานราชการ พวกเขาอ้างว่าเกือบครึ่งหนึ่งของลูกค้าเป็นบริษัท open-core เอง ซึ่งชี้ให้เห็นว่าแท้จริงแล้วมีตลาดสำหรับองค์กรที่ใส่ใจความปลอดภัยและต้องการสนับสนุนความยั่งยืนของโอเพนซอร์ส
โมเดลการแบ่งปันรายได้
- ผู้ดูแลโอเพนซอร์ส: 70% ของรายได้จากการสมัครสมาชิก
- SecureBuild : 30% ของรายได้จากการสมัครสมาชิก
- ไม่จำเป็นต้องมีสัญญาสนับสนุน
- ไม่จำเป็นต้องเปลี่ยนแปลงโค้ดจากโปรเจกต์
มองไปข้างหน้า
การสนทนานี้เผยให้เห็นความตึงเครียดที่กว้างขึ้นในอุตสาหกรรมความปลอดภัยระหว่างการจัดการช่องโหว่แบบครอบคลุมและการตอบสนองภัยคุกคามแบบเจาะจง ในขณะที่โมเดลการแบ่งปันรายได้ 70-30 ของ SecureBuild กับผู้ดูแลโอเพนซอร์สแก้ไขความท้าทายด้านความยั่งยืนที่แท้จริง แนวทางความปลอดภัยของพวกเขาอาจต้องการการปรับปรุงเพื่อตอบสนองความคาดหวังของอุตสาหกรรมที่เปลี่ยนแปลงไป
เมื่อองค์กรต่างๆ เรียกร้องเวลาตอบสนองที่เร็วขึ้นและการจัดลำดับความสำคัญของภัยคุกคามที่ซับซ้อนมากขึ้น บริการเช่น SecureBuild จะต้องสร้างสมดุลระหว่างกรอบเวลาที่ทะเยอทะยานกับความเป็นจริงในทางปฏิบัติของการพึ่งพิงซอฟต์แวร์ที่ซับซ้อนและลักษณะที่แท้จริงของภัยคุกคามด้านความปลอดภัย
อ้างอิง: Secure, Sustainable Open Source