พิมพ์เขียวความปลอดภัยซอฟต์แวร์องค์กร: ใช้โอเพ่นซอร์สอย่างมั่นใจ

ช่วงหลังมานี้ พาดหัวข่าวส่วนใหญ่เป็นเรื่องเกี่ยวกับช่องโหว่ zero day ที่เกิดจาก AI ซึ่งทำให้เกิดคำถามว่า องค์กรจะเสี่ยงเกินไปในการใช้ซอฟต์แวร์โอเพ่นซอร์สหรือไม่ ประเด็นนี้เป็นเรื่องที่ไม่ควรมองข้าม เนื่องจากโอเพ่นซอร์สครองสัดส่วนเฉลี่ยมากกว่าสามในสี่ของคลังซอร์สโค้ดทั้งหมดที่องค์กรหนึ่ง ๆ ใช้ในการพัฒนาซอฟต์แวร์หรือระบบไอทีภายในองค์กร (codebase) แต่คำตอบนั้นชัดเจนว่า ซอฟต์แวร์โอเพ่นซอร์สยังคงมีความปลอดภัยโดยเนื้อแท้ มีโครงสร้างที่แข็งแกร่ง และมีความปลอดภัยฝังตัวอยู่ตั้งแต่ระดับรากฐานเริ่มแรก

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

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

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

แม้จะไม่มีวิธีการพัฒนาซอฟต์แวร์ใดที่สามารถรับประกันความปลอดภัยได้อย่างสมบูรณ์แบบ แต่ความโปร่งใสและการระดมสมองจากกลุ่มคนจำนวนมากในชุมชนโอเพ่นซอร์ส ถือเป็นข้อได้เปรียบที่เด่นชัดเหนือโมเดลซอฟต์แวร์กรรมสิทธิ์เมื่อต้องรับมือกับภัยคุกคามยุคใหม่ แน่นอนว่าองค์กรธุรกิจต่างเฝ้าระวังช่องโหว่ทันทีที่ถูกตรวจพบมาโดยตลอดและจะยังคงทำเช่นนั้นต่อไป แต่สิ่งที่เปลี่ยนแปลงไปคือความเร็ว เห็นได้จากจำนวนช่องโหว่ความปลอดภัยที่ถูกเปิดเผยต่อสาธารณะ (CVEs) ที่พุ่งสูงมากกว่า 520% ตั้งแต่ปี 2016 เป็นต้นมา อีกทั้งเครื่องมือสแกนที่ขับเคลื่อนด้วย AI ในปัจจุบัน สามารถตรวจพบช่องโหว่ร้ายแรงประเภท zero-day ได้ภายในเวลาไม่กี่ชั่วโมง แทนที่จะเป็นหลายเดือนเหมือนในอดีต แต่ช่องโหว่ที่ถูกค้นพบโดย AI กลับได้รับการแก้ไขหรือทำการแพตช์ไม่ถึง 1% ความท้าทายในปัจจุบันจึงตกไปอยู่ที่ขีดความสามารถในการดำเนินงานขององค์กร ว่าจะสามารถนำตัวแก้ไขหรือฟิกส์ (fixes) เหล่านั้นมาทดสอบและใช้งานได้ทันท่วงทีหรือไม่

ปัญหานี้ทวีความรุนแรงยิ่งขึ้นจากความล้มเหลวในการผสานการทำงานร่วมกัน องค์กรใหญ่ ๆ ทุกแห่งต่างต้องพึ่งพาแพ็กเกจโอเพ่นซอร์สหลัก ๆ ชุดเดียวกัน เช่น Spring Framework, Jackson, Log4j, Pandas และ OpenSSL แต่หากขาดการประสานงาน ต่างคนต่างตรวจหาช่องโหว่แบบเดียวกัน พัฒนาแพตช์แยกกันในพื้นที่ปิด และรักษาเวอร์ชันย่อยส่วนตัวเอาไว้ โดยที่ไม่มีใครได้ประโยชน์ร่วมด้วย จะส่งผลให้เกิดการทำงานที่ซ้ำซ้อนด้วยต้นทุนที่สูงลิ่วและได้คุณภาพที่ไม่แน่นอน ในขณะที่ระบบนิเวศในภาพรวมยังคงเผชิญกับความเสี่ยง การจะคงความปลอดภัยไว้ได้นั้น องค์กรต่าง ๆ ต้องเข้าไปมีส่วนร่วมกับชุมชนผู้พัฒนาหลัก (upstream communities) เร่งยกระดับมาตรฐานการดำเนินงาน และที่สำคัญคือต้องลงมือทำสิ่งเหล่านี้ไปด้วยกัน

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

• เลือกใช้แพลตฟอร์มที่มีเวนเดอร์หรือผู้จำหน่ายที่มีความรับผิดชอบสนับสนุนอยู่เบื้องหลัง: โครงสร้างพื้นฐานขององค์กรคือฐานที่รองรับการทำงานของระบบทั้งหมด ดังนั้น ควรตรวจสอบให้แน่ใจว่าเวนเดอร์ที่ดูแลระบบเหล่านั้น เป็นผู้ที่มีส่วนร่วมอย่างจริงจังในโครงการโอเพ่นซอร์สที่พวกเขาหยิบยกมาให้บริการ เวนเดอร์ที่ให้การสนับสนุนชุมชนนักพัฒนาต้นน้ำมาอย่างยาวนาน มีการนำแพตช์จากเวอร์ชันล่าสุดย้อนไปติดตั้งให้เวอร์ชันเก่า (security backports) และมีกระบวนการแจ้งเตือนช่องโหว่อย่างรับผิดชอบ นับเป็นเวนเดอร์ที่มุ่งมั่นในการดูแลรักษาชุมชนโอเพ่นซอร์สให้แข็งแกร่ง ไม่ใช่เพียงแค่ต้องการรักษาผลประโยชน์ทางธุรกิจกับองค์กรที่เป็นลูกค้าเท่านั้น
• จัดทำรายการส่วนประกอบที่ต้องพึ่งพากันทั้งหมด: เริ่มจากการตรวจสอบพอร์ตโฟลิโอของแอปพลิเคชันขององค์กรเพื่อสร้างฐานข้อมูลอ้างอิง (baseline) จากนั้นระบุไลบรารีโอเพ่นซอร์สทั้งหมด ระบุส่วนประกอบที่เกี่ยวเนื่องกัน (transitive dependency) และเวอร์ชันที่ถูกล็อกไว้ (pinned version) ที่กำลังถูกใช้งานจริงในปัจจุบัน
• วัดรอบระยะเวลาการแพตช์จนถึงการนำไปใช้จริง: ประเมินจากเวลาที่เกิดขึ้นจริง ว่าแพตช์จากต้นทางต้องใช้เวลานานเท่าใดในการผ่านระบบสแกนความปลอดภัยภายใน การทดสอบ คณะกรรมการพิจารณาความเปลี่ยนแปลง จนถึงการเปิดใช้งานจริงบนระบบ เมื่อได้ตัวเลขระยะเวลาแล้ว ให้ตั้งเป้าหมายที่ท้าทายเพื่อลดระยะเวลานี้ลง
• ทำไปป์ไลน์ของการประกอบซอฟต์แวร์ใหม่ (rebuild) และติดตั้งใหม่ (redeploy) ให้เป็นอัตโนมัติ: ช่วงเวลาที่เสี่ยงต่อการถูกโจมตีหดสั้นลงจากหลักเดือนเป็นเพียงไม่กี่ชั่วโมงทำให้การอัปเดทระบบแบบแมนนวลไม่ตอบโจทย์อีกต่อไป องค์กรควรเตรียมสภาพแวดล้อมให้พร้อมสำหรับการ rebuild แอปพลิเคชันแบบอัตโนมัติได้อย่างแม่นยำและบ่อยครั้ง เพื่อให้องค์กรสามารถใช้แพ็คเกจที่ปลอดภัยได้อย่างรวดเร็ว
• ใช้โซลูชันด้านความปลอดภัยแบบเชิงรุก: เลือกใช้โซลูชันซัพพลายเชนเชิงรุกที่มาพร้อม zero-CVE baselines และการปกป้องระบบขณะทำงาน (runtime protection) เช่น Red Hat Hardened Images, Red Hat Trusted Libraries และ OpenShift Advanced Cluster Security เพื่อให้องค์กรขับเคลื่อนงานได้อย่างรวดเร็วยิ่งขึ้น

เร่งการเปลี่ยนแปลง ด้วย Project Lightwellในขณะที่องค์กรกำลังทำให้ไปป์ไลน์ต่าง ๆ เป็นอัตโนมัติเพื่อให้สามารถนำตัวแก้ไขหรือฟิกซ์ (fixes) เหล่านี้เข้ามาปรับใช้ในระบบให้ได้เร็วขึ้น ด้านไอบีเอ็มและเร้ดแฮทก็กำลังสร้างกลไกแก้ไขช่องโหว่ (remediation engine) ที่ออกแบบมาเพื่อให้บริการตัวแก้ไขหรือฟิกซ์เหล่านั้นเป็นการเฉพาะ ล่าสุดได้เปิดตัว Project Lightwell ซึ่งเป็นความร่วมมือร่วมทุนมูลค่า 5 พันล้านเหรียญสหรัฐฯ โดยมีกองกำลังวิศวกรกว่า 20,000 คนทั่วโลกคอยสนับสนุน เพื่อพลิกโฉมความปลอดภัยของซัพพลายเชนของซอฟต์แวร์ในยุค AI

Project Lightwell ขยายขอบเขตความสามารถของเร้ดแฮทที่ผ่านการพิสูจน์มาแล้วนานกว่าสองทศวรรษ ในการนำแพตช์ความปลอดภัยจากเวอร์ชันใหม่ล่าสุดส่งย้อนกลับไปแก้ไขให้กับซอฟต์แวร์เวอร์ชันเก่าที่องค์กรยังใช้อยู่ (backporting) เป็นการขยายวินัยทางวิศวกรรมอันเข้มงวดนี้จากระดับระบบปฏิบัติการ ขึ้นไปสู่ระดับแอปพลิเคชันเฟรมเวิร์กและกลุ่ม dependency ที่กว้างขึ้น โดยเริ่มจาก Maven/Java และขยายไปยัง PyPI, npm รวมถึงแพลตฟอร์มอื่น ๆ ต่อไป ด้วยการผสานพลังของ AI ในการประมวลผลภัยคุกคามปริมาณมาก ร่วมกับความเชี่ยวชาญของวิศวกรที่เป็นมนุษย์ ทำให้สามารถเจาะลึกเข้าไปแก้ไข (surgical fixes) บนเวอร์ชันที่มีเสถียรภาพซึ่งองค์กรใช้งานจริงได้อย่างแม่นยำ ช่วยตัดความจำเป็นในการสุ่มอัปเดตเวอร์ชันใหม่แบบสุ่มเสี่ยง ซึ่งอาจทำให้ระบบเสียหายได้

หากไม่มีกลไกในการส่งฟิกซ์ (fixes) กลับคืนสู่โครงการต้นทาง (upstream) ทุก ๆ แบ็กพอร์ต (backport) ที่องค์กรพัฒนาขึ้นเองจะกลายเป็นการแยกโค้ดมาทำเองเป็นการภายในอย่างถาวร ซึ่งเป็นโค้ดที่องค์กรต้องคอยดูแลต่อไปในทุกครั้งที่มีช่องโหว่ มีการอัปเดต หรือเกิดความเปลี่ยนแปลงของ dependency ในอนาคต สิ่งนี้จะเพิ่มทั้งต้นทุนและความเสี่ยงให้กับองค์กร แต่ Project Lightwell จะเข้ามาทำลายวงจรนี้ โดยเร้ดแฮทจะเป็นผู้พัฒนาฟิกซ์ส่งมอบให้กับองค์กร และส่งกลับคืนให้กับโครงการโอเพ่นซอร์สต้นน้ำนั้น ๆ ทำให้ฟิกซ์ดังกล่าวกลายเป็นส่วนหนึ่งของซอร์สโค้ดสาธารณะ (public codebase)

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

เครือข่ายอัจฉริยะในรูปแบบความร่วมมือนี้ มอบความสามารถสามประการที่ไม่มีองค์กรใดสามารถสร้างขึ้นเองได้โดยลำพัง

• ประการแรก สมาชิกจะสามารถแชร์การค้นพบช่องโหว่ใหม่ ๆ และได้รับแพตช์ที่ผ่านการประสานงานร่วมกันก่อนที่จะมีการเปิดเผยสู่สาธารณะ ซึ่งจะเปลี่ยนการค้นพบแบบต่างคนต่างทำเป็นการร่วมกันป้องกัน
• ประการที่สอง ทุกแพตช์จะถูกส่งมอบแบบ production-ready ที่มีการทำ cryptographic signature มาคู่กับ machine-readable SBOM และรายงานเตือนภัยด้านความปลอดภัย (security advisories) เพื่อตอบโจทย์ด้านการปฏิบัติตามกฎระเบียบ
• ประการที่สามซึ่งสำคัญมากคือ Project Lightwell ดำเนินงานภายใต้หลักการที่ต้องส่งตัวแก้ไขหรือฟิกซ์ (fixes) ที่พัฒนาขึ้น คืนกลับไปยังโครงการโอเพ่นซอร์สต้นทางเสมอ (upstream-always mandate) การทำงานร่วมกันในศูนย์กลางข้อมูลแห่งนี้ จึงไม่ใช่แค่การปกป้องเป็นรายองค์กร แต่เป็นการส่งคืนความก้าวหน้าด้านความปลอดภัยกลับสู่ชุมชนอย่างเป็นระบบ เพื่อช่วยให้โอเพ่นซอร์สปลอดภัยสำหรับทุกคน

โอเพ่นซอร์สเป็นรากฐานของการสร้างองค์กรยุคใหม่ การเฝ้าระวังร่วมกันและ Project Lightwell ช่วยให้โค้ดเหล่านี้ปลอดภัยเสมอด้วยการแก้ไขที่รวดเร็วมากขึ้นภายในชุมชนเดียวกันและเป็นแนวคิดระบบเปิด

• ข่าวพัฒนาซอฟต์แวร์
• ข่าวความปลอดภัย
• ข่าวพิมพ์เขียว
• ข่าวซอฟต์แวร์
• ข่าวเทคโนโลยี