เมื่อผู้ผลิตออกแบบและจัดส่งสินค้าทางกายภาพที่พิสูจน์แล้วว่าเป็นอันตรายต่อมนุษย์ (หรือแม้แต่ทำให้มนุษย์ต้องเสี่ยงอันตราย) โดยปกติแล้วก็มักจะถูกเรียกคืนโดยผู้ผลิต การเรียกคืนโดยโรงงานนั้นเป็นเรื่องปกติที่กระทำกันในทุกอุตสาหกรรม แต่มักเป็นระเบียบปฏิบัติในสายการผลิต เช่น ของเล่นเด็ก รถยนต์ หรือเครื่องจักรอุตสาหกรรม ที่จะมีการสุ่มตรวจสอบสินค้าตัวอย่างสามชิ้น แต่ผู้เผยแพร่ซอฟต์แวร์กลับไม่จำเป็นต้องรับผิดชอบเมื่อมีการจัดส่งผลิตภัณฑ์ที่ทำให้ผู้คนและระบบตกอยู่ในอันตรายเพราะช่องโหว่ด้านความปลอดภัยทางไซเบอร์ สถานการณ์เช่นนี้ดูออกจะผิดแผกไปจากสิ่งที่ควรจะเป็น เพราะในโลกทุกวันนี้ ระบบส่วนใหญ่ที่ชีวิตคนเราต้องพึ่งพาอาศัยนั้นต้องทำงานบนซอฟต์แวร์ทั้งสิ้น
และยิ่งเมื่อได้เห็นถึงผลที่เกิดจากการละเมิดด้านข้อมูลที่เกิดขึ้นบ่อยๆ และความเสียหายที่ได้รับแล้ว สถานการณ์นี้ก็เป็นสิ่งที่ไม่อาจเพิกเฉย ผู้จำหน่ายซอฟต์แวร์สามารถและควรที่จะรับผิดชอบกับข้อผิดพลาดในผลิตภัณฑ์ของตนเองหรือไม่ ยกตัวอย่างเช่น หากนั่นส่งผลต่อกระแสไฟฟ้าที่คนนับล้านๆ ใช้งาน
สำหรับไบรอัน ฟอกซ์ ผู้ร่วมก่อตั้งและ CTO ของ Sonatype คำตอบก็คือ “ใช่” อย่างไม่มีต้องสงสัย อันที่จริงแล้วนี่ไม่ใช่เพียงแค่การวิวัฒนาการที่หลีกเลี่ยงไม่ได้ของอุตสาหกรรมซอฟต์แวร์ แต่ในขณะนี้คณะกรรมการคุ้มครองผู้บริโภคของคณะกรรมาธิการการค้าแห่งสหพันธรัฐมีอำนาจที่จะฟ้องร้องผู้ผลิตในข้อหาเพิกเฉย ไบรอันได้ให้สัมภาษณ์พิเศษกับ Tech HQ ว่าหากผู้ผลิตวางจำหน่ายผลิตภัณฑ์ที่ไม่ปลอดภัยตั้งแต่ในระบบ “นั่นก็อาจเท่ากับเป็นการละเมิดกฎไปแล้ว และคุณก็อาจต้องรับผิดชอบเมื่อสามารถคาดการณ์ได้ถึงภัยที่จะเกิดขึ้น […] ในอุตสาหกรรมอื่นๆ ที่เกิดขึ้นก่อนหน้าเราต่างก็ผ่านพ้นการปฏิรูปนี้ไปแล้ว เชื่อไหมครับว่า เคยมีช่วงเวลาที่ผู้ผลิตอาหารนั้นไม่ต้องรับผิดชอบใดๆ เลยเมื่อมีสัตว์รบกวนแอบเข้าไปในขวดและทำให้คนล้มป่วย ซึ่งนั่นก็คือเมื่อหนึ่งร้อยปีที่แล้ว […] สมัยก่อนผู้ผลิตรถยนต์ก็ไม่มีหน้าที่รับผิดชอบ หากล้อรถหลุดออกมาแล้วไปทับคนบาดเจ็บ สิ่งที่ผมอยากจะสื่อก็คือ หากคุณคิดว่าผู้ผลิตซอฟต์แวร์ไม่จำเป็นต้องรับผิดชอบความเสียหายใดๆ เลย ไม่ว่าในรูปแบบใดก็ตาม นั่นเท่ากับว่าคุณไม่ได้หันไปพิจารณาสิ่งที่เกิดขึ้นในประวัติศาสตร์ของ […] อุตสาหกรรมอื่นก่อนหน้านี้เลย ผมไม่รู้ว่าคุณคิดอย่างไร แต่ผมว่าคุณคิดผิดแล้ว”
ไม่ว่าอย่างไร อุตสาหกรรมซอฟต์แวร์ก็ยังไม่ได้มีการตกลงร่วมกันเพื่อหาแนวทางว่าความรับผิดชอบหรือการรับผิดนั้นจะออกมาในรูปแบบใด เมื่อหลายทศวรรษก่อนหน้า ลำดับขั้นของความรับผิดชอบนั้นสามารถแยกออกมาได้ชัดเจนกว่านี้เพราะสินค้าภายใต้กรรมสิทธิ์นั้นถูกจัดส่งออกไปในรูปแบบของแผ่นซีดี แต่สำหรับวัฏจักรการผลิตที่ทำได้อย่างรวดเร็ว รวมถึงการใช้ไลบรารี่ เฟรมเวิร์ก และคอมโพเนนต์แบบโอเพ่นซอร์สเช่นในทุกวันนี้ ภาพรวมในท้ายที่สุดจึงเป็นสิ่งที่ตีความได้ลำบากไม่น้อย แนวคิดที่กำลังติดท็อปเทรนด์บนเสิร์ชเอนจิ้นในเวลานี้ก็คือ SBoM (Software bill of materials) หรือ โปรแกรมที่ใช้จัดการกับรายการส่วนประกอบ ซึ่งเป็นหัวข้อที่ใครๆ พากันให้ความสนใจมากขึ้นนับตั้งแต่เริ่มมีข่าวคราวเกี่ยวกับความเปราะบางของซอฟต์แวร์ซัพพลายเชนหนาหูมากยิ่งขึ้น โดยเฉพาะอย่างยิ่งจากข่าวข้อบกพร่องของ Apache Log4j เมื่อปีที่แล้ว
องค์กรซอฟต์แวร์ บริษัท มูลนิธิ และชุมชนกำลังรวบรวมความคิดเห็น ทั้งยังเริ่มมีการเข้ามากำกับดูแลพร้อมกับร่างกฎหมายที่เกี่ยวข้องมากขึ้น สำหรับในยุโรป สิ่งเป็นโฟกัสหลักขณะนี้ก็คือการเรียกคืนและกฎระเบียบที่อยู่ในรูปแบบขององค์ประกอบบัญญัติด้านความมั่นคงปลอดภัยทางไซเบอร์ ถึงแม้จะเป็นแนวทางที่ถูกต้อง แต่ไบรอันก็ยังมองว่าทางสหภาพยุโรปนั้นกำลังทำพลาด ในแง่ที่กลายเป็นสร้างให้เกิดความคลุมเครือยิ่งกว่าเดิมว่าอะไรบ้างที่ถือว่าเป็นหรือไม่เป็นโอเพ่นซอร์ส
ขณะที่ในสหรัฐอเมริกา คำสั่งประธานาธิบดีของสหรัฐอเมริกาเกี่ยวกับ SBoM นั้นดูจะเน้นไปที่กฎหมายในแบบสั่งแล้วก็จบๆ ไป “การผลักดัน […] ความสามารถในการเรียกคืน […] เป็นแนวทางที่ผมผลักดันมาตลอด [เช่นกัน] และสิ่งที่ผมไม่ค่อยพอใจนักเกี่ยวกับข้อกำหนดแรกเริ่มด้าน SBoM ก็คือกฎเหล่านั้นมัวแต่ไปมุ่งเน้นเกี่ยวกับปัญหาในประเด็นที่ผิดๆ พวกเขามัวแต่สนใจกับความต้องการในการสร้างรายการวัสดุแล้วมอบให้เรา [ผู้ใช้ปลายทาง] เมื่อคุณขายซอฟต์แวร์ และผมมักจะเปรียบเทียบให้เห็นภาพด้วยการให้ลองสมมติว่าเราบอกผู้ผลิตรถยนต์ว่าคุณไม่จำเป็นต้องมีการเรียกคืนอีกต่อไปแล้ว ทั้งหมดที่ต้องทำเมื่อขายรถก็คือพิมพ์รายการวัสดุอะไหล่ต่างๆ และยัดใส่ไว้ในช่องเก็บของหน้ารถก็พอ ใครๆ มักจะหัวเราะเมื่อผมพูดแบบนั้นเพราะมันฟังดูตลกสิ้นดี แต่นั่นแหละคือสิ่งที่คำสั่งประธานาธิบดีบอกให้เราทำ โดยที่ไม่มีตรงไหนเลยที่ส่งเสริมให้บริษัทหันมาสนใจกับ SBoM นั้น และรับรองว่าหากมีจุด
อาจจะฟังดูสมเหตุสมผลดี ถ้าการพัฒนาซอฟต์แวร์จะเป็นไปอย่างช้าลง และไม่ต้องรีบเร่งตอบสนองแนวโน้มในการวนซ้ำ ผลิตภัณฑ์ที่วางจำหน่ายนั้นก็น่าจะปลอดภัยกับผู้ใช้ปลายทางมากขึ้นด้วย แต่นั่นไม่ใช่สิ่งที่เกิดขึ้นเลย ไบรอันบอกกับเรา จากหลายๆ บริษัทที่ Sonatype ได้ทำการสำรวจเมื่อไม่นานมานี้ “เราพบว่าบริษัทที่พยายามแก้ไขทั้งสองปัญหา [กระบวนการพัฒนาที่รวดเร็วและปลอดภัย] นั้นกลับปลอดภัยและเร็วกว่าบริษัทที่มุ่งเน้นเฉพาะความปลอดภัยเพียงอย่างเดียวหรือบริษัทที่มุ่งเน้นที่ความว่องไวเพียงอย่างเดียวเสียอีก ซึ่งฟังแล้วย้อนแย้งมาก” เขาอธิบายว่าบริษัทที่พัฒนาซอฟต์แวร์อย่างรวดเร็วและปลอดภัยจะมีกระบวนการ CI/CD ซึ่งมุ่งเน้นที่ DevSecOps ที่เหมาะสมรองรับอยู่แล้ว และบริษัทเหล่านั้นก็คือบริษัทที่ประสบความสำเร็จมากที่สุดนั่นเอง
“การบริหารจัดการซัพพลายเชนได้ดีแปลว่าคุณจะต้องทำงานช้าลงงั้นหรือ เปล่าเลย คำตอบก็คือคุณปลอดภัยขึ้นและรวดเร็วขึ้น เพราะคุณมีการแก้ไขและการทำงานซ้ำที่ไม่ได้วางแผนไว้ก่อนน้อยลงกว่าเดิมต่างหาก การมีวิธีจัดการกับ Dependency อย่างมีประสิทธิภาพนั้นก็แปลว่านักพัฒนาจะสามารถสร้างนวัตกรรมใหม่ๆ ได้อย่างปลอดภัยด้วย ซึ่งเป็นสถานการณ์หายากที่ทุกฝ่ายล้วนได้รับประโยชน์ หากทำอย่างเหมาะสม [ความปลอดภัย] ไม่จำเป็นต้องเป็นตัวถ่วงระบบเสมอไป”
แทบจะเป็นไปไม่ได้เลยที่จะจัดส่งซอฟต์แวร์ที่ปลอดภัยและจะปลอดภัยทั้งหมดตลอดเวลา ทั้ง Dependency การอัปเดต และวิธีเจาะระบบใหม่ๆ ต่างก็มีส่วนทำให้สิ่งนี้เป็นไปไม่ได้ แต่ไบรอันก็ยังชี้ให้เห็นว่า ความเปราะบางส่วนใหญ่ทั้งในปัจจุบันและอนาคตนั้นอาจเป็นแค่เพียงการคาดคะเนในทางทฤษฎีเท่านั้น จะต้องมีโหมดในการใช้ซอฟต์แวร์ที่ทำให้ผู้ไม่ประสงค์ดีสามารถนำไปใช้เพื่อเจาะระบบได้ กระบวนการคิดที่ผิดก็คือ “การมองว่าปัญหาอย่างความเปราะบางนี้เหมือนกับผักกาดที่ใบแหว่ง และเราไม่ควรวางขายผักกาดที่ใบแหว่งๆ นั่นไม่จริงเลย การโจมตีที่มุ่งร้ายก็เหมือนผักกาดใบแหว่ง และสิ่งเหล่านั้นไม่ได้ถูกนำออกจากคลังเก็บโดยเร็วที่สุดเท่าที่จะเป็นไปได้ แต่จริงๆ แล้วความเปราะบางส่วนใหญ่นั้นเหมือนกับเนยถั่วมากกว่า เพราะมันก่อให้เกิดอาการแพ้รุนแรงในบางคน แต่สำหรับคนส่วนใหญ่นั้นกลับไม่มีปัญหาอะไรไ
บทบาทที่ปรึกษาของรัฐบาลและองค์กรต่างๆ เปิดโอกาสให้ไบรอันได้เดินทางไปทั่วโลก โดยล่าสุดเขาได้มีโอกาสร่วมงานกับรัฐบาลของไบเดนในด้านความปลอดภัยไซเบอร์และปัญหาซอฟต์แวร์ เราไม่มีคำตอบง่ายๆ อย่าง คลังที่ตรวจสอบก่อนล่วงหน้าสำหรับส่คอมโพเนนต์ต่างๆ “มีคอมโพเนนต์อยู่มากมายเป็นล้านๆ ดังนั้นจึงเป็นไปไม่ได้เลยที่คุณจะตรวจสอบทั้งหมดอย่างมีประสิทธิภาพ เป็นไปไม่ได้ และบริษัทที่ทำแบบนั้นก็จะเรียกสิ่งนี้ว่า Repository ทองคำ ปัญหาก็คือคุณจะส่งผลกระทบในเชิงลบต่อนวัตกรรมเพราะคุณทำให้นักพัฒนาไม่สามารถนำสิ่งที่ยังไม่ได้ผ่านกระบวนการสารพัดมาใช้งานได้ แต่ปัญหาที่เลวร้ายที่สุดก็คือกระบวนการส่วนใหญ่นั้นไม่มีการย้อนกลับไปและตรวจสอบสิ่งที่อยู่ใน Repo”
และในกรณีเช่นนี้ เจ้าของ Repo ทองคำที่ว่า ซึ่งก็คือบริษัทพัฒนาซอฟต์แวร์ที่มี “Repository ของคอมโพเนนต์ที่ปลอดภัยทั้งหมด” ก็ยังจะต้องรับผิดชอบอยู่ดีจากมุมมองของผู้ใช้ปลายทาง หากเกิดความเสียหายใดๆ ขึ้นจากการใช้งานซอฟต์แวร์ดังกล่าว
ในขณะที่ยังไม่มีทางลัดใดๆ ในการจัดการความรับผิดทางกฎหมายของซอฟต์แวร์ ผู้เชี่ยวชาญที่คร่ำหวอดอยู่ในวงการซอฟต์แวร์ (และความปลอดภัยทางไซเบอร์) อย่างเช่นไบรอันนั้นก็จะต้องมีบทบาทสำคัญในการวางนโยบายที่สอดคล้องเชื่อมโยงกัน อาจต้องใช้เวลาอีกสักพักกว่าที่กฎระเบียบจะเป็นมากกว่าแค่แนวทางที่องค์กรต่างๆ ร่างขึ้นเพื่อรับมือกับปัญหาเดียวกันนี้ สำหรับอีกสองสามปีนับจากนี้ ผู้ซื้อพึงระวัง จึงยังเป็นคำแนะนำที่ดีที่สุดในการรักษาความปลอดภัยของการใช้งานซอฟต์แวร์ในชีวิตประจำวัน และสำหรับบริษัทพัฒนา DevSecOps ก็จะต้องเป็นมากกว่าคำฮิตติดเทรนด์ประจำเดือนด้วย
