อนาคตของโอเพ่นซอร์สอยู่ภายใต้การคุกคามหรือไม่?

ซอฟต์แวร์โอเพ่นซอร์ส (OSS) เป็นแกนหลักของสถาปัตยกรรมแอปพลิเคชันในปัจจุบัน ด้วยการเร่งเวลาออกสู่ตลาดและลดภาระของนักพัฒนาที่มักทำงานหนักเกินไป โอเพ่นซอร์สได้ยึดตำแหน่งการปฏิวัติภายในแนว DevOps แม้ว่าจะเป็นการเปลี่ยนแปลงอย่างมากในการพัฒนาแอปพลิเคชันสมัยใหม่ แต่การคัดลอกและวางแบบโอเพ่นซอร์สยังคงเป็นความเสี่ยงด้านความปลอดภัยที่สำคัญสำหรับองค์กรและบุคคลทั่วไป การต่อสู้กับความต้องการนี้จำเป็นต้องมีบัญชีดำทั้งหมดของรหัสโอเพ่นซอร์ส หรือการดำเนินการเชิงรุกของมาตรการตอบโต้ เช่น โซลูชัน WAF เจนเนอ เรชั่นถัดไป

รหัสของบุคคลที่สามมีความสำคัญต่อการพัฒนาแอพ

ไลบรารีเป็นแหล่งรวมซอร์สโค้ดที่มีประโยชน์อย่างเหลือเชื่อสำหรับคอมโพเนนต์ของเว็บหรือแอปพลิเคชันมือถือ ห้องสมุดเหล่านี้สามารถเป็นโอเพ่นซอร์สได้ – ใช้ได้สำหรับทุกคนโดยไม่มีค่าใช้จ่าย – หรือเป็นกรรมสิทธิ์ ซึ่งจะล็อกรหัสหลังการชำระเงิน แม้ว่าโอเพ่นซอร์สจะอ้างสิทธิ์มากมาย แต่โค้ดที่เป็นกรรมสิทธิ์ก็มีบทบาทในการทำงานอย่างต่อเนื่องของแอปพลิเคชันระดับองค์กร

ซอฟต์แวร์ของบุคคลที่สามนี้ เมื่อใช้อย่างมีความรับผิดชอบ จะป้องกันไม่ให้นักพัฒนาซอฟต์แวร์ต้องคิดค้นสิ่งใหม่ๆ อยู่ตลอดเวลา สิ่งนี้ช่วยปรับปรุงประสิทธิภาพของกระบวนการพัฒนาได้อย่างมาก ในขณะเดียวกันก็ช่วยในการผลิตผลิตภัณฑ์ขั้นสุดท้ายคุณภาพสูง ท้ายที่สุด การใช้โอเพ่นซอร์สโค้ดอย่างเสรีและเสรีจะสร้างวงจรป้อนกลับเชิงบวก ทำให้ผู้พัฒนาสามารถออกผลิตภัณฑ์ขั้นต่ำที่ทำงานได้เร็วยิ่งขึ้น ซึ่งเป็นการปูทางสำหรับการรวบรวมและการนำความคิดเห็นและการประเมินของผู้ใช้ไปใช้อย่างรวดเร็ว แม้ว่านักพัฒนาซอฟต์แวร์จะตระหนักดีถึงตำแหน่งที่สำคัญของโอเพ่นซอร์สภายในกระบวนการ DevOps แต่ผู้บริหารก็มักจะประหลาดใจเมื่อรู้ว่า 80% ของโค้ดที่ สนับสนุนแอปพลิเคชันสมัยใหม่นั้นมาจากโค้ดที่มีอยู่ก่อนแล้ว

อันตรายเงาของการพึ่งพาชั่วคราว

ไม่ใช่ข่าวที่โอเพ่นซอร์สมาพร้อมกับความเสี่ยง จุดอ่อนที่แพร่หลายล่าสุดเช่น Log4j และ HeartBleed ทำให้โอเพ่นซอร์สมีความเสี่ยงอย่างถาวรบนแผนที่ สิ่งที่ยังคงมีความเข้าใจเพิ่มขึ้นคือความถี่ที่แท้จริงของการใช้โอเพ่นซอร์ส และการซ่อนเร้นที่ช่องโหว่สามารถแอบเข้าไปในโครงการที่กำลังทำงานอยู่ได้ แม้จะมีความเสี่ยงอย่างต่อเนื่องที่นำเสนอโดยโครงการโอเพ่นซอร์ส แต่มีการวิจัยน้อยมากเกี่ยวกับประเภทของความเสี่ยงที่โอเพ่นซอร์สนำเสนอ นักวิจัยจาก Endor Labs มุ่งมั่นที่จะเปลี่ยนแปลงสิ่งนี้โดยชี้แจงที่มาของภัยคุกคาม OSS ที่สำคัญ

ภายในซอฟต์แวร์ การพึ่งพาสกรรมกริยาอธิบายความสัมพันธ์ทางอ้อมที่ไม่ซ้ำกันระหว่างสององค์ประกอบ ตัวอย่างเช่น สมมติว่าทีมพัฒนาของคุณเพิ่มแพ็คเกจ B ในโครงการที่กำลังดำเนินอยู่ ในทางกลับกัน แพ็คเกจ B จะดาวน์โหลดแพ็คเกจ C โดยอัตโนมัติ ในสถานการณ์นี้ ในขณะที่ซอฟต์แวร์ที่กำลังพัฒนามีความสัมพันธ์โดยตรงกับแพ็คเกจ B แพ็คเกจ C ยังคงซุ่มซ่อนอยู่ในเบื้องหลัง ซึ่งเป็นส่วนประกอบสำคัญแต่ส่วนใหญ่มองไม่เห็น ความผิดหวังในความพยายามใด ๆ ในการพัฒนาที่ปลอดภัยยิ่งขึ้นคือข้อเท็จจริงที่ว่ามีเพียง 5% ของการพึ่งพาซอฟต์แวร์โอเพ่นซอร์สเท่านั้นที่ถูกเลือกด้วยตนเองสำหรับการใช้งานภายในกระบวนการ DevOps ด้วยวิธีนี้ การพึ่งพาส่วนใหญ่จะถูกดึงเข้าสู่โค้ดเบสโดยอัตโนมัติ สิ่งนี้อธิบายถึงแหล่งที่มาของช่องโหว่แบบสกรรมกริยา รายงานล่าสุดโดย Endor Labs พบว่า 95% ของช่องโหว่โอเพ่นซอร์ส ที่น่าอัศจรรย์ มาจากการพึ่งพาแบบสกรรมกริยา

ข้อมูลดังกล่าวรวบรวมจากรายงาน Census II ของ Core Infrastructure ซึ่งแสดงรายชื่อซอฟต์แวร์โอเพ่นซอร์สฟรีที่ได้รับความนิยมมากที่สุด ข้อมูลนี้ได้รับการเสริมด้วยแหล่งข้อมูลอื่น ๆ ที่ช่วยให้นักวิจัยของ Endor สามารถสแกนตัวจัดการแพ็คเกจยอดนิยมและไลบรารี OSS ได้ นักวิจัยค้นพบว่า จาก 254 แพ็คเกจที่กล่าวถึงในข้อมูล Census II ส่วนใหญ่ประสบปัญหาจากการพึ่งพาสกรรมกริยาเฉลี่ย 14 รายการ ในสุญญากาศ 14 อาจไม่สูงจนน่าตกใจ แต่แอปพลิเคชันส่วนใหญ่พึ่งพาการพึ่งพาโดยตรงหลายสิบหรือหลายร้อย คู่สกรรมกริยาของพวกเขาขยายขนาด

ความกังวลหลักที่นักวิจัยเปล่งออกมานั้นขึ้นอยู่กับการประเมินปัญหาที่ต่ำเกินไปของอุตสาหกรรม ผู้บริหารยังคงบ่อนทำลายจำนวนของซอร์สโค้ดที่ใช้ภายในกระบวนการพัฒนา - การพึ่งพาสกรรมกริยายังไม่อยู่ในเรดาร์ ปัญหาด้านความปลอดภัยเชิงลึกที่แท้จริงยังคงแฝงตัวอยู่ใต้พื้นผิว เพิ่มรัศมีการระเบิดของการโจมตีแบบพิมพ์ผิดและเรียกใช้โค้ดจากระยะไกล หากการใช้โอเพ่นซอร์สโค้ดซ้ำอย่างต่อเนื่องเพื่อให้เต็มศักยภาพ ความปลอดภัยจำเป็นต้องกลายเป็นลำดับความสำคัญที่สูงขึ้นภายในกระบวนการ DevOps

วิธีป้องกันช่องโหว่ที่ซุ่มซ่อนอยู่

กระบวนการดูแลรักษากลุ่มเทคโนโลยีที่ปลอดภัยไม่เคยซับซ้อนไปกว่านี้อีกแล้ว ด้วยการแจ้งเตือนแพตช์ที่ล้นหลามอย่างรวดเร็ว ถึงเวลาแล้วที่การรักษาความปลอดภัยขององค์กรจะต้องจัดลำดับความสำคัญของการป้องกันแบบอัตโนมัติและไร้แพตช์ มาตรการดั้งเดิมที่ให้ความสำคัญกับการรักษาความปลอดภัยในขอบเขตควบคู่กับการวิเคราะห์แบบคงที่และไดนามิกอาศัยการอัปเดตด้วยตนเอง ซึ่งหมายความว่าไม่มีการป้องกันซีโร่เดย์ รหัสลับที่ผู้โจมตีใช้ในการโจมตี SolarWinds ที่น่าอับอายไม่ถูกตรวจพบโดยการวิเคราะห์แบบคงที่ เนื่องจากไม่มีข้อผิดพลาดทางเทคนิค

การระบุและบล็อกการพยายามแสวงประโยชน์ต้องใช้ชุดซอฟต์แวร์ประสานขนาดเล็ก เพื่อช่วยกำหนดและป้องกันขอบเขตของแอปพลิเคชันเป็นอันดับแรก สามารถติดตั้ง Web Application Firewall (WAF) รุ่นถัดไปได้ WAF อยู่ที่ขอบระหว่างภายนอกและภายใน ตรวจสอบทราฟฟิกทั้งหมดที่ไหลเข้าและออกจากแอปพลิเคชัน มุมมองยุคถัดไปช่วยให้ WAF นี้สามารถปรับและปรับใช้นโยบายใหม่ได้โดยอัตโนมัติ การปรับใช้แบบอัตโนมัติของวิวัฒนาการที่ต่อเนื่องนี้ทำให้ทีมรักษาความปลอดภัยมีเวลาและพลังงานมากขึ้น ซึ่ง WAF โรงเรียนเก่าอาจใช้หมดไป

ในขณะที่ WAF คอยจัดการกับความพยายามภายนอกในการเรียกใช้โค้ด Runtime Application Self Protection (RASP) จะป้องกันจุดอ่อนภายในและการแทรกโค้ด การป้องกันระดับนี้จะประเมินเพย์โหลดทั้งหมด (เช่น การสืบค้น SQL และคำสั่งระบบปฏิบัติการ) ตามเวลาจริง กระบวนการนี้ไม่ต้องการลายเซ็นหรือขั้นตอนการเรียนรู้ และดำเนินการทั้งหมดภายในบริบทของแอปพลิเคชัน เนื่องจากสิ่งนี้ทำงานภายในแอปพลิเคชัน จึงครอบคลุมบริบทเกือบทั้งหมด ซึ่งหมายความว่า แม้ว่าช่องโหว่จะอนุญาตให้เจาะขอบเขตได้ แต่ผู้โจมตีก็ไม่สามารถเคลื่อนไหวด้านข้างได้ เนื่องจากพฤติกรรมของแอปพลิเคชันที่น่าสงสัยจะทำให้ RASP ปิดตัวลง สิ่งนี้จะยุติกิจกรรมที่น่าสงสัยและแจ้งเตือนทีมรักษาความปลอดภัย ด้วยวิธีนี้ RASP จึงเป็นส่วนเสริมของ WAF รุ่นต่อไป ในขณะที่ WAF ช่วยป้องกันทราฟฟิกที่ไม่ดีออกไป RASP จะช่วยลดความเสี่ยงที่เกิดจากการแฝงตัวและการแสวงประโยชน์แบบสกรรมกริยา ด้วยส่วนประกอบเหล่านี้ที่ปกป้องกองเทคโนโลยี ภาระที่ OSS วางไว้กับความปลอดภัยในปัจจุบันจึงเบาบางลงอย่างมาก