ในช่วงไม่กี่ปีที่ผ่านมา บัญชีรายการวัสดุของซอฟต์แวร์ (SBOM) ได้กลายเป็นองค์ประกอบสำคัญของความปลอดภัยของซอฟต์แวร์และการจัดการความเสี่ยงของห่วงโซ่อุปทานของซอฟต์แวร์
เราได้พูดคุยกับ Tim Mackey หัวหน้าฝ่ายกลยุทธ์ความเสี่ยงของห่วงโซ่อุปทานของซอฟต์แวร์ ที่ Synopsys เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับประโยชน์และความท้าทายของ SBOM
BN: อะไรคือสิ่งสำคัญที่เกิดขึ้นจากช่องโหว่ Log4shell?
TM: ประสบการณ์ Log4Shell เน้นว่าการใช้งานโอเพ่นซอร์สแพร่หลายภายในองค์กร แม้แต่ซอฟต์แวร์เชิงพาณิชย์ก็พบว่ามีส่วนประกอบของโอเพ่นซอร์สเป็นการอ้างอิง สิ่งนี้นำไปสู่การโฟกัสที่คมชัดยิ่งขึ้นว่าโครงการโอเพ่นซอร์สนั้นสร้างและดูแลโดยอาสาสมัครภายนอก ไม่ใช่พนักงานหรือผู้ขายเชิงพาณิชย์ที่เป็นบุคคลที่สาม ซึ่งหมายความว่าฝ่ายไอทีขาดการควบคุมใดๆ ต่อการใช้ซอฟต์แวร์โอเพ่นซอร์สภายในซอฟต์แวร์เชิงพาณิชย์ แม้ว่าพวกเขาจะมีกระบวนการกำกับดูแลโอเพ่นซอร์สที่สมบูรณ์สำหรับซอฟต์แวร์โอเพ่นซอร์สที่พวกเขาดาวน์โหลดและใช้งานโดยตรง หรือใช้ในความพยายามในการพัฒนาซอฟต์แวร์แบบกำหนดเองของพวกเขาก็ตาม p>
BN: องค์กรต้องเข้าใจอะไรเกี่ยวกับโอเพ่นซอร์สเพื่อเตรียมพร้อมรับมือกับความท้าทายที่ไม่เหมือนใคร
TM: ขั้นตอนแรกคือ บ่อยครั้งเพียงแค่รับรู้ว่าคุณกำลังใช้โอเพ่นซอร์ส และจากนั้น คุณสามารถกำหนดเวิร์กโฟลว์การกำกับดูแลที่ใช้การได้ เนื่องจากทีมโอเพ่นซอร์สไม่รู้ว่าใครเป็นคนดาวน์โหลดโค้ดของพวกเขา คุณจึงไม่มีกลไกพุชสำหรับการอัปเดต คุณมีกลไกการดึง ดังนั้น เมื่อโปรเจกต์ถูกละทิ้งอย่างได้ผล หรือเมื่อสิ้นสุดอายุการบำรุงรักษา เราอยากให้ผู้ดูแลเหล่านั้นไปและพูดว่า”เฮ้ ฉันทำโปรเจกต์นี้เสร็จแล้ว”และเขียนข้อความเล็กๆ น้อยๆ ลงบนโปรเจ็กต์ว่า จะไม่มีการอัปเดตใหม่ใดๆ แต่โดยปกติจะไม่เกิดขึ้น
ตอนนี้ ความสามารถในการระบุโครงการที่”ละทิ้ง”กับ”เสร็จสิ้น”เป็นปัญหาที่แยกจากกัน คุณไม่สามารถตัดสินใจได้หากคุณไม่ได้มีส่วนร่วมกับโครงการ ดังนั้นหากคุณไม่รู้ว่าคุณกำลังใช้โครงการอยู่ ให้เริ่มถามคำถามเหล่านี้ และนั่นคือสิ่งที่เป็นปริศนาชิ้นใหญ่ชิ้นแรก–ยอมรับว่าคุณมีโอเพ่นซอร์ส ยอมรับว่ามีการจัดการที่แตกต่างกัน และวางกระบวนการที่รวมถึงการมีส่วนร่วมกับโครงการเหล่านั้น
สิ่งที่ท้าทายเป็นพิเศษคือเมื่อคุณพูดว่า สามหรือสี่ระดับที่ลึกลงไปในการพึ่งพาหรือห่วงโซ่ซัพพลายเออร์ที่คุณอาจไม่จำเป็นต้องรู้ว่าคุณมีโอเพ่นซอร์สโค้ดทำงานอยู่ นั่นเป็นหนึ่งในบทเรียนของประสบการณ์ Log4j ทั้งหมด ผู้คนไม่รู้ว่ามีสิ่งที่เรียกว่า Log4j ก่อนที่ปัญหาจะเกิดขึ้น
BN: SBOM คืออะไรกันแน่
TM: โดยพื้นฐานแล้ว SBOM เป็นไฟล์ที่แสดงรายการไลบรารีที่แอปพลิเคชันใช้ เป็นองค์ประกอบสำคัญของแผนการกำกับดูแลที่ไม่เพียงแต่ครอบคลุมการใช้งานโอเพ่นซอร์สในห่วงโซ่อุปทานของซอฟต์แวร์เท่านั้น แต่ยังกลายเป็นจุดยึดสำหรับองค์ประกอบการดำเนินงานอื่นๆ องค์ประกอบการดำเนินงานที่พบบ่อยที่สุดที่กล่าวถึงในวันนี้คือการใช้ SBOM เพื่อสื่อสารความเสี่ยงภายในส่วนประกอบในห่วงโซ่อุปทานของซอฟต์แวร์สำหรับแอปพลิเคชันที่กำหนด
BN: SBOM เพียงพอหรือไม่ที่จะบรรเทา ความเสี่ยงด้านความปลอดภัยและการออกใบอนุญาตของโอเพ่นซอร์ส?
TM: ไม่ เนื่องจาก SBOM ถูกนำเสนอใน Executive Order จึงได้รับความสนใจอย่างมากว่า’ฉันต้องไปและมี SBOM.’เพื่อวัตถุประสงค์ในทางปฏิบัติ องค์กรจำนวนมากในปัจจุบันกำลังสร้าง SBOM และเป็นเพียงรายการเนื้อหาที่ระบุว่า”ฉันมีส่วนประกอบเหล่านี้ที่มาจากจุดนี้ และนี่คือเวอร์ชันของส่วนประกอบเหล่านี้”
มันคือ จริง ๆ แล้วเป็นสิ่งที่คงที่ มันแสดงถึงลักษณะของซอฟต์แวร์ชิ้นนั้นเมื่อมันถูกจัดส่ง มันยอดเยี่ยมในแง่นั้น แต่จะไม่บอกคุณว่ามันปลอดภัยกว่าหรือปลอดภัยน้อยกว่าสิ่งอื่น เป็นการบอกคุณอย่างชัดเจนว่ารายการส่วนผสมนั้นมีลักษณะอย่างไรสำหรับซอฟต์แวร์ชิ้นนั้น และนั่นคือสิ่งที่ผู้คนมักถูกหลอก SBOM ที่ทุกคนพูดถึงไม่ใช่ยูนิคอร์นวิเศษตัวนี้ แต่เป็นส่วนหนึ่งของเวิร์กโฟลว์ที่ต้องดำเนินการภายในบริษัท
คำว่า SB ใน SBOM ไม่ได้หมายถึง Silver Bullet
p>
ปัญหาคือข้อมูล SBOM ต้องเข้าสู่เวิร์กโฟลว์ ผู้ที่อยู่ในจุดสิ้นสุดของการรับ SBOM อาจพูดว่า”นี่ ฉันได้ไฟล์นี้มาแต่ไม่รู้ว่าจะทำอย่างไร”และนั่นกำลังพูดถึงเวิร์กโฟลว์ ซึ่งเป็นชุดของกระบวนการที่องค์กรจำเป็นต้องทำ คิดออก
กล่าวอีกนัยหนึ่ง ความรู้ที่ได้รับจาก SBOM นั้นมีค่าอย่างเห็นได้ชัด แต่ถ้าองค์กรของคุณไม่มีกระบวนการที่จะใช้ การมี SBOM และข้อมูลช่องโหว่ที่เกี่ยวข้องจะมีประโยชน์เพียงเล็กน้อย. การขาดกระบวนการนี้เป็นความท้าทายที่ยิ่งใหญ่ที่สุด ในขณะที่ทีมจัดซื้อสามารถขอ SBOM จากซัพพลายเออร์ทั้งหมดของตนได้ หากไม่มีกระบวนการที่ชัดเจนในการดำเนินการกับข้อมูลใน SBOM สิ่งที่เกิดขึ้นก็คือคุณได้ ตอนนี้มีไฟล์อีกหนึ่งไฟล์ในไดเร็กทอรี
BN: กระบวนการที่ประสบความสำเร็จและกำหนดไว้อย่างดีอาจมีลักษณะอย่างไรเพื่อรับค่าจาก SBOM
TM: องค์กรทั้งหมดมีแผนกไอทีที่รับผิดชอบในการบำรุงรักษาแพตช์ในซอฟต์แวร์ที่อยู่ในองค์กรนั้น ซอฟต์แวร์ทั้งหมดสร้างขึ้นจากส่วนประกอบ เราทราบจากรายงาน Synopsys OSSRA ว่า การใช้งานโอเพ่นซอร์สภายในซอฟต์แวร์เชิงพาณิชย์เฉลี่ย 78 เปอร์เซ็นต์ คุณทราบดีว่าจะต้องมีส่วนประกอบที่เป็นโอเพ่นซอร์สและจะต้องมีการอัปเดต SBOM จะสื่อสารข้อมูลนั้นหากแนบมากับสินทรัพย์ที่ IT จัดการอยู่
ตอนนี้ เมื่อถึงเวลาที่มีการเปิดเผยช่องโหว่ใหม่ IT จะอยู่ในฐานะที่จะไปและสอบถามว่าระบบการจัดการ SBOM แล้วพูดว่า”อ-ฮ่า–ฉันมีสิ่งนี้ แต่แพทช์ของฉันมาจากไหน”แพทช์มาจากข้อมูลที่มาของ SBOM นั่นคือบทบาทของ SBOM ไม่ใช่การบอกว่าคุณมีช่องโหว่ใหม่ แต่เป็นเอกสารที่อธิบายอย่างชัดเจนว่ามีอะไรอยู่ในสิ่งประดิษฐ์นั้นที่คุณกำลังพยายามเรียกใช้ และตอนนี้คุณสามารถทำสิ่งที่ถูกต้องได้หากคุณมีเวิร์กโฟลว์นั้น
BN: SBOM ต้องเป็นไปตามข้อกำหนดอะไรบ้าง
TM: เพื่อให้เป็นประโยชน์ SBOM ต้องถูกต้องและสมบูรณ์ และปัญหาสองอย่างนี้ต่างกันแต่แก้ปัญหาได้อย่างหนึ่ง จะขึ้นอยู่กับการแก้ไขอื่น ๆ
ในการเริ่มต้น ห้องสมุดภายนอกทั้งหมดที่รวมอยู่ในแอปพลิเคชันจะต้องเข้าสู่ระบบเพื่อให้ SBOM เสร็จสมบูรณ์ รวมถึงซอฟต์แวร์โอเพ่นซอร์ส ไลบรารีของบุคคลที่สามเชิงพาณิชย์ และซอฟต์แวร์ใด ๆ ที่แนะนำผ่าน สัญญาบุคคลที่สาม ตามหลักการแล้ว SBOM จะดึงมาจากซอร์สโค้ดของแอปพลิเคชัน แม้ว่านี่อาจเป็นกระบวนการที่ยาก ขึ้นอยู่กับวิธีกำหนดกระบวนการสร้างของแอปพลิเคชัน ตัวอย่างเช่น คุณอาจต้องการ SBOM ที่แตกต่างกันสองรายการเมื่อรวบรวมแอปพลิเคชันสำหรับสองแพลตฟอร์มที่แตกต่างกัน หนึ่งรายการสำหรับ Windows และอีกรายการหนึ่งสำหรับ Linux
ในทำนองเดียวกัน สิ่งสำคัญคือต้องระบุส่วนประกอบอย่างถูกต้อง โดยจดจำทุกสิ่งตั้งแต่จุดกำเนิดไปจนถึงเวอร์ชันของมัน SBOM ของบุคคลที่หนึ่งซึ่งดึงมาจากซอร์สโค้ดของแอปพลิเคชันนั้นแม่นยำที่สุด แต่ก็มี SBOM ของบุคคลที่สามเช่นกัน ในกรณีนี้ แอปพลิเคชันและไม่ใช่ซอร์สโค้ดจะถูกสแกน ซึ่งอาจส่งผลให้ข้อมูลบางส่วนขาดหายไปเนื่องจากคุณไม่มีความสามารถในการระบุรุ่นของไลบรารีที่แม่นยำ ดังนั้น วิธีนี้จึงเหมาะสมเฉพาะในกรณีที่ SBOM ของบุคคลที่หนึ่งไม่พร้อมใช้งานหรือเป็นวิธีการตรวจสอบ SBOM ของบุคคลที่หนึ่งซ้ำอีกครั้ง
BN: คุณมองเห็นอะไรสำหรับอนาคตของ SBOM ใน จัดการกับช่องโหว่ของโอเพ่นซอร์สและความเสี่ยงด้านห่วงโซ่อุปทานของซอฟต์แวร์โดยรวมหรือไม่
TM: เราเพิ่งเริ่มต้นในยุค SBOM ผู้ค้าส่วนใหญ่ยังคงทำงานเพื่อสร้าง SBOM และจะดำเนินต่อไปในอนาคตอันใกล้ อย่างไรก็ตาม ในขณะที่ผู้จำหน่ายสามารถจัดหา SBOM ได้นั้นเป็นตัวบ่งชี้ความเฉียบแหลมด้านความปลอดภัยแบบโอเพ่นซอร์ส แต่ก็ไม่ใช่ตัวบ่งชี้เพียงอย่างเดียว สิ่งสำคัญคือหากองค์กรขอ SBOM จากผู้จำหน่าย แต่ไม่มีเวิร์กโฟลว์เพื่อประมวลผล SBOM นั้นและได้รับคุณค่าจากมัน การให้ผู้จำหน่ายจัดหา SBOM จะเพิ่มต้นทุนโดยไม่เกิดประโยชน์
น่าสนใจ หลายแห่งล้มเหลว เพื่อสังเกตว่ากรณีการใช้งานด้านความปลอดภัยสำหรับ SBOM มักจะสอดคล้องกับโซลูชันการวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCA) ที่มีอยู่แล้ว SBOMs มีประโยชน์มากที่สุดโดยเป็นส่วนหนึ่งของกลยุทธ์การลดความเสี่ยงโดยรวม ซึ่งหมายความว่ามีกระบวนการที่ใช้เพื่อวัดความเสี่ยงที่ถ่ายทอดผ่าน SBOM จากนั้นจึงดำเนินการบางอย่างเพื่อลดความเสี่ยงนั้น
เครดิตรูปภาพ: Momius/depositphotos.com